RFC 2920《SMTP 服务扩展：命令流水线》中文导读

1. 流水线解决什么问题

传统 SMTP 是“一问一答”的同步模型：客户端每发一条命令都要等服务端应答才能发下一条。在跨洋或高延迟链路上，一次邮件投递要往返十几次，时延被严重放大。

RFC 2920 的 PIPELINING 扩展允许客户端在确认服务端支持后，把互不依赖的多条命令一次性发出（流水线），再批量读取应答。它收录于 STD 60，是降低 SMTP 延迟的标准做法，尤其在批量投递场景收益明显。

2. EHLO 关键字与适用命令

服务端在 EHLO 响应中通告 PIPELINING 关键字，即表示支持该扩展。规范明确划分了哪些命令可以进入流水线：

• 可以成组批送（任意多条）：RSET，以及 MAIL FROM、SEND FROM、SOML FROM、SAML FROM 与 RCPT TO。
• 只能作为流水线中的最后一条：EHLO、DATA、VRFY、EXPN、TURN、QUIT、NOOP。

也就是说，典型的投递事务可以写成“并行发出若干 MAIL/RCPT，最后跟一条 DATA”，一步到位进入正文上传。

3. 客户端的流水线写法

C: EHLO client.example.org
S: 250-server.example.net Hello
S: 250 PIPELINING
C: MAIL FROM:
C: RCPT TO:
C: RCPT TO:
C: DATA
S: 250 OK
S: 250 OK
S: 250 OK
S: 354 Start mail input; end with .

上例中客户端在收到任何应答前就连发 MAIL/RCPT/DATA 三条，然后按顺序读取服务端回应的 250/250/250/354。顺序必须与发出顺序一一对应。

4. 服务端的三条硬约束

• 按序应答：服务端必须按命令接收的顺序逐条给出应答，不能以乱序或合并的方式回应，否则客户端无法把应答与命令对应。
• 不得冲刷输入缓冲：服务端在发完手上所有可发的应答之前，不得主动冲刷（flush/drain）TCP 输入缓冲，否则会丢弃尚未处理、但客户端认为已发送的命令，造成静默丢命令。这是防止实现缺陷导致会话紊乱的关键。
• 非流水线命令只能末位：DATA 等命令一旦发出，其后不能继续挂接新的 FROM/RCPT，必须等到事务结束。

需要注意：流水线并不改变 SMTP 的语义——MAIL 必须在 RCPT 之前、事务状态仍受 EHLO/MAIL/RCPT/DATA 约束；它只改变“是否等待应答”的时机。

5. 与 STARTTLS 的关系

如同前面 RFC 3207 所述，若使用了 STARTTLS，它必须是命令分组中的最后一条；握手成功、状态重置后，客户端才能开始新的流水线。换言之：流水线只能在“已稳定协商的会话状态”内使用，不能在 TLS 切换的边界处跨跳。

规范特别提醒：在 EHLO 与 STARTTLS 之间、以及握手后重发的 EHLO 之前，都不宜把 STARTTLS 与后续命令放进同一组。

6. 拒绝服务考量

流水线的风险在于恶意客户端可能在服务端来不及应答时倾泻大量命令，耗尽服务端内存中的应答缓冲。因此规范强调“不得冲刷输入缓冲”只是实现正确性的要求；更进一步的防护（限制单条命令长度、限制未完成事务数、对异常客户端限速或断开）属于服务端本地策略，文档建议实现方自行控制。

对客户端而言，流水线虽能提速，但一旦某条命令被拒（如 550 收件人不存在），后续命令的应答语义仍需逐条核对，不能假设“整组成功”而忽略中间错误。

参考：https://www.rfc-editor.org/rfc/rfc2920.txt