摘要

  • RFC 3516 允许 IMAP 服务器去掉 MIME Content-Transfer-Encoding，再用 BINARY 返回解码后的正文段；若数据包含 NUL，则可通过 literal8 承载。这个结果是解码视图，不是原始序列化邮件。
  • BINARY.SIZE 和 partial 偏移都以解码数据为坐标。存储形式、FETCH BODY、文本 CRLF、编码词头部与密码学覆盖范围仍是不同证据面。

Base64 解决的是老式邮件路径无法透明传送任意字节的问题。它把二进制数据变成较安全但更长的文本表示。到了邮件读取阶段，客户端可能先把扩大后的表示下载一遍，随即又在本地撤销它。RFC 3516 指出，在慢速无线链路或流媒体场景中，这份额外成本并不抽象。

2003 年 4 月发布的 IMAP4 Binary Content Extension 把解码工作移到了服务器。服务器在 CAPABILITY 中声明 BINARY 后，客户端可以请求 FETCH BINARY。服务器先撤销所选 MIME 正文段的传输编码，再发回结果。节省带宽与客户端计算是真实收益，但返回的字节并不会因此变成邮箱最初接收的那份邮件。

IMAP 的每个正文段都有 MIME Content-Transfer-Encoding。没有显式字段时，它被视为 7bit。在 MIME 语义中，CTE 同时规定解码算法与解码后数据所属的取值域。base64 与 quoted-printable 会明显改变表示；另一些 CTE 即使不改变数值，也可能声明基础 IMAP literal 无法表达的域，例如含有 NUL 的数据。

因此，RFC 把服务器处理拆成两个逻辑步骤。第一步执行与 CTE 有关的解码，第二步判断解码结果的域。得到一串字节，并不自动回答应该用哪一种 IMAP 协议元素来承载。

为此新增的 literal8 以波浪号和长度开头，随后可以传输任意字节，包括 NUL。如果数据属于八位域但不含 NUL，服务器应尽量使用普通 string。这样客户端无需扫描整个数据流，也能从外层表示知道结果是否跨入了更宽的域。

长度声明很精确，但权限有限。它证明这一次 IMAP 响应元素中随后有多少字节，不能证明服务器内部也按同样形式存储。服务器可能刚刚从 base64 重建数据，可能一直保存着未编码正文，也可能使用另一种符合要求的内部表示。

BINARY.PEEK 处理的又是另一条边界。它像 BODY.PEEK 一样，不会因为读取而隐式设置 \\Seen。这个承诺涉及邮箱状态，而不是字节来源。邮件仍显示未读，并不能把服务器生成的解码视图升级成原始邮件。

BINARY.SIZE 报告所选段撤销 CTE 后的长度，也就是相应 FETCH BINARY 应返回的字节数。它不是编码后正文的长度，不是物理存储占用，也不是整封邮件或渲染后附件的大小。RFC 还提醒，实现可能必须实际解码才能计数，滥用这个查询会让服务器付出显著成本。

partial 读取使坐标系问题更明显。FETCH BINARY 的起点和长度都指向解码后的段。在 base64 文本或 FETCH BODY 结果中的某个偏移，通常不会落到相同内容。若客户端拿编码视图的断点续传计数去恢复 BINARY 流，服务器仍可能返回语法正确的片段，只是逻辑位置已经错了。

服务器不认识某个 CTE 时，协议禁止猜测。BINARY 与 BINARY.SIZE 都必须以带 UNKNOWN-CTE 扩展码的 NO 失败。这张回执说明当前服务器无法按所声明规则执行转换，并不自动说明邮件损坏。

后来的 RFC 4466 更新了 IMAP 响应码框架，RFC 9051 又把二进制机制纳入 IMAP4rev2。现代轨迹需要结合这些文档解读，但无论版本如何，编码正文、解码段和内部存储都没有被合并成同一份字节证据。

邮件头部另有边界。RFC 2047 的 encoded-word 让某些头部位置能够承载非 ASCII 文本，它不是 MIME 正文的传输编码。RFC 3516 因而明确禁止服务器在 BINARY FETCH 或 APPEND 中顺手转换这些编码词。获得“解码正文”的权限，并不等于可以改写邮件里所有看起来像编码的文本。

面向行的文本段还必须使用 IMAP 的 CRLF 行结束形式发送，不论服务器本地怎样保存。这个规范化让协议输出稳定，却也说明返回文本不是服务器磁盘换行字节的取证镜像。

文档对存储边界说得更直接：服务器可以用未编码形式保存二进制正文，但 BODYSTRUCTURE 仍必须把邮件描述成基础 IMAP 可以接受的 CTE 形式，FETCH BODY 也必须返回与该描述一致的表示。协议接口提供的是可互操作的合约，不是内部内存或磁盘直读。

APPEND 从相反方向穿过同一边界。客户端可以用 literal8 提交含 NUL 的数据。目标邮箱不能保存二进制时，服务器必须用 UNKNOWN-CTE 拒绝；能够保存时，服务器可以修改 CTE，但转换不能丢失正文载荷。

“不丢载荷”仍不等于“序列化邮件相同”。base64、quoted-printable 与直接表示可以恢复出同一载荷，却由不同字节组成。CTE 字段、头部折行和换行同样属于邮件序列。于是，一次内容无损的改写仍可能破坏针对原序列计算的摘要或签名。

RFC 3516 对此给出明确警告：不必要的编码变更会让多数已经对邮件执行的密码学操作失去用途。两个要求并不矛盾。一个保护可恢复内容，另一个依赖精确字节和被覆盖的头部。只记录“无损转换”，没有记录验证器真正消费了什么。

扩展也没有免除客户端自己的 MIME 解码能力。它是特定条件下的优化，不是新的通用存储格式。支持 BINARY 的客户端仍应准备自行撤销 CTE。能力协商提供快路径，不应成为普通编码路径失效的理由。

Heng Lu 对符号现实与运行现实的区分可以整理这条证据链。CAPABILITY 里的 BINARY 是能力声明；BINARY.SIZE 是对某个解码响应长度的承诺；计数 literal 是一条连接上实际观察到的序列。存储字节、RFC 5322 邮件、MIME 载荷、屏幕呈现与签名验证输入处在相邻但不能互相替代的层。

可靠回执应先固定邮件标识与读取上下文，再记录 BODYSTRUCTURE、所选段、原 CTE、命令形式、\\Seen 影响、响应码、数据域、literal 长度、partial 偏移以及完整返回字节的哈希。若需要证明原始邮件身份，还要另行取得 raw message 并计算哈希；若涉及签名，则要记录规范化规则与验证器的精确输入。

这样，两句真实陈述便不再冲突：服务器确实正确返回了解码正文，而下载文件的哈希也确实不同于所存或所传邮件。RFC 3516 没有要求任何一方错误，它定义的正是两者之间的转换。

这项扩展的历史成果很务实：二进制内容不必在每次 IMAP 读取时继续为另一段传输路径设计的编码付费。它留下的更深教训是证据克制。服务器解码了正文，客户端拿到了有用字节；原始邮件仍需自己的读取、哈希与证明。

来源