摘要

  • RFC 9873 允许 EPP 联系人在 RFC 5733 的基础邮箱之外再保存一个 ASCII 或 SMTPUTF8 地址，并可将新增地址标为首选。
  • 首选标记只规定处理次序；协议协商、字段存储、SMTP 传输、转发、收件人动作和 RDAP 公开展示分别需要证据。

如果新增地址已经是“首选”，为什么原有地址还必须保留？答案就在 RFC 9873 的边界里：扩展为 RFC 5733 联系人增加一个地址，而不是重写基础映射。它适合在 ASCII 与 SMTPUTF8 之间提供另一条联络路径，却没有权力把两条路径合并成一个经过验证的人。

两个地址甚至可能交叉工作。发送到其中一个地址的邮件可以被转发到另一个地址，回复也可能从不同地址或不同文字系统返回。因此，字符串变化既不能自动证明身份变化，也不能自动证明身份相同。primary=true 只告诉扩展联系人处理逻辑优先使用哪一个地址，不会触发邮箱探测。

协议首先要求双方证明处理能力。RFC 5730 的问候与登录协商承载扩展命名空间。协商成功后，客户端和服务端必须能够接受、校验、保存并返回新增地址，并在收发邮件时支持 SMTPUTF8；若会话开始时没有成功协商，双方都不得提供或返回扩展数据。这项证据严谨，却只覆盖 EPP 会话。

空元素也有明确状态：在更新时表示取消新增地址，在查询时表示该地址不存在；空元素不能带首选属性。非空值则只证明字段有值。它不证明 MX 可用、邮箱已建立、转发配置正确、SMTP 接收成为最终送达、收件人阅读了内容，或回复者就是预期主体。

国际化地址还带来显示相似与存储差异。RFC 6530 给出国际化邮件框架，RFC 6531 定义 SMTPUTF8 扩展。RFC 9873 建议限制本地部分字符集合，要求域名符合 IDNA2008，并测试复杂组合序列的保存与返回。RFC 5895 处理用户界面映射，IANA IDNA 表 列出代码点状态。语法通过不等于两种视觉形式在人类判断中等价。

隐私规则没有因为字段新增而分叉。基础联系人的邮箱披露设置必须覆盖所有新增邮箱。与此同时，EPP 存储与公开目录是不同层。新增地址可以像基础地址一样进入 RDAP 处理，而 STD 95 并不要求逐字公开所有存储值。ICANN 的 2026 年联络表单通告 说明特定政策环境下可以使用匿名化地址或网页表单；它不是 RFC 9873 已部署的证明。

Heng Lu 的现实分层论要求把协商能力、配置值、规范化结果、存储值、披露决定、SMTP 尝试、传输结果、收件人动作与公开投影分别记账。最小初始规范支持这类边界清楚的小型互操作协议，同时保留本地字符、验证与公开政策。运行代码优先则要求每一层都留下可重放记录。

RFC 9873 的价值正在于它没有假装一个字段能完成整条通信链。真正的管理风险，是下游系统把“首选”显示成“已验证”，把 SMTP 接受当成“已通知”，或让新增地址绕开与基础地址共用的披露决定。

来源