Кратко

  • Редакция августа 1982 года определила SMTP как надёжный потоковый диалог, способный передавать почту через ретрансляторы даже при разных транспортных службах на концах.
  • MAIL задаёт обратный путь, RCPT — один или несколько путей получателей; RFC 822 отдельно описывает формат текста. Принятый SMTP-сеанс не доказывает попадание письма в ящик или его прочтение.

Письмо может пересечь границу сети, не зная, по какой сети его передали. Именно такую задачу показывает спецификация Simple Mail Transfer Protocol, опубликованная Jonathan B. Postel в августе 1982 года. RFC 821 не привязывала SMTP к конкретной подсистеме передачи. Она требовала надёжный упорядоченный поток данных и описывала обмен командами и ответами между SMTP-процессами.

Ретрансляция была частью модели. Если отправитель и получатель использовали одну транспортную службу, отправляющий процесс мог напрямую обратиться к принимающему SMTP. Если нет — один или несколько промежуточных SMTP-серверов связывали транспортные среды. Jonathan B. Postel отдельно уточнял масштаб: транспортная служба могла охватывать одну сеть, несколько сетей или часть одной сети. «Сеть» и «транспортная среда» не были взаимозаменяемыми понятиями.

Транзакция делала передачу наблюдаемой по шагам. Отправитель открывал двусторонний канал, получатель отвечал. MAIL начинал транзакцию с обратным путём для уведомления о недоставке. Каждый RCPT задавал путь к получателю и мог повторяться. Затем DATA передавал сообщение. Числовые ответы показывали, принята ли каждая команда. Конверт SMTP содержал инструкции доставки, отличные от текста письма.

Сопоставление с RFC 822, вышедшей в том же месяце, показывает разделение задач. RFC 822 стандартизировала формат текстовых сообщений ARPA Internet, RFC 821 — диалог передачи. Заголовок From: относился к представлению сообщения, а MAIL FROM — к SMTP-транзакции. Если считать их одним и тем же, адрес в тексте ошибочно становится доказательством реального маршрута или решения о доставке. Спецификации такого не обещали.

RFC 821 была редакцией, а не свидетельством рождения SMTP. В заголовке сказано, что она заменяет RFC 788, 780 и 772; RFC 788 ноября 1981 года уже описывала SMTP. План перехода RFC 801 упоминает SMTP-службу в контексте смены сетевой инфраструктуры, но не сообщает число установок и не измеряет успешную доставку пользователям. Дата обновлённой спецификации не равна дате её внедрения на всех узлах.

Модель не ограничивалась TCP. Приложения RFC 821 описывают, среди прочего, NCP, TCP и NITS; приложение для TCP назначает SMTP номер сокета 25. Это уточняет реализацию, но открытый порт сам по себе не доказывает, что служба работает. Нужны активный принимающий процесс, принятые команды, корректные пути, завершённая передача DATA и локальная обработка после соединения.

Исторический вклад заключался в переносимой границе сервиса. SMTP задал общий диалог для передачи почты и позволил ретрансляторам соединять разные транспортные среды; формат текста и поведение локального почтового ящика остались отдельными вопросами. Если применить Note 64 Heng Lu как позднейшую аналитическую рамку, это пример общей спецификации, ограниченной потребностями совместимости и оставляющей выбор транспорта и развёртывания работающим системам. Это интерпретация, а не свидетельство намерений Jonathan B. Postel.

Sources