Кратко

  • RFC 5335 разрешал экспериментально сопровождать не-ASCII mailbox адресом-альтернативой в ASCII. Если следующий SMTP-узел не поддерживал нужную возможность, downgrade мог выбрать альтернативу, хотя она могла вести в другой ящик или к другому человеку.
  • RFC 6530 подвёл итог: связь адресов нельзя было надёжно аутентифицировать, ранние реализации сталкивались с interoperability-проблемами, а долгосрочная сложность была чрезмерной. RFC 6532 заменил RFC 5335 и опирается на нативный end-to-end UTF-8 без downgrade в транзите.

Видимый отказ сохранил бы больше правды

Сообщение адресовано международному mailbox. Маршрут доходит до узла без необходимой возможности. Система может вернуть ошибку: заданный адрес нельзя перенести по доступному пути. Это неудобно, зато точно.

Экспериментальная альтернатива обещала более приятный результат. В envelope уже есть ASCII-адрес, поэтому агент подставляет его и продолжает доставку. Отказ исчезает. Но вместе с ним исчезает важный факт: первоначальный адрес не был доставлен.

RFC 5335 прямо допускал, что ASCII и не-ASCII варианты ведут в разные ящики или принадлежат разным людям. Выбор мог зависеть от capability почтовых агентов на пути. Тогда успешная доставка означает лишь, что сообщение принял второй адрес. Она не означает сохранение первоначального получателя.

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

Пара адресов была записью, а не мандатом

RFC 5335 расширял значения заголовков до UTF-8, сохраняя сами имена полей в ASCII. Международный mailbox мог содержать дополнительный ASCII адрес. Формат показывал, что две строки связаны.

Он не показывал, кто создал связь и имел ли создатель право объявить адреса взаимозаменяемыми. Не было встроенного срока, доказательства контроля, области применения или события отзыва.

Это критично для local-part. Его смысл задаёт принимающий домен; он не является свободно переводимым именем. Транслитерация может принадлежать другому аккаунту. Старый alias может быть повторно выдан. Адрес в другом домене находится под другой администрацией.

Поэтому пару нужно рассматривать как claim. Для неё требуются issuer, подтверждение контроля, разрешённые операции, дата проверки, текущий владелец и отзыв. Без них система знает лишь, что кто-то записал два идентификатора рядом.

Подход Lu Heng отделяет полезную функцию учёта от власти над объектом учёта. Держатель записи координирует данные, но не становится владельцем описанного principal. SMTP-узел тем более не получает такого права из-за собственной технической несовместимости.

Новый домен делал замену видимой

RFC 5504 описывал downgrade envelope через ALT-ADDRESS. Не-ASCII path заменялся декодированным ASCII вариантом. Если домен менялся, текущая SMTP-сессия могла перестать соответствовать цели; агент должен был разрешить новый домен и выбрать подходящее соединение.

Так совместимость переносила сообщение через административную границу. Менялись оператор, хранение, фильтрация, доступ и потенциально юрисдикция. Триггером оставалось отсутствие одной capability у следующего hop.

Capability даёт право узлу принять или отклонить формат. Она не даёт права определить другого человека. Безопасная система ищет поддерживаемый маршрут, возвращает решение submission-системе под контролем отправителя или останавливается. Проверенную альтернативу применяет тот, кто способен доказать полномочие, а не случайный посредник.

Downgraded-* сохранял часть истории, но не её законность

Чтобы не потерять исходные значения, RFC 5504 вводил поля Downgraded-*. Они помогали увидеть преобразование. Однако поле могло быть вставлено недоверенным участником, некоторые алгоритмы теряли информацию, а изменение заголовков влияло на подписи.

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

В multi-recipient транзакции возникал конфликт с приватностью. Сохранение исходного адреса одного получателя в общем заголовке могло раскрыть его остальным. Поэтому Downgraded-Rcpt-To в такой ситуации запрещался. Правильная защита приватности означала, что финальный объект не всегда содержал полную цепочку.

Нужны разные receipts: исходный envelope, наблюдаемая capability, исполнивший агент, авторизующая policy, выбранный адрес, смена домена, новый маршрут, ответ SMTP и состояние mailbox. Ни один заголовок не заменяет их совокупность.

Эксперимент измерил скрытую сложность

RFC 5335 вышел как Experimental в 2008 году. RFC 6532 заменил его в 2012-м. RFC 6530 объяснил архитектурный сдвиг: ранняя серия поддерживала downgrade в транзите и практически требовала ASCII-эквивалентов. Пары нельзя было аутентифицировать удовлетворительно. Первые реализации не достигли надёжной совместимости. Требования и долговременные последствия оказались слишком сложными.

Стандартная серия отказалась от downgrade в пути. RFC 6532 использует нативные UTF-8 заголовки end-to-end в 8-bit-clean среде, гарантированной транспортом, и требует SMTPUTF8 для SMTP. Она не обещает пересечь legacy 7-bit сегмент, назначив другого получателя.

Это не поражение интернационализации. Эксперимент обнаружил, что «ASCII-эквивалент» был не функцией кодирования, а пакетом полномочий. Чтобы сохранить смысл, механизм должен был подтвердить principal, согласие, маршрут, приватность, подписи и audit trail во множестве реализаций.

Современные alias, recovery и migration-системы сталкиваются с тем же риском. Связь идентификаторов не равна тождеству. Тождество не равно разрешению на конкретную доставку. SMTP acceptance не равен получению исходным человеком. Надёжность начинается с аутентификации binding до кризиса и заканчивается видимым отказом, если continuity доказать нельзя.

Источники