摘要

  • SMTP 在邮件数据结束后以一个结果接受或拒绝整个事务；一旦返回正向完成答复，接收服务器就承担整封邮件的后续投递责任。
  • RFC 2033 规定 LMTP 按成功 RCPT 的原始顺序逐一返回最终结果，使上游队列仅保留未决收件人；若实际投递已经完成而答复丢失，重复投递风险仍然存在。

两个邮箱产生了两种事实

队列管理器先后提交两个 RCPT，本地投递代理都暂时接受。正文传完以后，第一个邮箱成功写入，第二个却遇到临时配额限制。此时真实状态已经分叉，但普通 SMTP 的最终语法没有分叉。

RFC 5321 明确规定，数据结束处不存在“部分失败”的事务结果。服务器要么接受邮件，要么不接受；若返回最终 250，便对邮件承担完整责任。之后若某个收件人失败，接收方只能自行排队重试，或者稍后生成未投递通知，不能把同一个最终答复同时解释为成功和失败。

这种规则适合主机之间的存储转发：接收方本来就有持久队列，可以先接管再处理。问题出现在另一条缝隙——已有队列管理器把邮件交给本地邮箱代理。若仅因 SMTP 缺少多结果语法，就要求后者再维护一套队列，持久状态、恢复机制和重试政策都会重复。

LMTP 专门处理这条狭窄边界。

答复数量重新划定了保管责任

1996 年发布的 RFC 2033 是一份 Informational RFC。它规定：DATA 的最终点号之后，LMTP 服务器必须为此前每一条成功的 RCPT 返回一个答复，而且顺序与命令顺序一致。

这样，收件人 A 的最终 250 可以让上游队列关闭 A 的责任；收件人 B 的 452 则让 B 留在原队列等待重试。本地代理提供最接近邮箱的事实，却不必继承一套独立的延迟处理系统。

这里的映射是位置性的。提前被拒绝的 RCPT 不进入最终答复序列；即使同一 forward-path 被成功提交两次，也必须占据两个位置并得到两个结果；多行答复仍然只算一个结果。客户端必须保存成功收件人的准确顺序，事后按地址文本合并或重排并不等价。

初始 RCPT 成功也不是最终投递保证。它只是让该收件人进入本次事务；真正转移责任的是正文结束后的对应正向答复。

LHLO 让双方先确认所用语法

LMTP 与 ESMTP 很相似，但恰恰在最终答复数量上不同。SMTP 客户端可能把第一条 LMTP 结果误当作整个事务结束，再把后续结果错配给别的命令；LMTP 客户端也可能在 SMTP 的单一答复后继续等待。

因此 RFC 2033 用 LHLO 取代 HELO 与 EHLO。LMTP 服务器不得正向接受 SMTP 问候，LMTP 也不得使用 SMTP 的 25 号服务端口。这不是名称装饰，而是在正文进入之前暴露双方的回复合同。

规范同时要求支持 PIPELINING 与 Enhanced Status Codes。RFC 2920 保证连续发送命令后仍按序对应答复；RFC 2034 和 RFC 3463 细化失败含义。但再精确的状态码也不能独自说明自己属于哪一条 RCPT，有序清单仍是核心证据。

若协商使用 CHUNKING，BDAT LAST 同样按收件人返回多项结果，非最终 BDAT 块仍只有一个答复。多结果属于“邮件完成”这一刻，不属于每一段字节。

丢失的答复仍会留下重复窗口

RFC 1047 早已指出 SMTP 的同步缝隙：接收方可能已经接受甚至完成投递，而发送方尚未收到正向答复。连接若在两者之间断开，一边有理由认为工作已完成，另一边却必须重试，于是可能出现副本。

LMTP 把这段不确定性缩小到单个收件人，却没有把邮箱写入和网络答复变成原子事务。假设 A 的 250 已被队列管理器持久记录，A 就可以退出重试集合；如果 B 已写入邮箱，但 B 的答复在途中丢失，客户端没有可依赖的接管证明。RFC 2033 要求处理已经收到的答复，并把其余位置视为临时失败。

服务器应尽快逐项发送并刷新缓冲区，客户端也应边收边处理，而不是等齐后一次提交。连接中断时，这能缩短处于歧义状态的尾部，却不能撤回已经发生的写入。

这也是 RFC 2033 不建议在广域网上使用 LMTP 的原因。其预期路径很短：持久队列在一侧，本地投递代理在另一侧。路径越长、故障越多，行为与证明被分开的机会就越大。

即时结果不是 DSN

DSN 是责任已经转移后，对后续投递事件所作的通知。LMTP 最终答复则直接参与责任转移：临时结果表示当前队列仍欠该收件人一次行动，正向结果表示本地代理已经接手。

它不证明人已阅读，不证明界面已显示，也不认证收件人的真实身份。LMTP 记录的是传输保管关系，而非注意力。它的历史意义，是让一个局部失败不再迫使所有收件人进入第二套队列。

来源与证据边界

闭合来源为 RFC 1047、RFC 2033、RFC 2034、RFC 2920、RFC 3463 与 RFC 5321。它们证明协议语义和责任边界，不证明当前部署比例、厂商默认值或统一的连接方式。RFC 2033 属 Informational，本文不把它写成互联网范围的强制要求。