Кратко

  • RFC 1846, опубликованный в сентябре 1995 года, описал специализированные узлы, которые никогда не принимают почту. Без SMTP-службы отправитель мог счесть неудачное соединение временным отказом, держать ошибочное письмо в очереди и повторять доставку днями. Экспериментальный код 521 позволял MX-посреднику или маленькому серверу сразу дать окончательный ответ.
  • Авторы заметили, что некоторые существовавшие клиенты после 521 и немедленного разрыва соединения снова ставили письмо в очередь, но возвращали его отправителю, если сервер ждал команды QUIT. RFC 7504 2015 года официально закрепил 521 для узла, который не принимает почту никогда, и ввёл 556 для посредника, заранее знающего, что домен назначения не принимает письма.

Отсутствие ответа было работой для чужой очереди

Повторная отправка — полезное свойство почты. Если получатель временно недоступен, письмо дождётся восстановления. Но Alain Durand и Francis Dupont указали в экспериментальном документе 1995 года на другой случай. Интернет состоял уже не только из универсальных машин: отдельные узлы занимались DNS, NTP и другими специализированными задачами. Почту они не принимали. Человек при этом мог ошибочно набрать адрес с именем такого узла.

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

SMTP в редакции 1982 года был разговором отправителя и получателя: подключение, команды, числовые ответы, действия в зависимости от результата. В 1995 году инженеры предложили добавить ответ для случая, который молчание не объясняло: этот узел не принимает почту вообще. Так появился экспериментальный код 521. Его цель состояла не в создании почтового ящика, а в прекращении поисков ящика, которого никогда не будет.

Произнести отказ можно было в двух местах. MX-посредник отвечал 521 после указания адресата в сеансе SMTP. Или сам непочтовый узел запускал минимальный SMTP-сервер, отклоняющий всякое письмо. При первом устройстве посредник говорил от имени узла; при втором узел говорил за себя. В обоих случаях кто-то брал на себя ответственность за слово «никогда». Без этого слова отправляющая система продолжала гадать, перед ней политика или обычная поломка.

Ответы посредников должны совпадать. RFC 1846 рекомендовал: если один MX отклоняет почту от имени такого узла, MX с более низким приоритетом тоже должен её отклонять. Иначе первый маршрут заканчивается окончательным отказом, а второй возвращает отправителя к бесполезным попыткам. Одной правильно настроенной двери мало, если опубликованы и другие.

Слишком быстрый отказ выглядел как обрыв связи

Минимальный сервер мог сразу после подключения произнести 521, затем своё официальное имя или IP-адрес. Дальше он мог разорвать соединение. Другой вариант — продолжать читать команды, отвечать 521 на все, кроме QUIT, и ждать завершения разговора. Узел с таким приветствием нельзя было указывать в MX-записи какого-либо домена: объявлять себя почтовым приёмником и одновременно заявлять, что почту он никогда не принимает, означало бы дать отправителям противоречивые указания.

Разница между двумя способами завершить сеанс оказалась существенной. Авторы RFC сообщили, что некоторые SMTP-клиенты после 521 и немедленного отключения считали событие временным сбоем и снова ставили письмо в очередь. Если сервер оставался на связи, эти клиенты посылали QUIT и возвращали письмо человеку. Число 521 и смысл отказа не менялись. Порядок окончания разговора менял то, что реально делала уже установленная программа. Можно выдать верный ответ и всё равно получить новые попытки доставки.

Так непочтовой машине доставалась крошечная почтовая обязанность: быть доступной, правильно назвать себя, сообщить постоянный отказ и иногда подождать прощальной команды. Она по-прежнему не хранила ни одного письма. Именно эта работа спасала другие системы от хранения заведомо недоставимого сообщения. Сервер отказов звучит нелепо, пока не посчитать дни, которые тратит очередь при полном отсутствии ответа.

В 1995 году RFC 1846 имел экспериментальный статус и просил разработчиков делиться опытом внедрения. Описание «некоторых» клиентов, повторяющих попытки после быстрого разрыва, говорит о несовместимости, а не о числе затронутых программ или писем. Для подсчёта тогдашнего масштаба понадобились бы журналы очередей или исследование реализаций. Само различие уже установлено: запись 521 в журнале принимающей стороны не доказывает, что отправляющая сторона перестала пытаться.

Через двадцать лет отказ стал точнее

RFC 7504, вышедший в июне 2015 года, включил 521 в SMTP как стандартный ответ. Документ сообщал, что код к тому времени широко использовался, хотя формально ещё не был включён в базовый протокол. Теперь его назначили началу соединения с узлом, который не принимает почту ни при каких обстоятельствах. Более общий отказ 554 может относиться к отдельному отправителю, адресу или обстоятельству. Код 521 говорит о постоянном отсутствии самой услуги на этом узле. RFC 7504 завершил эксперимент, начатый в 1995 году.

К тому времени сказать «здесь нет почты» можно было ещё до подключения к узлу. RFC 7505 описал null MX — запись DNS, объявляющую, что домен не принимает почту. Если MX отсутствует, отправитель может обратиться к адресу A или AAAA и попытаться подключиться к машине, которая ведёт веб-сайт или другой сервис, но не обслуживает почту. Null MX сообщает решение на уровне домена и избавляет от необходимости запускать отдельный SMTP-сервер только ради отказов.

В RFC 7504 появился и код 556. Промежуточная почтовая система, узнавшая, например из null MX, что домен адреса пересылки не принимает письма, может ответить предыдущему узлу без подключения к конечной машине. Код 521 произносит узел при открытии соединения. Код 556 произносит посредник, который заранее знает правило домена. Цель похожа — остановить бесплодные попытки, но знание находится в разных местах пути.

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