Кратко

  • Явный SMTP source route был изменяемым состоянием конверта: каждое реле потребляло свой первый элемент forward-path и переносило его в reverse-path.
  • Маршрут отличался от абсолютного почтового ящика, а SMTP-конверт — от видимых To: и From:. Эти поля не удостоверяли автора и не доказывали фактическое прохождение всех узлов.
  • MX и глобально понятные доменные имена передали обычный выбор пути MTA, DNS и локальной политике. Способность прочитать старую форму больше не означала обязанность дать ей транзит.

Узел стирал себя из будущего и добавлял в прошлое

После задания reverse-path в MAIL FROM клиент мог отправить команду:

RCPT TO:<@ONE,@TWO:JOE@THREE>

RFC 821 называет аргумент RCPT forward-path. Справа от двоеточия расположен абсолютный ящик JOE@THREE; слева — source route @ONE,@TWO. Ящик отвечает на вопрос о конечном адресате, маршрут — о способе добраться до него. Спецификация прямо запрещает смешивать эти понятия.

Если ONE узнаёт себя в первом элементе, оно удаляет @ONE. Остаётся @TWO:JOE@THREE. Одновременно ONE ставит собственный идентификатор в начало reverse-path. Информация не исчезает: она перестаёт указывать ещё не выполненный шаг и становится частью пути, по которому впоследствии можно вернуть уведомление о недоставке.

Одна сторона состояния убывала, другая росла. Поэтому source route был не длинной декоративной записью адреса, а небольшой машиной переходов, которую исполняли MTA при передаче ответственности.

Конверт не переписывал авторство сообщения

Reverse-path из MAIL FROM относится к транспортной транзакции. Он не обязан совпадать с видимым From:, не равен Reply-To: и не подтверждает, кто написал текст. Его назначение связано с распределением ответственности и возвратом последующей ошибки.

Forward-path из RCPT TO также не обязан копировать To: или Cc:. Один текст может иметь несколько получателей конверта; Bcc не показывается читателю; имя в заголовке может не участвовать в конкретной SMTP-сессии.

RFC 822 разделял в route-addr маршрут и addr-spec и не рекомендовал source routing без особой необходимости. Исторически похожая запись встречалась в формате сообщения, но это не отменяет границу между сообщением и транспортом.

Следовательно, перенос имени ONE в reverse-path не меняет поле автора. Архив, сохранивший только доставленный текст, мог полностью утратить исходную маршрутную инструкцию. Доказательство следует хранить вместе со слоем, на котором оно возникло.

На выходе реле могло называться иначе

RFC 821 требовал добавлять в reverse-path не обязательно полученное написание имени, а имя, под которым реле известно в среде, куда оно отправляет. Это учитывало шлюзы между разными системами именования и почтовыми сообществами.

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

Если текущий сервер не является первым элементом forward-path, он не вправе произвольно удалить этот элемент. Тот может использоваться для выбора следующего SMTP. Право потребить шаг возникает из совпадения позиции и идентичности.

Но совпадение не является криптографической аутентификацией. Source route не доказывает контроль доменов, реальный проход через каждый узел или честность записавших его систем. Даже выросший reverse-path остаётся механизмом обработки ошибки, а не неизменяемым журналом происхождения.

MX вынес изменчивую топологию из адреса

RFC 974 связывает домен назначения с почтовыми обменниками и их предпочтениями. Отправляющий MTA запрашивает домен и пробует подходящих кандидатов по правилам. Пользователь сохраняет user@domain, даже если домен меняет принимающие серверы.

MX не перенёс source route в DNS. Обменники не образуют последовательность обязательных промежуточных точек. RFC 974 предостерегает от рекурсивного поиска MX для MX ради построения чрезмерных цепочек.

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

Изменилась и стоимость исправления. Устаревшая source route может быть размножена по адресным книгам, очередям и alias. MX обновляется в точке, которой управляет домен. Топология стала результатом текущего решения, а не долговечной частью идентичности получателя.

Старую форму сначала перестали производить

RFC 1123 говорит, что Sender-SMTP не должен посылать явный маршрут @...: в RCPT. Архитектурный выбор сделан в пользу универсальных имён: user@domain, глобально значимый домен и MX покрывают основную потребность.

Однако Receiver-SMTP по-прежнему обязан принимать синтаксис. Здесь «принимать» прежде всего значит правильно разбирать форму, а не предоставлять любому клиенту неограниченный relay. Если сервер не исполняет запрошенный маршрут, он может при оговорённых условиях попытаться доставить прямо домену справа от последнего @.

Такое неравенство требований позволяет выводить механизм из обращения постепенно. Новые клиенты перестают создавать старые объекты, а очереди, шлюзы и программы установленной базы сохраняют способность их читать.

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

Совместимый parser не означает открытый relay

Сервер может безошибочно разобрать @ONE,@TWO:JOE@THREE и отказать в транзите по аутентификации, исходной сети, домену или антиабьюз-политике. Распознавание грамматики и разрешение расходовать ресурсы — разные проверки.

RFC 2821 объявляет source routes deprecated. Серверы должны быть готовы принять их синтаксис, обычно должны игнорировать маршрут и могут отказать в relay. Клиенты не должны продолжать его создавать.

Если маршрут игнорируется, имена промежуточных узлов не должны копироваться в reverse-path. Переход из RFC 821 относится к режиму, который действительно использует старый путь, а не к каждой современной SMTP-транзакции.

Если сервер в исключительном случае решает применить маршрут, он обязан отправить к первому указанному домену и не угадывать сокращение. Явное игнорирование или отклонение лучше поддаётся аудиту, чем молчаливая перестановка части списка.

Фраза «source route принята» поэтому неоднозначна. Принят синтаксис, получатель, право транзита или ответственность после DATA? Эти события происходят на разных границах.

Между почтовыми островами карта пользователя имела ценность

RFC 1711 в 1994 году описал явный source routing как включение желаемого MTA в адрес. Когда сообщение достигает MTA, тот удаляет себя и маршрутизирует остаток.

В мире редко связанных «почтовых островов» пользователь мог знать шлюз к далёкому сообществу, тогда как инфраструктура не распространяла такую достижимость автоматически. Запись маршрута компенсировала недостающую общую карту.

По мере взаимосвязности Интернета знание топологии конечным пользователем перестало быть необходимым в обычном случае и стало быстро устаревать. RFC 1711 также называет непоследовательную обработку разными реле причиной отказа от практики.

Это историческая оценка 1994 года, а не современная статистика. Она не доказывает одновременное исчезновение всех шлюзов и диагностических задач. Она фиксирует смену преимущества: статическая пользовательская карта из решения превратилась в источник рассогласования с динамической системой.

Percent hack, UUCP bang paths и шлюзовые преобразования находятся рядом исторически, но не являются тем же синтаксисом и не обязаны выполнять тот же переход forward/reverse. Здесь рассматривается форма @relay1,@relay2:user@host.

Грамматика пережила повседневное основание

RFC 5321 объясняет, что MX устранил регулярную потребность в явных маршрутах, а требование Fully Qualified Domain Names сняло последнее существенное общее оправдание. Клиенты не должны использовать форму, кроме необычных обстоятельств — например, диагностики или тяжёлой временной проблемы DNS.

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

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

Поэтому бинарное «поддерживается» скрывает важные состояния: распознано, сохранено, проигнорировано, отклонено, использовано. Кроме того, конечный домен может разрешиться или нет, а ответственность — быть отклонена в сессии или уже принята до последующей ошибки.

Написанный путь не является доказанным путём

Наличие @ONE,@TWO в базе подтверждает только строку. Без данных сессии нельзя утверждать, что ONE потребило шаг, TWO получило соединение или THREE приняло сообщение. Нужны ответы SMTP, конечные точки, DNS-решение, очередь и время.

Верно и обратное. Нормализованное JOE@THREE не доказывает, что таким был вход. Пограничный MTA мог удалить маршрут, коллектор — сохранить только разобранный ящик, а заголовки сообщения — никогда не содержать эти данные.

Надёжная запись сохраняет сырой аргумент, разбор, решение use/ignore/reject, следующий hop и результат. Нормализованное значение полезно как производная проекция, но не как незаметная замена полученному доказательству.

Даже reverse-path не удостоверяет реле. Он помогает вернуть ошибку, но не гарантирует единственный честный проход и владение каждым именем. Сила вывода не должна превышать определённую протоколом функцию.

Граница источников

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

Они также не превращают SMTP source route в IPv4 LSRR или SSRR. Сходство терминов не переносит слой, объект, обработчик, угрозу и полномочия.