摘要

  • RFC 733 统一了 ARPANET 主机间传送的文本消息格式，但没有定义完整的邮件服务或用户界面。
  • 共同语法出现时，邮件仍通过 FTP 命令投递；此前的提案和各主机的解析程序已形成不同预期。

分析

快速修补仍发生在 FTP 之内

到 1973 年，网络邮件已经通过 File Transfer Protocol 的两个命令 MAIL 和 MLFL 传递。它们可以把消息放进收件人主机的本地邮件系统，却无法保证邮件头格式一致。一台主机发送的作者、标题或日期，另一台主机未必能可靠识别。对 FTP 而言，整个消息——包括邮件头——都只是数据。

RFC 524 曾提议在 FTP 的命令空间里加入更丰富的邮件协议。作者也说明了为何方案依托 FTP：FTP 已被广泛实现，而当时另一个统一的用户层协议还没有。RFC 561 选择了一条更快的临时路径。四位作者没有等新的投递命令，而是先为已由 MAIL 或 MLFL 发送的消息提出文本约定。From、Date 和 Subject 有了可识别的写法，其他字段则仍可扩展。作者明确认为，这比修改邮件协议更容易快速实现。

这是一项边界清楚的改动。RFC 561 没有取代传输层；它试图让传输中的数据更便于人和软件理解。灵活性也留下了缺口：“杂项”字段可以不断增加，但收件人及其他字段仍没有共享语法。

标题可能比协议本身说得更大

RFC 680 于 1975 年以“Message Transmission Protocol”为题发布，扩展了消息字段。文中定义的是邮件头及其预期含义，并未规定主机之间如何传送消息。作为修订提案的 RFC 724 后来说明，RFC 680 发行范围有限，也没有正式成为 ARPANET 官方标准；不过，一些实现者仍把它当作标准使用。

RFC 724 还记录了另一种更直接的影响力来源：已经运行的邮件软件。该文作者称，TENEX 系统发出的网络消息多于其他类型的主机，其 To 和 Cc 格式因此逐渐成为事实上的惯例。TENEX 的邮件阅读程序开始期待这种格式。Multics 尝试了不同写法；据该报告，随后 TENEX 用户抱怨无法解析那些消息。这是当时委员会的记录，并非所有主机的部署统计。但它说明，仅有正式文件的标题不足以决定格式：已经流通的消息和解析程序会塑造使用者预期。

RFC 733 统一了接口边界

RFC 733 于 1977 年 11 月发布，取代了 RFC 561、RFC 680 和提案 RFC 724。它系统规定了 ARPANET 文本消息的语法，包括收件人地址形式和对已保存地址列表的引用。前言称，这项工作经由邮件环境本身持续讨论了一年，参与者超过二十人。这能证明协作过程存在，却不能证明每个系统都采用了最终规范。

该文档对自身边界说得很清楚：它规定主机之间传送的内容格式，不规定本地邮件系统必须提供哪些功能，也不规定撰写或阅读程序应当是什么样子。语法可以承载结构化字段，但主机自行决定哪些字段要自动处理。作者希望共同格式先满足眼前需要，并为开发者留下空间，以便“妥善地”另行设计邮件传输协议。

这个折中有现实意义：先让消息格式相通，同时保留本地服务的设计选择。发送方和接收方可以使用不同系统，不必共享同一界面。不过，规范一经发布，并不会自动让所有实现彼此兼容。解析程序仍须有人编写，采用情况仍取决于运行这些程序的主机。

后来的标准把两层分得更清楚

1982 年，RFC 821 规定了 Simple Mail Transfer Protocol（SMTP），将其定义为主机间基于可靠有序数据流的传输机制。同年，RFC 822 则单独规定 ARPA Internet 文本消息的格式，并明确取代 RFC 733。合起来看，两份文档把两个问题拆开了：消息如何移动，以及消息内容如何组织。

因此，现存记录支持的是一个有限结论：RFC 733 并未“发明电子邮件”，也没有立即统一全部邮件系统。RFC 724 记述了一种广泛使用但非正式的邮件头惯例；RFC 733 提供正式语法并界定其范围；RFC 821 和 RFC 822 后来分别记录了传输和内容标准。这些文件本身都没有统计有多少主机实现了每条规则，也没有说明某个具体系统何时改变。

来源与证据边界

一手资料包括 RFC 524、561、680、724、733、821 和 822。关于 TENEX 与 Multics 的叙述来自 RFC 724，不能扩写成整个网络的采用率统计。Heng Lu 的第 64 号笔记提出的“最小初始规范”“未来决策留在本地”和“自愿采用”，只是后来的分析视角，并不能证明 1970 年代作者的主观意图。

来源