摘要

  • D. L. Mills 在 1981 年提出邮件名称域时，ARPANET 与 DCNET 合用的表里已有四百多个名称和别名；未来让每台主机保存全网平面清单越来越不合算。
  • 更棘手的是一台转发机兼任多个域的“邮局”。Mills@HOST 在 COMSAT 和 INTELPOST 可以指向不同邮箱，而机器的 IP 地址不能替回信决定是哪一个域。完整邮箱名和路由上下文必须一路带着。

假设一间收发室同时替两家公司分信，两边都有人叫 Mills@HOST。信封只写这个本地名字，柜台会先问：你找哪边的 Mills？这个收发室是比喻，难题却来自 D. L. Mills 1981 年 9 月的 RFC 799。当时 ARPANET 与 DCNET 合用的名称地址表已经塞进四百多个主机名和别名。把名单按域分开看似轻松，邮件从一个域走到另一个域、再收到回信时，名字中的上下文可不能掉在门口。

Mills 设想的名称域可对应 ARPA、UCL、COMSAT 等机构。域之间允许重叠，也不要求覆盖每一个地址。文章讨论时只取一层域结构，但标准邮箱写法 <user>.<host>@<domain> 从右向左读已经有三层意味。在 COMSAT 内部，Mills@COMSAT-DLM 足以找到人；跨到别处，Mills.COMSAT-DLM@COMSAT 才把域也写全。不同域可以重复使用本地别名。这使末尾的域名成为真正的分拣线索，而不是信封上的花边。

每个域配置一个或多个邮件转发进程。转发者掌握本域所有主机名，同时知道其他各域至少一个转发者。普通主机只需记住各域的转发者，再按需要缓存或登记其他主机。一个实体主机可以同时替多个域运行转发进程，也可以拥有不止一个互联网地址。Mills 提到转发者可复制以求稳健，却没有假装复制后的路由复杂性已经解决。整个方案容许地方自己取名，代价是转发时必须保存“此刻按哪一本地方名册解释”的信息。

转发者也不意味着每封邮件都得排队换乘。Mills 预期，大多数邮件会由发件主机直接交给收件主机。只有双方无法同时在线、发件方缺乏名称转换能力、直连遇到监管、经济或安全限制，或者一边用 TCP、一边用 NCP 等情形，中途存放并转送才有用。普通中继可以存信再送，未必掌握转发者那套跨域名册。把两者分清，才知道哪些节点必须当“全网通”的收发室。

RFC 799 给出了一组极直白的路线：MRCP to:<@COMSAT,Mills@HOST> 与 MRCP to:<@INTELPOST,Mills@HOST>。在例子里，它们可以是两个不同邮箱，即使两套转发进程运行在同一台电脑上。若这台电脑在两边都叫 FORWARDER，路线缩成 MRCP to:<@FORWARDER,Mills@HOST>，关键的域便丢了。查机器的互联网地址也找不回来：一个地址背后可以同时扮演两个域的转发角色。回信若只凭上一站机器地址重建路线，就会继承这道选择题。

因此，跨域中继需要写足邮箱名。Mills 还挑出当时 RFC 780 路由办法里的另一处陷阱：接收方要从上一站的互联网地址构造发件路线名称。面对一台服务多个域的转发机，这个地址只说明是哪台机器，没说明它以哪个域的身份接手邮件。发送方必须同时更新收件路线与发件路线：把收到的收件路线第一项复制为发件路线的新第一项。来时经过哪个柜台，回程的单据也要写上。

旧邮件系统没法一夜之间统一名字。Mills 不赞成沿途反复修改 RFC 733 邮件头，那是需要大范围解析的侵入性操作。新系统应尽量通篇使用完整的互联网邮箱写法；旧 ARPANET 系统需要改名时，就在邮件第一次进入互联网邮件系统的边界处理：本地 <anything>@<host> 改写为 <anything>.<host>@ARPA，已经认得的 <anything>@<domain> 保持原样。最了解简称来自哪里的地方，正是把它补全的地方。

RFC 799 最后一句甚至请读者继续讨论。它记录的是一份方案，不是后来 DNS 已建成的现场报告。Mills 抓到的关键却很硬：32 位机器地址可以唯一定位主机，却不能说明同一主机正在替哪个邮件域工作。四百多个名称让平面名册开始吱呀作响；一台兼职两个域的机器，则让“先分册再说”立刻遇上回信地址的考题。