Кратко

  • RFC 9873 определяет расширение команд и ответов EPP для связи дополнительного адреса с объектом контакта.
  • Адрес может быть ASCII или интернационализированным SMTPUTF8; primary обозначает предпочтение в пределах расширения.
  • Пустой элемент addlEmail снимает второй адрес, и при такой операции primary присутствовать не должен.

Полномочия протокола здесь ограничены. RFC 5730 задаёт структуру команд и ответов EPP, RFC 5733 описывает объекты контактов и раскрытие данных, а RFC 9873 добавляет элемент дополнительного адреса и правила обновления. Флаг раскрытия контакта распространяется и на дополнительный адрес, поэтому оба поля должны обрабатываться согласованно. Согласованная поддержка требует обработки ASCII- и SMTPUTF8-адресов, а также поддержки SMTPUTF8 при отправке и получении почты. Контекст интернационализированной почты описан в RFC 6530 и RFC 6531.

RFC устанавливает модель данных и поведение протокола. Она не проверяет владение ящиком и не гарантирует доставку. Из неё не следует, что SMTPUTF8 повсеместно развернут у всех реестров и регистраторов. Пометка адреса как основного автоматически не меняет каждый последующий процесс реестра. Второй адрес не устраняет все проблемы приватности, контактов для злоупотреблений или переноса домена. Наконец, одна RFC не даёт оснований утверждать что-либо о внедрении, производительности, инцидентах или развертывании у конкретного оператора.

Политика должна учитывать смешение похожих символов Unicode, синтаксис почтового домена и достижимость адреса. Это отдельные проверки, а не гарантия, встроенная в EPP.

Источники