摘要

  • RFC 821 提供三个可选的事务起始命令，把终端显示、邮箱存放或二者并行变成 SMTP 的投递语义。
  • 三种成功标准并不相同：SEND 取决于终端投递，SOML 接受终端或邮箱任一结果，SAML 即使尝试终端显示，成功仍以写入邮箱为准。
  • MX 中继能够掌握邮件路线，却未必控制用户的实时终端；后续 SMTP 因而弃用这些命令，只保留有限的兼容规则。

在正文发出以前，先选择“怎样抵达”

设想 1982 年的一台共享主机。收件人已经登录，并允许系统把消息直接显示在终端上。远端发送者建立 SMTP 会话后，不一定使用普通的 MAIL，而是可以在三个命令之间作出选择。

SEND 要求把数据送到用户终端；用户不在线或不接受终端消息时，服务器可以对该收件人返回临时失败。SOML 是 Send Or MaiL：用户在线且同意时投到终端，否则写入邮箱。SAML 是 Send And MaiL：在线时尝试终端显示，同时无论如何都要存入邮箱。

这些不是正文里的偏好标签。RFC 821 让它们与 MAIL 一样成为事务的起点，后面才是 RCPT 与 DATA。也就是说，发送者先选投递机制，再给出收件人与内容。

这个设计把一个极短暂的人类状态交给了传输层：用户此刻是否活跃、是否愿意被打断，以及“屏幕亮了一次”还是“内容留下来了”才算成功。

同一个“成功”，有三种证据含义

三个命令最有价值的地方，不是它们曾提供即时消息，而是它们公开承认“送达”并非单一事件。

对 SEND 而言，只有终端收到数据才算成功；除非客户端改用其他命令，邮箱并不是自动兜底。SOML 把终端和邮箱当作替代目的地，完成任意一条即可。SAML 则要求邮箱分支成立，终端显示只是额外动作；规范没有把屏幕显示写进其成功条件。

于是，成功的 SEND 可能只有瞬时呈现而没有持久副本。成功的 SOML 若缺少额外记录，甚至不能说明究竟哪条分支完成。成功的 SAML 可以证明邮箱路径完成，却不能据此断言用户真的看到了终端上的内容。

协议语法诚实地区分了注意力与保管责任。问题在于，选择命令的是发送者，承担中断和留存后果的却是收件人及其主机。

“在线”是主机本地事实，不是地址属性

RFC 821 的终端投递依赖两个条件：用户正在该主机上活动，而且接受终端消息。它们都不是邮箱地址的永久属性，而是某台机器上某个会话在某一时刻的状态。

邮箱地址不变，用户可以退出、换终端或关闭打扰。路由仍然有效，接收邮件的主机却可能已经不再掌握用户的交互界面。即使在同一事务中，处理收件人时看到的状态，也可能在正文传完前发生变化。

因此，发送者可以提出 SEND 请求，却不能宣布收件人在线。服务器在 EHLO 中宣布支持某个命令，只能证明它认识这套语法，不能证明某个人此刻存在于终端前，更不能证明对方同意被打断。

MX 把“能转交”与“能显示”拆开了

RFC 1123 将发送端和接收端实现 SEND、SOML、SAML 都列为可选，并用一小段讨论点出了结构性矛盾。

MX 路由允许一台主机代表目标接收邮件。它可能知道怎样把邮件继续送近用户，却无法直接写入用户终端。对于 SEND 后面的收件人，这样的服务器可以返回 251 User Not Local，告诉源端实际投递可能被推迟。

这个回复区分了两种可达性。路由可达表示系统能够接管并转发邮件；呈现可达表示它控制用户正在使用的屏幕。MX 可以拥有前者，完全没有后者。

存储转发网络因此遇到了一条硬边界：中间节点可以可靠承担下一跳责任，却无法把“立即获得人的注意”当作自己能够履行的传输承诺。

能力发现只能证明语法

RFC 1425 引入 SMTP 扩展机制时，最初的注册表把三个命令列为可选服务，并让命令名本身成为 EHLO 关键字。

这解决了“服务器是否实现该命令”的猜测，却没有解决收件人是否登录、是否接受终端消息、当前服务器是否为最终主机，以及显示能否完成。产品界面很容易把一个能力标志变成绿色按钮，再把按钮变成承诺；但 SEND 出现在 EHLO 中，只说明服务器会说这种协议语言。

发现机制提供的是形式能力，不是用户状态，更不是中断许可。

协议保留兼容，却移走了中心位置

到 2001 年，RFC 2821 已把 SEND、SAML、SOML 称为过时命令。规范说它们很少被实现，工作站技术的变化和其他协议的出现，可能使已有实现也失去用途。

处理方式并非粗暴删除。客户端不应再把它们作为服务提供；服务器仍可为了兼容而实现，但必须遵守 RFC 821 的模型，并在 EHLO 响应中公开命令名。

RFC 5321 延续了这一安排。旧命令仍可被识别为事务起点，普通 SMTP 的核心却是 MAIL，以及服务器在成功接收正文后承担的正式责任。

这种责任可以持久记录：服务器既然接受，就应继续投递或报告失败。它不必声称某双眼睛在某一瞬间看到了屏幕。弃用因此不是抹掉历史，而是把协议的公共中心收缩到传输层真正能够负责的事实。

注册表记录名字，不记录现实部署

IANA SMTP 注册表 至今仍保留 SEND、SOML、SAML，引用 RFC 821，标注其后来的弃用，并规定不得用于 Message Submission。

这些条目维护的是可互操作的历史词汇，不是现状普查。它们不能说明多少服务器仍有实现、收件人是否允许终端消息，也不能证明某次屏幕显示确实发生。

这正是本段历史留下的证据纪律：支持、在线、同意、呈现、存储、责任是六种不同事实。早期 SMTP 试图用事务命令组合其中几项；后来的 SMTP 没有解决人的注意力，而是不再把这种短暂状态当作邮件传输的中心。

即时呈现并不是更强的投递

这三个命令并不愚蠢。在数量不多、关系紧密的主机之间，直接终端消息既直观又便利。SOML 提供合理的失败回退，SAML 明确保留持久副本。设计者看见了真实差异，并给每一种差异安排了动词。

规模改变的是哪些差异适合留在传输层。中继增加、工作站分化、用户应用独立以后，邮件系统可以稳定掌管队列和保管责任，却无法稳定掌管用户当前的界面与被打断意愿。

屏幕发光可以很快，也可以转瞬即逝；安静的邮箱可能稍晚，却能留下可追责的副本。一封抢在邮箱前出现的消息也许赢了时间，但它未必找到了可以留下来的地方。

来源