摘要

  • RFC 3191 把全球电话网地址的最小表示放进邮件地址的本地部分，但只有负责 @ 右侧域名的 MTA 才能解释业务选择符、号码和限定符；中继邮件系统只能承载，不能擅自执行。
  • 标准刻意把“长得合法”与“实际送达”分开：视觉分隔符没有操作意义，未知限定符可以不执行却不得删除，多项子地址必须展开成多个邮件收件人，而 DNS 和 SMTP 成功都不是电话身份或终端收件的证明。

最容易误读的不是号码，而是权限

互联网邮件与电话业务相接时，工程师并不缺少把数字塞进地址的方法。语音、传真和短消息网关各自都能发明一套写法。真正困难的是：一串看起来人人都读得懂的字符，究竟允许谁来决定它的含义？

RFC 3191 在 2001 年给出的答案很克制。@ 左侧由业务选择符、等号和电话号码表示构成，还可以附加登记过的限定符；@ 右侧是网关域名。这不是把全球交换电话网整体搬进 SMTP，而是为已有网关提供一层最小的共同外壳。

普通邮件规则在这里仍然有效：一个域名的本地部分只归负责该域名的 MTA 解释。中途服务器即使看见 VOICE=+...，也不能因为自己认得英文和数字就把它当成可执行命令。它的职责是传输。右侧域名才选择有权读取左侧内容的网关。

因此，号码形状并不等于身份。它不证明订户是谁，不证明号码已经分配，也不证明所请求的业务可用。域名同样不为这些事实背书。整条地址只表达“把这项表示交给这个解释者”，而不是“电话世界已经发生了这件事”。

最小格式不替电话系统作真实性判断

全球形式以 + 开头，随后是数字，也允许为人眼分组而加入点号或连字符。合规实现必须忽略这些分隔符，发送端则不应主动生成它们。换言之，视觉排版可以不同，操作上却仍是同一个最小号码表示。

加号的地位不同。它专门标记全球形式。网关可以另行支持本地或专用拨号计划，但那些计划不能借用加号假装具有全球意义。RFC 3191 保护的是一个命名边界，而不是替所有电话制度完成号码规范化。

业务选择符由字母、数字和连字符组成，比较时不区分大小写。文档使用 VOICE、FAX、SMS 等例子展示结构，却明确警告：示例未必是有效地址。语法通过只说明字符串符合约定，不说明号码存在、设备在线、服务获准或资费可接受。

这种限制不是缺口，而是标准的责任边界。它规定可以向网关递交什么，不把自己伪装成全球电话目录。

不理解一个限定符，不代表可以抹掉它

最小号码后面可以增加限定元素：斜杠、限定名、等号和值。后续规范因此能为特定业务补充信息，不必每出现一种需求就重写共同核心。

只实现最小规范的系统可以不执行自己不认识的限定符，但 RFC 3191 要求它保留所有收到的限定元素。这里存在一个重要的不对称：忽略只是承认当前处理者能力有限；删除则会把它的局部无知变成后续所有系统都无法逆转的决定。

保留原字段，意味着更下游、具备相应知识和权限的网关仍能看到发送者的意图。若提前删掉，后来者只会收到一条被悄悄改写的指令，而且无法知道丢失发生在哪里。

业务选择符和限定符的扩展还要进入登记体系。规范必须持久可用，并足以让第三方独立实现；限定符也可以声明适用范围。登记协调了共同词汇，却不保证任何特定网关已经实现该能力。注册记录不是部署证明。

兼容旧痕迹，不等于鼓励继续制造痕迹

完整对象仍是互联网邮件的 addr-spec，受邮件引用规则约束。RFC 3191 还接受包围电话结构的可选斜杠，因为 X.400 等其他网关路径可能留下这种转换痕迹。

接收方必须接受，新的发送方不应生成，转换过程中则可以移除。这个三段式规则很精确：旧消息不能因历史痕迹而被拒收，但历史痕迹也不应被奉为新的规范形式。

RFC 3191 本身也体现了这种兼容观。它取代 RFC 2303，把 PSTN 中的 Public 改述为 GSTN 中的 Global，因为电话产业已不再符合“一个或少数公共运营商”的图景；但部分旧 ABNF 变量名继续保留，以免无谓破坏已部署实现。制度描述可以更新，线上的兼容标识不必为了整洁而全部改名。

一个电话号码可能必须拆成多个邮件收件人

同一个电话邮箱可以带有多个子地址。邮件系统却以收件人为单位接受、失败和重试。RFC 3191 因而规定：若存在多项子地址，就要生成多个 pstn-email 元素。

用户界面可以让人一次输入多项内容，但交给 MTA 时必须成为独立收件人。这种展开保住了结果的可归因性。一项被接受、另一项被拒绝时，邮件信封仍能区分两者，而不是把所有状态压在一个不透明地址里。

拆分并不保证电话端成功。两个邮件收件人可以都被 SMTP 接受，网关却只解析其中一个；网关也可以全部接收，电话终端却没有任何响应。邮件信封、SMTP 回执、网关解析、电话网交接和设备收件是五种不同证据。

DNS 只能证明路由选择的一部分

右侧域名决定邮件如何寻找网关，因此 RFC 3191 的安全讨论把 DNS 操纵列为重要风险。被攻陷的服务器、伪造的回答或受污染的附加数据，都可能让消息绕到恶意 MTA 或假网关。

权威且经过验证的 DNS 数据可以提高对邮件路由选择的信心，却不能向链路下游无限延伸。正确网关仍可能运行错误软件、使用过期号码数据、因政策拒绝请求，或根本没有通往目标电话网的路径。即使号码真实，也可能不属于发送者以为的那个人。

可靠审计需要分别保存：用户代理提交的原始地址、MTA 使用的 DNS 回答、网关的 SMTP 接受、解析决定、送往交换网络的指令，以及最终业务回执。把这些合并为“邮件地址有效”，会抹去每次权限转移发生的位置。

最小规范的价值，在于它没有冒充最终执行者

RFC 2846 后来给出更完整的上位语法，覆盖本地拨号、拨号后序列、子地址和收件人细节；RFC 3192 则把最小框架具体用于传真。它们都没有让 RFC 3191 的通用形式变成电话执行引擎。

它真正完成的是较窄但更可靠的工作：不同网关业务可以共用一个小型封装和一个受治理的扩展方法；中继系统能够完整转运自己无权解释的数据；网关能够识别登记词汇，又不必声称每条语法正确的目的地都真实可达。

互联网历史里，@ 两侧在这一刻承担了两种权力。左侧保存电话形状的表示，右侧选出唯一解释者；最终效果不属于任何一侧的字符串。标准之所以能互通，正因为它没有把表示、解释和结果压成一个事实。