摘要

  • IMAP COMPRESS 只有在带标签的 OK 到达后才启动：服务器从该答复结尾的 CRLF 之后压缩，客户端则从下一条命令开始压缩。
  • 反复出现的命令、头字段和正文因共享历史而变短，后续字节却也因此依赖隐藏状态。后来的安全规范说明密文长度仍可能泄露关联，但没有证明发生过专门针对 IMAP COMPRESS 的攻击。

同一条流在一处换了读法

IMAP 原本就以带标签的命令、无标签的数据和呼应标签的最终结果组织会话。RFC 4978 没有发明新的答复类型。服务器公布 COMPRESS=DEFLATE，客户端发出 COMPRESS DEFLATE，仍由熟悉的 OK、NO 或 BAD 给出裁决。

平常的外观包着一条严格规则：裁决回来以前，客户端不得再发下一条命令。若结果为 OK，它此后的第一条命令必须压缩。服务器仍以未压缩形式发完成功答复，却要从终止该行的 CRLF 后立即启用编码器。拒绝则让两个方向都维持原状。

于是，一个字节位置取得了权威。客户端切换太早，会把明文送进解压器；服务器切换太晚，会让客户端把压缩比特当成 IMAP 文法。即使 TCP 一个字节也没有丢、顺序也完全正确，会话仍会因双方赋予字节的含义不同而崩溃。

能力只表示许可，不表示收益

能力声明只说服务器懂得这个算法。它没有承诺某个邮箱一定变小、CPU 花费值得，也没有承诺连接保密。每个发送方可以选择自己的压缩强度，相对的一端负责解码它产生的流。

拒绝规则守住了这层窄含义。若同一压缩机制已经由别的层启用，服务器可用带 COMPRESSIONACTIVE 的 NO 回答。扩展已经启用后再次执行 COMPRESS 则是无效操作。两处都能协商某种变换，不等于可以盲目叠上两套相同的有状态处理。

两个方向也并非共用一个神秘词典。重复的客户端命令构成上行历史；服务器答复、字段名和邮件内容构成下行历史。每个发送者只记住自己输出过的字节。

层次顺序不跟随命令顺序

IMAP 会话还可能启用 SASL 安全层或 TLS。RFC 4978 规定了唯一的发送顺序：先压缩，再做 SASL 的签名或加密，最后由 TLS 保护；接收时反向拆解。

即使客户端以另一先后次序请求这些功能，数据变换的次序也不改变。协商发生的时间与线上处理顺序是两件事。COMPRESS 因而必须理解 IMAP 状态机，不能假装自己只是底层一根透明管道。

现行 IMAP4rev2 对安全层切换也保留这种一般纪律：成功答复所结束的位置，就是新层开始的位置。一条长连接可以改换表示或保护方式，前提是双方只承认同一条边界。

重复让历史变得值钱

IMAP 很适合压缩。客户端一遍遍使用少量动词；服务器反复输出固定答复和邮件头名称；同一讨论串又会引用旧句。不断增长的历史可以用短引用替代后来出现的重复片段。

附件却会改变局面。已经压缩的归档文件或 JPEG 往往难以再缩小，还会把有用的 IMAP 模式挤出词典，让 CPU 学习不会重现的材料。规范讨论了在大块 literal 前后做完整刷新，也讨论了遇到疑似不可压缩格式时降低压缩强度。这些是本地调节，不是新的线上命令。

应用层压缩的优势恰恰来自贴近 IMAP：它知道接下来是语法、邮件头、文本还是 literal。知识能节省字节，也使应用必须为由此保留的历史负责。

加密没有让长度失去含义

2007 年的 RFC 4978 只用一句话把安全问题指向当时的 TLS 压缩考量。后来被总结的攻击改变了业界认识。CRIME 等研究说明，内容虽被加密，长度仍可能被观察。若秘密与攻击者可影响的文本进入同一段压缩历史，反复改变猜测就可能从尺寸差异看出它是否接近秘密。

IETF 汇总的案例涉及 TLS 和 Web，并未证明 IMAP COMPRESS 已遭专门利用，也不能证明所有 IMAP 场景都有漏洞。但它足以推翻“先压缩再加密便不再泄露信息”这种简单推论。

当前 TLS 最佳实践不建议 TLS 1.2 使用普通记录层压缩，除非应用已经被证明不受此类攻击，而且仍须极其谨慎；TLS 1.3 已将这种压缩删除。规范同时警告，TLS 之上的压缩也会产生 TLS 无法自行修补的泄露。应用越懂自己的数据，越需要决定哪些来源可以共享记忆。

隐藏状态必须有主人

逻辑上的 IMAP 消息没有改变，编码后的字节却依赖此前字节。只有双方持续同意启用点、方向、算法与上下文，收益才存在。解码失败、资源耗尽或保密疑虑，也无法仅凭加密后的抓包直接说明。

持久教训并不是笼统地禁止压缩秘密，而是为上下文命名：谁能影响输入，谁能看见输出长度，历史保存多久，解码能耗费多少资源，又怎样在不破坏会话的前提下关闭。会记忆的优化，本身就是状态机。

来源与边界

DEFLATE 格式见 RFC 1951；IMAP capability、切换边界、分层顺序和调节建议来自 RFC 4978。RFC 7457 汇总压缩攻击类别，RFC 9051 是现行 IMAP 核心，RFC 9325 给出当前 TLS 建议，COMPRESS=DEFLATE 仍列在 IANA IMAP 注册表中。这些来源没有测量当前使用率，也没有记录一宗具体 IMAP COMPRESS 入侵。