Кратко

  • Обычное SMTP-письмо указывает reverse-path для будущих отчётов о доставке. Уведомление использует MAIL FROM:<>, чтобы его собственная недоставка не породила ещё одно уведомление и цикл.
  • Нулевой путь — допустимое значение конверта, а не отсутствие видимого From:, не доказательство добросовестности и не освобождение от проверок. Система должна принимать его осмысленно; HELO и SPF сохраняют возможность оценить отправляющий хост.
  • Структурированные DSN добавили корреляцию и статусы по каждому получателю, но сохранили конечного отправителя. Когда удалённый отчёт невозможен, ответственность сужается до локальной эксплуатации, а не исчезает.

После принятия сбой превращается во второе письмо

Пока SMTP-клиент подключён, сервер может отклонить адресата или сообщение отрицательным ответом. Клиент немедленно узнаёт результат, сохраняет ответственность и решает, что делать дальше. Новое письмо для объяснения сбоя не нужно.

Сложность появляется после положительного ответа на DATA. Получатель формально взял на себя доставку, дальнейшую пересылку либо последующий отчёт. Уже затем может выясниться, что следующая система недоступна, ящик удалён или раскрытие списка привело к несуществующему адресу. Исходного соединения больше нет. Факт отказа приходится оформить отдельным письмом и отправить на reverse-path исходного конверта.

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

RFC 821 распознал проблему ещё в 1982 году: relay, обнаруживший поздний отказ, должен сообщить исходному reverse-path, но не должен отправлять уведомления о проблемах с уведомлениями. Ограничитель записан как MAIL FROM:<>.

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

Пустое значение стало обязательной частью протокола

RFC 1123 усилил раннее решение: SMTP-хост обязан поддерживать пустой reverse-path. Нельзя считать MAIL FROM:<> синтаксической ошибкой только потому, что внутри нет обычного адреса.

Стандарт завершил и правило остановки. Уведомление о сбое, обнаруженном после принятия, должно иметь нулевой reverse-path. Если исходный адрес для такого уведомления уже нулевой, уведомление отправлять запрещено. Принятие и остановка — две стороны одной совместимости. Запрет всех нулевых отправителей уничтожает легитимные отчёты; ответ на нулевой адрес возвращает рекурсию.

Таким образом, пустота передаёт положительный смысл. Она отличает забытое поле от выбранного конечного состояния. Автоматизация, которая ради «полноты данных» подставляет видимый адрес вместо null, стирает именно тот сигнал, который удерживает систему в границах.

Конверт и заголовок участвуют в разных разговорах

Reverse-path существует в SMTP-транзакции. Видимый From: объясняет читателю автора или службу, а Reply-To: предлагает человеку направление осмысленного ответа. Автоматический отчёт может назвать оператора в заголовке From и одновременно использовать MAIL FROM:<> в конверте.

Это не противоречие: заголовки обслуживают человеческий диалог, а конверт распределяет машинную ответственность за недоставку. Программа, которая при пустом конверте копирует From или отвечает на Reply-To, повторно соединяет ребро, удалённое для защиты от цикла.

RFC 5321 связывает ответственность с положительным завершением DATA. Если отказ достоверно известен во время транзакции, ранний отрицательный ответ обычно безопаснее: его получает реальный подключённый клиент, а отдельный bounce не уходит на потенциально поддельный reverse-path.

Однако временный DNS-сбой, downstream-шлюз, асинхронная обработка или список рассылки могут раскрыть проблему лишь позже. Тогда отчёт необходим. Null ограничивает новую ветвь одним поколением.

От backscatter это полностью не защищает. Злоумышленник может подставить адрес жертвы в reverse-path обычного письма; принявший, а потом отказавший сервер отправит первый отчёт жертве. Нулевой отправитель остановит лишь отчёт об этом отчёте. Ранний отказ, авторизация узла и антиабьюз-политика контролируют соседние границы.

Конец удалённого отчёта не уничтожает местную обязанность

Если легитимный DSN сам не доставлен, внешняя цепочка должна завершиться. Но эксплуатационная неисправность остаётся. RFC 5321 допускает локальное журналирование или передачу сведений о сбое сообщения с нулевым адресом и упоминает postmaster, способного исправить почтовую систему.

Локальная эскалация не должна создавать новый внешний DSN. Удалённый отчёт возвращает результат стороне, назвавшей reverse-path. Внутренний сигнал говорит оператору: «наш конечный отчёт тоже не дошёл; проверьте очередь, маршрутизацию и конфигурацию». Протокол не скрывает ошибку, а назначает владельца последней стадии.

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

DSN уточнил содержание, не открыл обратный путь

Ранние уведомления представляли собой разнородный человеческий текст. Машинам было трудно сопоставить его с транзакцией и отдельным адресатом. RFC 3461 добавил SMTP-расширение Delivery Status Notifications. ENVID несёт выбранный идентификатор конверта, RET управляет возвратом исходного содержания, ORCPT сохраняет адрес до переписывания. NOTIFY выбирает SUCCESS, FAILURE или DELAY, а отдельное значение NEVER запрещает отчёт.

Параметры выражают пожелания к отчётности, а не меняют допустимость MAIL или RCPT. Они не сильнее терминального инварианта: MTA не создаёт DSN для сообщения с нулевым MAIL FROM, даже если в заголовках находится правдоподобный отправитель.

Передаваемый DSN сам использует нулевой адрес. В его транзакции не применяется RET; если присутствует NOTIFY, допустим только NEVER. Внутри может быть подробное свидетельство о доставке, но требование свидетельства о самом отчёте равно нулю.

RFC 3464 определил DSN как multipart/report типа delivery-status: читаемое человеком объяснение, машинную часть message/delivery-status и, когда позволяют правила возврата и приватности, материал исходного сообщения.

Один DSN относится ровно к одному исходному сообщению, но содержит отдельные блоки для нескольких получателей. Action различает failed, delayed, delivered, relayed и expanded; Status даёт структурированный код. Частичная доставка больше не сводится к фразе «письмо не доставлено»: один адрес может быть успешен, другой ждать повторов, третий окончательно отказать.

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

Автоответчикам нужен тот же конечный сигнал

Циклы возникают не только у отчётов доставки. Отпускные ответы, групповые сервисы, helpdesk и обработчики контента способны активировать друг друга. RFC 3834 обобщает правило: автомат не создаёт ответ, адресатом которого был бы null, и обычно ориентируется на Return-Path конверта, а не угадывает по человеческим From или Reply-To.

Автоматический ответ, которому не нужен ответ, может использовать MAIL FROM:<>; при наличии DSN-расширения уместен NOTIFY=NEVER. Но прекращение цикла не доказывает согласие. Обратные адреса легко подделать, поэтому сервис не должен слать крупный ответ или вызывать побочное действие без основания считать запрос авторизованным.

На этапе submission RFC 6409 запрещает отклонять сообщение только из-за нулевого пути. Легитимные клиенты создают такие письма, включая некоторые уведомления о диспозиции. MSA всё равно проверяет учётную запись, полномочия, скорость и содержание. Зарезервированный статус надо понимать, а не слепо доверять ему.

Почтового ящика нет, но хост остаётся проверяемым

SPF обычно оценивает домен MAIL FROM. Для null RFC 7208 строит MAIL-FROM identity как postmaster в домене HELO identity. У отправляющего хоста остаётся поверхность авторизации, хотя ящика отправителя нет.

Результат не удостоверяет тело DSN, сам факт отказа или личность человека. Авторизованный хост способен создать неверный отчёт, а верный отчёт может пострадать от настройки. Правило показывает лишь, что пустой reverse-path не отменяет все оценки происхождения.

Null MX означает другое. Он объявляет в DNS, что домен не принимает почту. Нулевой reverse-path находится в конверте уже передаваемого письма и закрывает отчётную ветвь одной транзакции. Один механизм закрывает вход домена, второй — рекурсию ошибок.

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

Первоначальный отчёт о недоставке и ограничитель MAIL FROM:<> описаны в RFC 821: https://www.rfc-editor.org/rfc/rfc821.html

Обязательная поддержка пустого пути и запрет уведомления нулевого адреса находятся в RFC 1123: https://www.rfc-editor.org/rfc/rfc1123.html

Параметры DSN, обработка нулевого отправителя и NOTIFY=NEVER находятся в RFC 3461: https://www.rfc-editor.org/rfc/rfc3461.html

Структурированный multipart DSN, поля по сообщениям и адресатам и пределы приватности находятся в RFC 3464: https://www.rfc-editor.org/rfc/rfc3464.html

Правила отпускных, групповых и сервисных автоответов находятся в RFC 3834: https://www.rfc-editor.org/rfc/rfc3834.html

Современная передача ответственности SMTP, классы null-сообщений и локальный путь postmaster находятся в RFC 5321: https://www.rfc-editor.org/rfc/rfc5321.html

Легитимный null при submission находится в RFC 6409: https://www.rfc-editor.org/rfc/rfc6409.html

HELO-идентичность SPF при нулевом reverse-path находится в RFC 7208: https://www.rfc-editor.org/rfc/rfc7208.html

Эти RFC устанавливают требования протокола, но не подлинность конкретного DSN и не сегодняшнюю практику провайдеров. Статья не утверждает текущие объёмы bounce, спама, отказов или внедрения.