RFC 3030《SMTP 服务扩展：二进制 ESMTP》中文导读

1. 为什么需要二进制 ESMTP

传统 DATA 命令把整封邮件作为一段文本上传，并要求对正文中“单独一行的点”做转义（点填充），同时正文受行长与字符限制，导致任意二进制数据必须先编码（base64/QP）才能发送——既膨胀带宽又增加 CPU 开销。

RFC 3030 由早期 RFC 1830 升级而来，引入两个扩展来消除这一约束：CHUNKING（用新的 BDAT 动词分块上传）与 BINARYMIME（在分块基础上允许任意二进制）。这样二进制附件可不经编码直接流过 SMTP。

2. CHUNKING 与 BDAT 动词

服务端在 EHLO 中通告 CHUNKING 后，客户端不再用 DATA，而是用 BDAT 逐块上传：

BDAT  [LAST]

• chunk-size：本块字节数（十进制）；
• LAST：可选标记，表示该块是邮件的最后一个分块；
• 客户端发送若干 BDAT 块，直到最后一个带 LAST 的块，事务即完成，等价于 DATA 阶段结束。

因为 BDAT 自带长度与结束标记，正文里不再需要点填充，也不存在“单独一行的点”歧义——这是 CHUNKING 相对 DATA 的核心简化。

3. BINARYMIME 与编码免除

BINARYMIME 扩展必须配合 CHUNKING 使用；单独通告 BINARYMIME 而无 CHUNKING 是不合规的。它允许邮件正文（在 BDAT 分块内）包含 RFC 5321 原本禁止的内容：超长行、NUL 字节、裸控制字符等，即真正的二进制透明传输。

相应地，使用 BINARYMIME 时 MAIL FROM 应带 BODY=BINARYMIME 参数，告知服务端本封是二进制主体，不应被当作需要文本约束的 MIME 处理。

4. DATA 与 BDAT 不可混用

规范明确规定：DATA 与 BDAT 不得出现在同一邮件事务中。一旦用 BDAT 开始上传，就必须一直用 BDAT 直到带 LAST 的块结束；中间不能插入 DATA，也不能在 DATA 之后改用 BDAT。

这种互斥保证了服务端解析路径单一，避免“半 DATA 半 BDAT”的会话状态混乱。

5. 应答码与分块容错

BDAT 的成功应答是 250（可带该分块被服务端处理的字节数）。若带 LAST 的块到来但服务端此前状态异常，会以相应错误码拒绝。

分块机制还有一个工程优势：发送方可以边生成边发送（流式），并在中途通过检查应答判断对端是否仍在接收，而不必先把整封邮件在内存里拼好。对超大附件（视频、数据库导出等）尤为有用。

6. 与 8BITMIME 的层次关系

回顾 RFC 6152：8BITMIME 只保留 8 位、仍受行长限制；RFC 3030 的 BINARYMIME+CHUNKING 则彻底放开二进制。三者的能力阶梯是：

7BIT（无扩展） → 8BITMIME（保留高位，受行长限） → BINARYMIME+CHUNKING（任意二进制，分块上传）。

实际部署中，MTA 一般三者都通告；发送方按内容类型与对端能力，选择最省编码代价的那一档。

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