摘要

  • 从姓名推导账户，换来了可预测性，却把不同的人压缩进更小的技术空间；唯一性来自明确的范围、比较规则与分配动作，不来自字符串像姓名。
  • RFC 1439 最重要的操作建议，是让消歧后缀始终出现、拒绝无后缀的含混形式，并在邮件系统的生命期内不复用标识符。
  • 后来的 RFC 把各层拆得更清楚：显示姓名、用户名、稳定资源 ID、外部 ID、邮箱、SMTP 责任交接、凭据和授权决定，各自只提供有限证据。

第二个同名者到来之后

设想九十年代初的一所大学把账户规则印在纸质名录上：名、中间名首字母、姓，再加几个标点。它的价值在于无需查表。只要见过一个例子，校外通信者也能猜出其他人的邮件地址。

问题从第二个同名结果出现的那一刻开始。规则没有找到“那个人”，只是算出了一个候选键。系统随后必须回答：数字给第二个人还是两个人都给？大小写能否区分？标点是否参与比较？第一位用户离开后，这个好看的字符串能否交给后来者？每项选择都会改变外部发件人能够相信什么。

Craig Finseth 在 1993 年 3 月发布的 RFC 1439 是信息类文档，并非互联网标准。它把分配方法分成三类。第一类发放与个人信息无关的、不透明而唯一的字符串，便于保证不冲突，却难以猜测。第二类由姓名推导主体，再用数字等变化保证唯一。第三类也由姓名生成，但重复时临时处置。

电子邮件普及后，可预测性变得有用。可是“能够推测”不等于“能够证明”。姓名是呈现材料，规范化规则得到比较形式，可用性查询观察某一刻的局部状态，分配记录才把槽位绑定给资源。把这些动作统称为身份，会把不同的执行主体和时间边界一起抹掉。

姓名簿里的生日问题

RFC 1439 估算了首字母、名字、姓氏以及多种组合所包含的典型与最大信息量。多数格式的典型值只有 8 至 20 比特；表中最丰富的典型组合为 26 比特，最大估值也没有超过 40 比特。因此，组织尚未显得“用完名字”之前，重复就可能很常见。

原因是生日问题：风险随可能发生碰撞的配对数增长，而不是只随已占用槽位的比例增长。文档把“名 + 姓”的典型信息量估为 17 比特。在 100 人组织里，发生至少一次重复的概率介于 2% 与 5% 之间，约为 4%；到 1000 人时，概率远高于 20%。

这些数字不能被当成适用于所有文化的人口规律。1993 年使用的姓名资料、语言、文字、亲属命名习惯、转写规则和组织构成都有历史条件。真正可迁移的结论是：碰撞率取决于输入的实际分布、比较函数和已分配数量，不能用可见字符长度代替测量。

去掉音调或变音符号、折叠大小写、删除空格与标点、截短长姓名、把不同文字转写成拉丁字母，都可能提高一个环节的兼容性，也可能把原来不同的候选项合并。任何“唯一”承诺，如果不同时说明在哪个空间、采用何种相等规则，就缺少最关键的谓词。

后缀不是例外，而是地址的一部分

附录考察了 First.M.Last-#。第一个使用者能否占有不带数字的漂亮版本，只给第二个人加 -2？RFC 1439 的答案是否定的。如果无后缀地址会自动交给第一人，外部发件人不会收到可靠提示，也就不知道自己可能找错了人。若所有账户都必须带数字，且无数字形式一律拒绝，失败会诚实地告诉发件人：你还缺少消歧信息。

拒绝在这里不是服务故障，而是安全地保留不确定性。系统没有足够证据选择时，静默偏向最先登记者，就是把姓名碰撞包装成一次成功投递。

文档以谨慎处理电子邮件为理由，并提到美国 1987 年《电子通信隐私法》。这只能作为作者在 1993 年的历史论据，不能延伸为今天的法律判断。技术结论无须借助这种延伸：邮件进入有效邮箱，并不能证明邮箱属于发件人心中那位同名者。

RFC 1439 还建议，在邮件系统的生命期内不要复用这类标识符。复用把同时碰撞变成跨时间碰撞。旧通讯录、归档邮件、邮件列表、访问控制、找回流程以及人的记忆，会在原持有人离开后继续引用旧字符串。把同一槽位交给新人，既继承了字符串，也继承了此前围绕它积累的信任与待执行动作。

因此，真正的生命期不一定等于在职期或账户启用期。只要旧 ACL、恢复联系人、订阅或历史消息仍能触发行为，这个标识符就没有在操作意义上死亡。

SMTP 的成功只交接责任

RFC 5321 把地址定义为指向某个用户或投放位置的字符串，把邮箱定义为那个存放处。地址的本地部分只能由域名所指定的主机解释和赋义。对域外发送者来说，相同外观可能指个人、共享队列、转发别名、程序，或为连续性保留的旧入口。

SMTP 还有一条清晰边界：服务器在消息数据结束时返回成功后，就正式承担责任，必须投递消息或正确报告失败。这证明的是协议内的责任交接，不证明预期中的人拥有邮箱、读过邮件或完成了下游动作。

RFC 2142 则故意规定了“不代表特定个人”的地址。postmaster、abuse、noc、security 是服务、角色与职能邮箱。支持相应职能的域，应把邮件送给适合处理该角色的接收方。人员可以更替，职能入口应当延续。

连大小写相等也没有脱离命名空间的统一答案。RFC 5321 要求保留邮箱本地部分的大小写，并在形式上把它视为大小写敏感；同时又不鼓励利用这种差异，因为会妨碍互操作。域名则不区分大小写。中间系统不能凭直觉替目的域发明账户比较规则。

现代模式把几种“ID”分开了

RFC 7643 的 SCIM 核心模式不是为解决 1993 年的邮件冲突而写，却很好地显示了分层。id 由服务提供方签发，在该提供方的全部资源中唯一、稳定且不可重新分配。externalId 由配置客户端给出，只在该客户端的配置域内有意义，服务端不强制其唯一。userName 面向用户，在提供方的用户集合中唯一；人的姓名各部分另有字段。

这四类值背后有不同权力。提供方控制资源键与登录空间，客户端控制外部关联键，姓名字段用于呈现。两个完全相同的字符串，可以在不同范围内提出不同主张；两个不同字符串，也可以从两个系统指向同一资源。

RFC 8265 又处理国际化用户名。它将用户名定义为账户的指示串，账户经常但并非必然由人使用，并建议把限制较严的账户标识符与表达更丰富的显示名或昵称分离。它提供大小写映射与大小写保留两种配置。选择权属于应用协议、实现或部署；映射会损失信息，因而应在明确的比较点上执行。

由此可以建立证据阶梯。显示姓名只负责呈现。规范化输出是候选项。可用性检查只观察某个空间的一刻。分配把槽位绑定给资源。邮箱地址按目的域规则指向投放位置。SMTP 成功交接后续责任。认证证明某套凭据的控制，授权证明某项策略允许某个动作。即便独立渠道上的本人回复能增加证据，它仍有时间与上下文边界。

最小公共规则并不需要统一全球姓名的写法。它需要明确互操作不可缺少的部分：命名范围、相等函数、碰撞处理、分配转移和复用条件。目录是协调记录；运行中的比较与路由代码才产生可执行事实。

来源