摘要

  • 客户端只有在本次会话的 EHLO 响应明确出现 8BITMIME 后，才能声明 BODY=8BITMIME，再发送最高位为一的八位字节。
  • 服务器一旦接收，便承担逐位保全责任；下一跳不具备能力时，中继只能无损转换成合法七位 MIME，或把障碍作为永久投递失败。

内容会说明自己，道路却没有随之加宽

MIME 让邮件能声明媒体类型、字符集和传输编码。这解决的是内容如何被解释，并不会自动改变 SMTP 的承载边界。RFC 2045 区分 7bit、8bit 与 binary。一段 MIME 正文可以在语义上完全正确，却含有下一台中继从未承诺保留的高位字节。

因此，8BITMIME 的历史不只是“邮件终于能写非英语”。真正的问题是责任落点：哪一台运行中的服务器在这次连接上接收了这些位，它的承诺又到哪里结束？

三份 RFC 稳定了一项很窄的承诺

RFC 1426 于 1993 年 2 月发布第一版 8bit-MIMEtransport 扩展；RFC 1652 在 1994 年 7 月取代它；RFC 6152 又在 2011 年 3 月取代 RFC 1652。这条文档链能证明规范演进，不能证明今天的部署比例。

服务器在成功的 EHLO 响应中列出 8BITMIME。IANA SMTP 服务扩展注册表 至今保存该关键字，不带 EHLO 参数，并指向 RFC 6152。扩展没有发明新命令。

客户端只是在 MAIL FROM 后增加可选的 BODY=7BIT 或 BODY=8BITMIME。BODY 说明随后 DATA 正文的字节域，不说明语言、字符集或媒体类型。运输许可和内容含义从来不是同一字段。

获准证据只属于当前连接

发送八位正文之前，客户端必须先发 EHLO，并收到含关键字的 250 响应。若 EHLO 失败或响应没有关键字，就不得传输 US-ASCII 范围以外的字节。TCP 能搬任意字节，不等于 SMTP 软件已经承诺正确处理；昨天同一品牌的服务器曾经支持，也不能代替这次会话的证据。

承诺只覆盖这一跳。第一台中继可以接收正文，随后却发现第二台不支持 8BITMIME。前一台的能力声明既不能替后一台发言，也不能保证终端程序会正确显示字符。

接收意味着保住每一位

支持扩展的服务器接收八位正文后，必须保留经 DATA 进入的每个八位字节，并以不丢位的方式投递或继续中继。这项责任穿过队列文件、内容扫描器、内部数据库与出口进程。若入口宣布支持，内部旧组件却清掉最高位，运行中的系统就没有兑现自己的声明。

这并非身份或安全保证。它不认证发件人，不证明内容无害，也不保证最终投递。它只建立一条可以核验的保管义务：已接收的字节不得因七位时代的隐含假设而变化。

八位并不等于任意二进制

DATA 仍采用行结构和点透明。单独一行句点仍结束正文，行首句点仍需转义，CRLF 仍有结构意义。RFC 6152 还保留行长限制：服务器可以只保证接收含 CRLF 在内不超过 1,000 字节的一行。

所以 8BITMIME 支持 MIME 的 8bit 传输编码，却不支持 binary。它扩展了行内字节值，没有取消“行”本身。后来 CHUNKING 与 BINARYMIME 处理的是另一种边界。

下一跳会重新提出问题

若下一台服务器没有宣布 8BITMIME，中继不能抱着“也许能用”的想法直接发送。RFC 6152 给出两条路：将消息无损转换成合法的七位 MIME，必要时使用 quoted-printable 或 base64；或者把这道障碍视为永久投递错误。

规范没有规定转换算法，因为转换并非机械清除最高位。邮件头、多段边界、换行、传输编码标签和签名都可能受影响。输出全是七位字节，并不等于收件人看到的内容没有变化。无法证明无损时，明确失败比伪装成功更诚实。

声明让证据可以对齐

BODY=8BITMIME 是客户端的声明，不会凭关键字自动变成真相。运营记录至少要分开保存：对端宣布了什么、客户端声明了什么、正文实际出现了什么，以及遇到下一跳时采取了什么动作。否则一个乱码字符可能来自发送端、错误降级、内部清位或最终渲染，无法归责。

8BITMIME 最持久的贡献，就是把范围说清楚。MIME 描述货物；本次 SMTP 会话决定这位保管人能否接手；下一条连接必须重新询问。

来源与证据边界

规范沿革来自 RFC 1426、RFC 1652 与 RFC 6152；RFC 2045 定义 MIME 字节域，IANA 注册表 记录当前扩展。它们不能证明当代部署率、厂商默认值或转换频率。