摘要

  • RFC 3939 为语音邮件定义了 Caller-ID 与 Caller-Name 两个邮件头，用来保存电话系统向被叫方呈现的信息，而不是认证呼叫者身份。
  • 它明确警告：国际号码被截成十位后可能指向另一个真实用户；内部短号被转发到企业外部后既无法回拨，也可能泄露私人拨号计划。

电话知道号码，邮件却没有合适的位置

2004 年的典型问题很具体：来电者没有被接通，留下语音留言；电话网能够提供号码和姓名，存放录音的 Internet Mail 系统却未必知道来电者的电子邮件地址。RFC 3801 已经允许用 non-mail-user 表示无法通过邮件回复的电话答录来电者，但把电话号码硬塞进普通 From 字段，仍会混淆两种来源。

RFC 3939 的办法是另开两栏。Caller-ID 保存电话系统提供的号码，Caller-Name 保存显示姓名。这样做保留了来源边界：From 属于 Internet Mail 的发件人模型，新字段则是电话系统当时向被叫方呈现的观察值。

这项分离没有把显示信息升级成证明。规范没有说号码认证了说话者，也没有说姓名对应法律身份。它只是回答“这份元数据放在哪里”，没有替电话网解决伪装、号码归属、呼叫授权或实际回拨结果。

unknown 才是默认语义

Caller-ID 只允许数字，不带空格、连字符或加号。内部呼叫可以只保存分机号；国际呼叫应保存最长 15 位的完整 E.164 数字序列。旁边还可以加一个 NumberingPlan 参数，但这个参数不是必填项。

参数缺失时，默认值是 unknown，不是 E.164。local 只表示该号码在保存语音邮件的系统域内属于一个本地编号计划；e164 才声明其国际号码语义。相同的四位数字，在一家公司的 PBX 内可能足以找到办公桌，离开该系统后却几乎没有行动价值。

RFC 3939 特意声明，它要原样记录模拟电话系统送来的号码，不负责把号码定义为可寻址或可拨打的地址。RFC 2806 为本地电话 URL 要求明确的 phone-context，因为同一串短号在不同区域会有不同解释；RFC 3191 则为邮件地址里的全球 GSTN 地址保留了带 + 的 E.164 形式。两份相邻规范反衬出 RFC 3939 的克制：记录观察值，不补造它没有收到的上下文。

完整转发，也可能完整地送错

规范给出的第一个危险来自国际号码截断。某些北美系统只能处理十位数字，可能把一个爱尔兰号码的前几位切掉；余下十位看上去又恰好像北美号码。收件人得到的不是明显报错，而是一个格式合理、意义错误的回拨目标。若系统只检查“是不是十位数字”，错误反而更容易通过。

第二个危险来自转发。公司内部的短分机在原系统里有效，语音邮件被转到外部后，这个短号既不能路由，又暴露了企业私人拨号计划的一部分。邮件传输成功、头字段逐字保留，都不能证明语义也完成迁移。

这正是运行证据必须分层的原因：电话系统呈现了什么，语音邮件系统保存了什么，邮件网关转发了什么，客户端显示了什么，用户最终拨了什么，是五个不同事件。前一步的成功不能替下一步背书。

姓名与时间也有自己的歧义

Caller-Name 需要穿越多种电话信令字符集。规范以 ASCII 为基础，无法用七位 ASCII 表示时可以采用 RFC 2047 编码原生字符集。接收系统若不支持相同选项，姓名可能显示错误；运营商还可能把姓名缩短到 15 个字符，尽管头字段允许最多 50 个字符。

隐私边界同样微妙。RFC 3939 说，限制号码不应因此被完整暴露，新字段只应保存被叫方本来会看到的内容，例如 Private Name，而不是运营商之间交换的隐藏细节。但进入邮件以后，号码可以随转发继续存在；除非客户端把头字段显示出来，收件人甚至可能不知道邮件里携带这项数据。

连时间也不能想当然。电话系统提供的时间可以写入普通 Date 头，系统也可以选择本机时间。没有记录来源，就不能把那个时间戳直接当作呼叫发生的精确时刻。

RFC 3939 的价值不在于把来电显示变成可靠身份，而在于承认保存与理解之间有距离。字符可以跨网，产生字符的行政域、拨号规则、显示限制和披露预期不会自动附着在字符串上。