RFC 6152《SMTP 服务扩展：8 位 MIME 传输》中文导读

1. 背景：SMTP 原只保证 7 位

原始 SMTP（RFC 821）只保证数据中每个字节的低 7 位在传输中不被改变，第 8 位（高位）可能被清除或出错。随着 MIME 让邮件正文可以携带非英文字符与二进制数据，需要在“如何把这些数据装进 SMTP”上做扩展。

RFC 6152 的 8BITMIME 扩展正是为此：它让服务端承诺“保留每个字节的 8 位”，客户端据此可以发送含高位字节的内容（例如 Latin-1、CRLF 之外的文本），而无需先对所有字节做 base64/QP 编码。它收录于 STD 71，废止了 RFC 1652。

2. EHLO 与 MAIL FROM 的 BODY 参数

服务端在 EHLO 中通告 8BITMIME 关键字。客户端若发送 8 位内容，需在 MAIL FROM 上用 BODY 参数声明正文类型：

C: EHLO client.example.org
S: 250-server.example.net Hello
S: 250-8BITMIME
S: 250 OK
C: MAIL FROM: BODY=8BITMIME
S: 250 OK

• BODY=7BIT：默认值，表示正文无高位字节（或高位被清零），兼容传统 SMTP。
• BODY=8BITMIME：表示正文中可能含高位字节，服务端必须原样保留。

3. 服务端的保位义务与限制

一旦协商 8BITMIME，服务端有两个明确义务：

• 保留全部 8 位：必须保证邮件在存储与转发过程中，每个字节的 8 位都被保留，不得清除高位。
• 行长仍受约束：8BITMIME 不放宽 RFC 5321/821 关于行长的限制——每行（含 CRLF）仍不得超过 1000 octet，且 CR/LF 之外不得出现裸 CR 或裸 LF。

这是 8BITMIME 常被误解之处：它只保证“位被保留”，不提供任意二进制透明传输。超过行长、或含 NUL、CR/LF 之外控制字符的二进制数据，仍然无法用 8BITMIME 直接发送，必须借助二进制扩展（见 RFC 3030）或 MIME 编码。

4. MIME 与 8BITMIME 的配合

8BITMIME 解决的是“传输层保留 8 位”，而正文如何解释由 MIME 负责。常见组合是：邮件声明 Content-Transfer-Encoding: 8bit，配合 8BITMIME 传输，正文即可直接携带 UTF-8 等 8 位文本，省去 base64/QP 的膨胀。

若服务端不支持 8BITMIME，发送方必须把正文改为 7bit 编码（QP/base64），否则高位字节会在传输中被破坏。这也是为什么“检测对端能力再决定编码方式”是邮件客户端与 MTA 的标准逻辑。

5. 与二进制扩展的边界

8BITMIME 之上还有 RFC 3030 的 BINARYMIME/CHUNKING，后者才允许传输任意二进制（包括超长行、NUL 等）。两者是递进关系：

8BITMIME = 保留 8 位 + 仍受行长限制；BINARYMIME（配合 CHUNKING）= 完全二进制透明。理解这条边界，才能正确选择“何时只需 8BITMIME、何时必须用二进制扩展”。

对运维而言，现代 MTA 普遍同时通告 8BITMIME 与 CHUNKING；当发送含大段二进制附件时，BINARYMIME 可避免 base64 膨胀，但前提是链路每一跳都支持相应扩展，否则需要降级回 8BITMIME 或 7BIT 编码。

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