Кратко

  • В раннем SMTP команды VRFY и EXPN служили диагностическими окнами: положительный ответ мог открыть один ящик или перечислить всех участников списка рассылки.
  • Код 252 создал честное третье состояние: сервер не подтверждает пользователя, но может принять сообщение и попытаться доставить его. Раскрытие справочника, принятие транспортной ответственности и итог доставки остаются разными фактами.

Когда почтовый сервер отвечал как справочник

RFC 821 предлагал предельно наглядный диалог. На VRFY Smith сервер мог ответить кодом 250, полным именем Фреда Смита и его почтовым ящиком. Если он знал адрес пересылки, то сообщал его. Если совпадений не было, говорил об этом. Если Смитов было несколько, требовался ответ 553 User ambiguous.

Соседняя команда EXPN шла дальше. Клиент называл список рассылки, а успешный многострочный ответ перечислял входящие в него ящики по одному на строке. Спецификация не считала это приблизительной подсказкой: успех VRFY обязан был содержать ящик, успех EXPN — адреса списка. Локальное знание становилось протокольным свидетельством для удалённого собеседника.

Польза была практической. Опечатку можно было найти до отправки. Пересылка становилась видимой. Вложенные расширения списка можно было проследить до петли. Раз справочник и доставка опирались на одно знание, диагностика внутри SMTP выглядела разумно.

Но диагностическое окно находилось на публичном почтовом сервисе.

У полезного ответа появился другой потребитель

В 1989 году RFC 1123 усилил диагностическую функцию: принимающая сторона обязана была реализовать VRFY и должна была поддерживать EXPN, хотя конкретная установка могла отключить обе команды или отдельные списки. Документ удерживал обе стороны вопроса. Администраторы регулярно применяли команды для поиска проблем доставки и циклов многоуровневых списков, но раскрытие списков создавало риск для приватности и безопасности.

С массовой нежелательной рассылкой тот же интерфейс получил новую ценность. VRFY проверял словарь предполагаемых имён, а EXPN превращал один идентификатор в множество адресов. RFC 2505 рекомендовал контролировать вызывающих с помощью общего переключателя или списков доступа. Для отключённого либо заблокированного VRFY стандартным ответом должен был стать 252, а EXPN следовало по умолчанию выключить.

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

Третий правдивый ответ

Если оставить только «да» и «нет», серверу пришлось бы выдумывать знание. 250 после одной проверки синтаксиса изображает верификацию, которой не было. Постоянный 550 изображает отсутствие пользователя. RFC 5321 считает оба поведения несоответствующими спецификации.

252 снимает ложный выбор: «Невозможно VRFY пользователя, но сообщение будет принято и будет предпринята попытка доставки». Код не доказывает существование ящика. Он не обещает, что всякий будущий RCPT TO будет принят, и тем более не подтверждает получение человеком. Сервер только не может либо не желает сделать запрошенное утверждение справочника, сохраняя обычный путь передачи.

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

Та же семантика работает при защите. RFC 5321 требует 252, если сайт отключает команды по соображениям безопасности: ответ не должен быть похож ни на положительную, ни на отрицательную проверку. Отказ раскрывать сведения не доказывает отсутствие пользователя.

Проверка, приём и доставка создают три записи

Почтовые системы часто склеивают соседние состояния. Допустимый синтаксис становится «проверенным адресом». 250 на одном переходе превращается в «доставлено». Заблокированный запрос записывается как «ящик недействителен». Частичное наблюдение каждый раз получает лишние полномочия.

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

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

Закрытое окно не означает отсутствия других

Отключение VRFY не убирает всю информацию о получателях. RFC 5321 отмечает, что ответы на RCPT иногда выдают те же сведения. В других системах проверка отложена до получения DATA, поэтому RCPT почти ничего не сообщает. Дополнительная защита зависит от всей цепочки приёма.

Нельзя объявлять победу лишь потому, что один глагол отвечает 252. Политика закрывает самый дешёвый прямой запрос, но различия в кодах, времени ответа, домены catch-all и поздние возвраты всё ещё могут давать сигналы. Следует испытывать совокупную поверхность.

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

Диагностика сохранилась внутри границы

RFC 5321 оставляет обеим командам законную роль. Аутентифицированные пользователи и администраторы в одном домене могут проверять маршруты, находить непреднамеренную пересылку чувствительной почты и исследовать списки. Сайт вправе открыть команды только удостоверенным запросам. Функция остаётся, а предполагаемое право анонима исчезает.

Текущий реестр SMTP IANA обозначает ещё одну границу. Поддержка VRFY обязательна для серверов, но его присутствие в списке EHLO необязательно. VRFY и EXPN отмечены как MUST NOT для Message Submission. Аутентификация ради отправки своей почты не даёт автоматического доступа к справочнику принимающей системы.

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

Источники