Кратко

  • RFC 9873 добавляет к базовому адресу контакта ещё один ASCII- или SMTPUTF8-адрес и позволяет предпочесть его, не удаляя исходное поле.
  • Согласование EPP доказывает способность двух узлов обработать значение; доставка, ответ, личность и публичное отображение требуют иных свидетельств.

В RFC 5730 есть чёткая точка согласования: сервер объявляет возможности в greeting, клиент выбирает расширения при login. Если стороны договорились о RFC 9873, они обязаны принимать, проверять, хранить и возвращать дополнительный адрес, а также поддерживать SMTPUTF8 при отправке или получении почты. Без согласования расширенные данные не должны передаваться.

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

Базовый адрес из RFC 5733 остаётся в контакте. Расширение добавляет ровно один адрес ASCII или SMTPUTF8. Необязательный primary определяет предпочтительный способ обработки расширенного контакта, но не вытесняет базовое значение и не создаёт квитанцию.

Пустой элемент, напротив, имеет исчерпывающий смысл: при обновлении он снимает дополнительный адрес, а при чтении сообщает об отсутствии. Атрибут primary при пустом элементе запрещён. Непустая строка говорит о состоянии записи, а не о доступности получателя.

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

Для Unicode важны ограничения и обратимость. RFC 6530 задаёт общую архитектуру, RFC 6531 — расширение SMTP. RFC 9873 рекомендует ограничивать наборы знаков, проверять домен по IDNA2008 и испытывать хранение сложных комбинируемых последовательностей. RFC 5895 касается преобразований в интерфейсе, а таблицы IANA IDNA фиксируют статус кодовых точек. Технически допустимое написание всё равно может быть визуально обманчивым.

Правило раскрытия общее для обоих адресов: настройка базового email должна применяться и к дополнительному. Публичное представление остаётся отдельным решением. Адрес может обрабатываться в RDAP в рамках STD 95, но стандарт не требует дословно публиковать каждое значение EPP. Рекомендация ICANN 2026 года даёт контекст для псевдонимизированных адресов и веб-форм, а не свидетельство внедрения RFC 9873.

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

RFC 9873 не обещает больше, чем способен измерить. Ошибка управления возникает позже: primary превращают в «проверено», приём SMTP — в «уведомлен», а публичную форму — в доказательство раскрытия сохранённого адреса.

Источники