摘要

  • 1982 年 8 月的修订版把 SMTP 定义为可靠流上的对话，即使通信两端不共享同一种传输服务，也可通过中继转送邮件。
  • MAIL 提供回程路径，RCPT 可给出一个或多个收件路径；RFC 822 另行规定消息文本格式，因此会话被接受并不证明邮件进入邮箱或被读者看到。

一封邮件可以跨越网络边界，而不需要邮件正文知道底层经过了哪张网。1982 年 8 月 Jonathan B. Postel 发布的 SMTP 规范，正是围绕这种传递方式展开。RFC 821 不绑定某一种传输子系统，只要求可靠、有序的数据流，再描述 SMTP 进程如何通过该通道交换命令和响应。

中继是架构的一部分。如果发送主机和目的主机共享同一传输服务，发送端可直接连接接收端 SMTP 进程；否则，一个或多个中间 SMTP 服务器可以连接不同的传输服务环境。Postel 对“环境”的定义并非等同于一张网络：一个传输服务可能覆盖一张网、多张网，或一张网的一部分。协议描述的是进程可达关系，而不是简单的地理或链路图。

事务把交接过程拆成可观察的步骤。发送端打开双向通道，接收端逐项响应。MAIL 以反向路径开始交易，供退信等信息返回；每条 RCPT 给出一个正向收件路径，而且可以重复。之后 DATA 才发送消息。数字响应码使发送方知道每条命令是否被接受。SMTP 信封携带的是投递指令，不等同于正文中的文本字段。

与同月发布的 RFC 822 对照，可以看出这两种标准处理不同问题。RFC 822 规定 ARPA Internet 文本消息的格式；RFC 821 规定传输会话。正文中的 From: 是消息表示的一部分，MAIL FROM 则属于 SMTP 交易。若将它们混为一谈，就会把正文里的地址误当作真实传输路径或投递决定的证据，而规范并没有这样的保证。

RFC 821 不是 SMTP 的创始文件，而是一次修订。它的首页列出被替代的 RFC 788、780 和 772；1981 年 11 月的 RFC 788 已经定义了 SMTP。RFC 801 的网络过渡计划提到 SMTP 服务，但没有提供采用数量，也没有衡量用户是否成功收到邮件。标准修订的出版日期不能代替所有主机的实际部署日期。

这套模型也不只适用于 TCP。RFC 821 附录描述了 NCP、TCP、NITS 等不同传输服务，并在 TCP 附录中给 SMTP 分配 socket 25。端口号让实现更具体，却不能证明邮件服务正在运行。仍需接收端程序在线、命令被接受、路径有效、DATA 事务完成，以及连接之后的本地处理。

它的历史贡献，是定义了可在多种环境间复用的服务边界。SMTP 为邮件传送提供共同对话，并允许中继连接两端不共享的传输环境；正文格式与本地邮箱行为仍是其他问题。借用 Heng Lu 的 Note 64 作为分析镜头，这说明共同规范可以只覆盖互操作所需的规则，把传输和部署留给运行系统自行选择。该视角是后来的解释，不是对 Postel 动机的判断。

Sources