Кратко

  • 251 успешно завершает старый RCPT TO и возлагает дальнейшую пересылку на принимающий сервер; 551 отказывает и передаёт отправителю выбор нового адреса или ошибки.
  • Поздние стандарты сохранили ответственность без обязательного раскрытия: 250 для тихой пересылки, 550 для отказа без замены.
  • Исправленный путь не удостоверяет человека и не переименовывает его глобально. Для постоянной записи нужны подлинность сервера и отдельное право на изменение адресной книги.

Одинаковое знание не означает одинаковую обязанность

Клиент предъявляет устаревшего получателя. При 251 сервер принял его в текущей транзакции и отвечает за дальнейший путь. При 551 получатель не принят, даже если текст содержит точный новый ящик.

Если панель сводит оба события к «пользователь переехал», она теряет состояние. После 251 повтор на предложенный адрес может создать дубль. После 551 ожидание скрытой пересылки оставит сообщение без хозяина. Адрес — подсказка, код — запись о передаче ответственности.

Две ветви исходного SMTP

RFC 821 ввёл ответы в 1982 году для случая, когда forward-path неверен, но принимающий SMTP знает правильное назначение. Мог измениться хост, локальная часть или оба компонента.

251 User not local; will forward сообщал путь на будущее и утверждал, что сервер отвечает за текущую доставку. 551 User not local; please try отказывался принимать почту; отправитель должен был перенаправить её или вернуть ошибку инициатору.

Спецификация не объявляла новый идентификатор пользователя. Она определяла, продолжилась ли текущая транзакция на этой стороне и кто теперь обязан действовать.

Настоящее принятие и будущий справочник

Клиент может не сохранить замену и всё же выполнить протокол. 251 означает, что старый получатель принят сейчас. 551 означает, что попытка по новому пути будет отдельным решением. Одноразовый retry, показ человеку и постоянная замена контакта имеют разные последствия.

RFC 5321 запрещает серверу рассчитывать, что клиент обновит адрес или даже покажет его пользователю. Сервер авторитетен относительно собственного принятия, но не относительно всех удалённых каталогов.

Так короткая сессия не получает неявного права на запись, которая переживёт её на годы.

Переслать и не раскрыть

К моменту RFC 2821 silent forwarding стал обычным. Организация могла сохранять публичный адрес и скрывать внутренний ящик; человек мог направить старую учётную запись в частную новую. Конечное назначение иногда вообще недоступно отправителю напрямую.

Поэтому принятие отделилось от раскрытия. Принимающий сервер может вернуть 251 с заменой или молчаливый 250. Отказывающий может дать 551 с рекомендацией или 550 без адресных сведений. RFC 5321 требует механизмов ограничения раскрывающих ответов.

Получаются четыре честных состояния: принять и назвать, принять и скрыть, отказать и назвать, отказать и скрыть. Политика конфиденциальности убирает карту, но не искажает итог транзакции.

Переезд без публичного назначения

RFC 3463 определил X.1.6: целевой ящик перемещён, адрес пересылки отсутствует. Текущий реестр расширенных кодов SMTP IANA сохраняет это описание как постоянную ошибку.

Замены может не быть; сервер может её не знать или не иметь права раскрывать; адрес может работать лишь внутри системы пересылки. Сам факт переезда не разрешает клиенту угадывать назначение по заголовкам, старым трассам или чужому каталогу.

RFC 3464 проводит ту же границу для DSN. Уведомления подделываются так же легко, как обычная почта, а пользователь может автоматически пересылать сообщения, не желая раскрывать конечный адрес. Реализациям следует защищать такую конфиденциальность. Сообщение движется дальше, но полная схема не обязана возвращаться автору.

Машиночитаемое исправление стало поверхностью атаки

Обычно SMTP-клиент действует по цифрам и может игнорировать свободный текст. Путь в 251 и 551 — исключение, если программа хочет его применить. Значит, подмена строки способна проникнуть в будущую маршрутизацию.

RFC 5321 предупреждает: перед автоматическим изменением поведения, например адресной книги, клиенту следует убедиться в подлинности сервера. Посредник может вставить свой ящик. Сохранённое «исправление» переживёт соединение и уведёт последующие сообщения.

Но и подлинный ответ не доказывает человеческую тождественность. Он показывает, какой сервер высказался, а не что новый ящик принадлежит тому же человеку, что перемена вечна или что администратор вправе менять канонический контакт пользователя. Подлинность источника не равна полномочию именования.

Alias меняет конверт, а не авторство

RFC 5598 отличает обычный MTA relay от alias. Relay приближает сообщение к назначению, не меняя envelope-адреса. Alias на стороне получателя повторно направляет его одному или нескольким альтернативным получателям, сохраняя содержание и обычно MailFrom.

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

Пересылка перераспределяет операционный риск, не переписывая автоматически видимый To, Message-ID или личную идентичность. 251 и 551 — локальные утверждения об envelope, не глобальное переименование.

Ограниченная коррекция оказалась устойчивой

История разделила четыре решения: принять, переслать, раскрыть и запомнить. Поздняя защита приватности уменьшила выдаваемые сведения, сохранив точную границу custody.

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