摘要

  • RFC 784 描述了 TOPS20 上的邮件派送程序：它查收件主机的能力表，分别选择 TCP 上的 MTP、NCP 上的 MTP、旧式 NCP 上的 FTP，或特殊路线。
  • RFC 785 把一封邮件拆成两个文件：正文文件放邮件内容，控制文件放寄件人与收件路径并指向正文。某条路线暂时走不通时，派送程序只需更新待办名单。

给四个人写同一封信，按常理只需要一份正文、四个地址。早期某些邮件程序却会为四个地址各造一份文本。Suzanne Sluizer 和 Jon Postel 在 1981 年 7 月提出更像邮局的做法：RFC 784 所述的 ISI TOPS20 MTP 实现把邮件放在一个文件里，把派送工作另放一张单子。路上堵车，改的是单子，信里的话继续躺着。

当时一封邮件确实可能面对几条不同的路。他们正在用 BLISS-10 为 TOPS20 建 MTP 收发程序，既走 TCP，也走较早的 NCP，还要同其他邮件系统接头。撰写邮件的程序和网络接收程序先在用户目录里留下文件。后台派送程序再挑选输出通道；用户也可以在通道可用时立即尝试派送。决定路线要查主机能力表：对方接收 TCP 上的 MTP、NCP 上的 MTP，还是旧方法 NCP 上的 FTP？特殊处理表还记着其他选择，例如经 UCL 开发的邮件系统送往英国主机。四个地址可以走四趟不一样的旅程。

控制文件记录交付信息，并指向另一份装着 RFC 733 邮件头和正文的文件。若某个收件人已经通过选定通道处理，派送程序可在控制文件中标记或删去他的待办项。另一条通道暂时不可用，相应的收件人继续留在名单里。正文文件供各次派送读取，整个本地流程结束后才可能改名或删除。变化发生在工作状态上，便把工作状态单独写。因为一扇门关着，就把整封信重新打一遍，邮局柜台恐怕也要抗议。

RFC 785《ISI TOPS20 文件定义》给这张单子写了格式：FILE: 指向完整的正文文件名，FROM: 写寄件路径，多个 TO: 各写一条收件路径。另一个文件保留邮件头与正文。文件中还比较了旧程序的做法：To、Cc、Bcc 里有 N 个地址，就做 N 份正文副本。新接口不论收件人有多少，先只做两份角色分明的文件。可见邮件页面上的收件栏和实际派送要处理的路径，本来就承担不同工作。

邻居的地址写法也未必一致。RFC 786专门说明 MTP 与 NIMAIL 之间如何交换文件，举出百分号形式的地址与 MTP 路径相互转换的例子。派送程序不仅要知道主机能接哪种传输，还要把地址写成下一站能读懂的样子。网络邮件从来不是把纸塞进电线就完了。

作者清楚交代了工程阶段。RFC 784列出他们正在造的收发程序、希望别人改造的撰写程序，以及要建立的能力表。RFC 785 则把文件接口写得很细。记录的是一份具体的实现计划，不是一张宣告所有收件人都收到信的回执。但关键的派送思路已经可见：一个人送成，另一个人还在等；这两件事可以分别记录，而不必复制发件人的每一句话。

画面很像旧邮局。一封信摊在桌上，旁边的卡片列出收件人和出门的路线。1981 年，门牌上写着 TCP、NCP 或 NCP 上的 FTP。某扇门打不开，那行姓名留在卡片上；其他通道照样工作。让字句留在原处，让派送单承受折腾，这就是两份文件的聪明劲。