Кратко

  • В RFC 821 отправитель мог поставить перед ящиком явную последовательность ретрансляторов; каждый переносил собственное имя из прямого пути в обратный.
  • RFC 1123 выбрал для обычной доставки универсальные доменные имена и DNS MX. Получатель по-прежнему принимал старый синтаксис, но мог отбросить промежуточные узлы и использовать конечный домен.
  • Нынешний SMTP разделяет распознавание, разрешение на relay и исполнение: сервер может игнорировать маршрут, отказать или строго выполнить его в ограниченном исключении.

Одинаковая строка больше не означает одинаковый путь

Клиент передаёт:

RCPT TO:<[relay alpha, relay beta]:[ящик user в домене gamma]>

Абсолютное назначение — ящик пользователя в домене gamma. Домены до двоеточия предлагают пройти через alpha и beta. Сервер способен правильно выделить обе части, не наделяя их одинаковой силой.

Один сервер удалит список и найдёт маршрут к gamma.example. Другой откажется быть ретранслятором. Третий в рамках разрешённой диагностики выполнит старое правило и сначала соединится с alpha.example. Все три правильно разобрали адрес. Различается политика, превращающая текст в сетевое действие.

Так обратная совместимость стала односторонней: система обязалась не искажать язык прошлого, но не обязалась вернуть ему прежний контроль.

Когда маршрут переходил из одного пути в другой

RFC 822 определял route-addr: необязательный маршрут перед абсолютным адресом. Автор мог перечислить хосты или службы передачи, а ящик оставался отдельным объектом.

RFC 821 исполнял это различие в конверте SMTP. В примере ретрансляторы ONE и TWO стояли перед ящиком JOE в домене THREE: ящик был назначением, а ONE и TWO задавали поездку.

Когда письмо приходило на названный relay, сервер удалял свой идентификатор из forward-path, ставил его в начало reverse-path, становился новым SMTP-отправителем и подключался к следующему хосту. Список оставшейся работы сокращался, а возможный путь возврата ошибки рос.

При этом relay мог отвергнуть задачу. Само имя хоста никогда не было универсальным разрешением на его использование. RFC 821 также отделял конверт от сообщения: эти пути не обязаны были попадать в To, From или CC. Транспортный маршрут не становился авторским адресом в тексте.

Устойчивое имя заменило быстро устаревающий маршрут

В 1989 году RFC 1123 потребовал от отправителей не создавать явную форму source route. Причина была архитектурной: Интернет выбрал универсальные имена вместо source routing. SMTP обеспечивал связность, DNS — глобальные и независимые от местоположения имена, а MX решал основной случай, ради которого раньше требовался список промежуточных хостов.

Ретрансляторы не исчезли. Изменился субъект выбора. Отправитель указывает конечный домен; домен публикует mail exchanger; каждый сервер применяет текущую авторизацию, доступность и политику. При смене топологии владелец домена обновляет DNS, не заставляя всех корреспондентов менять сохранённые адреса.

Ящик стал долговечнее конкретной дороги. Сведения о вчерашней сети перестали быть частью постоянной идентичности получателя.

Принять форму и убрать её действие

RFC 1123 не объявил старую запись синтаксической ошибкой. Получатель должен был её принимать. Если историческая relay-функция не реализована, следовало попробовать конечный домен почтового ящика. В нормативном примере ретрансляторы ALPHA и BETA удалялись, а ящик JOE направлялся прямо к домену GAMMA.

RFC 2821 уточнил границу. Принимающая система распознаёт source route, но должна обычно снять его и использовать домен ящика так, будто списка не было. Имена удалённых узлов нельзя копировать в reverse-path. Узнавание старой пунктуации не восстанавливает обратный маршрут RFC 821.

Отказ от parser ломает старые клиенты или принимает разделители за данные local-part. Автоматическое исполнение позволяет старому токену выбрать посредника, запрещённого сегодняшней политикой. Распознавание сохраняет совместимость; неподчинение сохраняет границу доверия.

Современный стандарт оставляет точное исключение

RFC 5321 до сих пор содержит A-d-l, список доменов через запятую, в нормативной грамматике path. Примечание соединяет три разных свойства: форму необходимо принимать, не следует генерировать и следует игнорировать.

Сервер может отказаться от relay или от адреса с маршрутом. Может убрать список и использовать конечное назначение. Но если он осознанно выполняет маршрут, то обязан сначала отправить на первый указанный домен и не вправе придумывать сокращение. Устаревшая функция не становится неопределённой при включении.

Стандарт описывает и миграционную ловушку. Некоторые отправители указывали в конце недействительное для DNS имя, рассчитывая, что посредник его поймёт. Когда совместимый сервер снимает маршрут, зависимость обнаруживается и доставка ломается. Строка остаётся грамматически допустимой после исчезновения модели, которая обеспечивала ей успех.

Отладка или тяжёлая временная ошибка конфигурации иногда оправдывают исключение. Тогда полномочие возникает из явного решения оператора, а не из способности клиента написать перечень доменов.

В заголовке сохранился другой след

RFC 5322 относит route в адресе заголовка к устаревшей грамматике и советует игнорировать при интерпретации. Архив способен прочитать старое письмо, не превращая исторические знаки в действующую команду SMTP.

Route в старом поле To не доказывает ни получателей конверта, ни реально пройденные серверы. Для этого нужны транзакция, соединения и поля Received, каждое со своими ограничениями.

Источники и пределы доказательств

RFC 821, RFC 822, RFC 1123, RFC 2821, RFC 5321 и RFC 5322 подтверждают грамматику и нормативный переход. Они не измеряют современное применение, настройки продуктов, фильтрацию или успешность доставки.

Исторический результат уже: SMTP сохранил обязанность понимать старый маршрут и отнял у него право по умолчанию выбирать маршрут фактический.