摘要

  • 早期 IMAP literal 是嵌在一条命令中的计数字符串。客户端发送 {n} 后必须等到 + continuation，才可发送接下来的 n 个八位组以及余下的命令语法。
  • 1997 年 LITERAL+ 用 {n+} 取消等待。延迟下降的同时，服务器若不愿接收大 literal，只能排空已获准发送的数据，或关闭连接。
  • 2016 年 LITERAL- 沿用 {n+}，却把无需逐次许可的上限定为 4096。APPENDLIMIT 另行公开全局或邮箱级上传政策；2021 年 IMAP4rev2 将受限形式并入基础语法。

行结束了，命令没有

IMAP 的 literal 不能靠换行符收尾，因为它本身可以包含 CR 和 LF。协议先给出八位组数量，再逐个计数。最后一个八位组之后，解析器立刻回到同一条命令：那里可能是一个空格、下一个参数、另一个 literal，或真正结束命令的 CRLF。

因此 A001 LOGIN {11} 只结束了物理行，没有完成 LOGIN。RFC 2060 要求客户端暂停，等待服务器发出以 + 开头的 continuation。服务器若已从前缀看出错误，可以改发带标签的 BAD，禁止客户端继续。2003 年的 RFC 3501 保留了这一规则。

+ 的权限很窄。它没有接受整条 LOGIN，也没有保证 APPEND 成功，更没有预留邮箱空间。它只说明服务器已准备好接收这段命令的下一部分。甚至 {0} 也要等：没有负载可传时，许可本身仍然存在。

这与 TCP 窗口不同。传输层管理字节流缓冲，不认识邮箱、命令和配额。IMAP continuation 是应用协议在一个语法节点上设置的决定权。TCP 可以畅通，IMAP 仍可以说“先别发”。

一枚加号买走一次往返

1997 年 1 月发布的 RFC 2088 定义 LITERAL+ capability。只有服务器明确宣布支持，客户端才可把 {11} 写成 {11+}，无需等待便立即发送 11 个八位组。没有 capability，就继续使用同步形式。

加号没有取消计数。服务器仍须在行尾识别标记，准确吞入指定数量，再接着解析同一命令。它也没有把 literal 变成另一条消息。被取消的只有中间那次询问与答复。

在高时延线路上，一条含多个 literal 的命令会多次停顿。RFC 2088 的 LOGIN 示例把用户名和密码各写成一个非同步 literal，客户端可连续发送。对老服务器而言，capability 又是一条兼容边界：没有自愿承诺，就不能擅自提前。

当时的安全章节称没有已知问题。十九年后，问题并不在计数失去确定性，而在许可提前后，拒绝成本由谁承担。

否决到达时，字节已经被允许上路

RFC 7888 在 2016 年把困境写得很具体。LITERAL+ 允许任意大小的非同步 literal。客户端一报出巨大的 {n+} 就可开始发送。服务器即使很快判断命令超限，也面对两种都不理想的选择。

第一种是读完 n 个八位组，把它们丢掉，再拒绝命令。字节流保持同步，但网络、CPU 和内存已经付费。第二种是发 BYE 并断开连接，迫使客户端重连；朴素的自动化还可能原样重试。服务器可以提前发 BAD 或 NO，可判决不会让已获准的字节凭空消失。

APPEND 尤其棘手。多数参数很短，APPEND 却能携带整封邮件和附件。服务器为了抵御资源耗尽而设置大小限制时，大量数据可能已经进入连接。客户端节省的是自己的等待，服务器得到的是事后清理。

4096 不是邮箱配额

RFC 7888 废止 RFC 2088，同时规定 LITERAL+ 与 LITERAL-。前者允许扩展意义下任意大小的非同步 literal。后者只允许 4096 八位组及以下；更大的数据必须退回 {n}，重新等待 continuation。

线上并没有 {n-}。LITERAL- 的减号只在 capability 名里，literal 仍写 {n+}。所以服务器不能同时宣布 LITERAL+ 和 LITERAL-：客户端必须从协商结果知道这枚加号获得了无限制授权，还是只获得小额授权。

这条线保留了小字符串的速度，也为大负载恢复明确许可。但 4096 只回答“能否不等回复就发”，不回答“邮箱能否接受”。3000 八位组的 APPEND 仍可能失败；同步之后的大邮件仍可能成功。

它也没有消灭拒绝服务风险。大量小 literal、昂贵解析和反复重连仍会聚合成本。RFC 7888 只说 LITERAL- 部分改善资源暴露，而不是提供完整防护。

APPENDLIMIT 提供另一把尺

同月的 RFC 7889 定义 APPENDLIMIT。服务器可用 APPENDLIMIT=<number> 宣布所有邮箱共用的上传上限，也可只宣布 APPENDLIMIT，让客户端通过 STATUS 或 LIST-STATUS 查询各邮箱的值；NIL 可以表示没有这一上限。

合作的客户端因此可以在发送前避开一个必然超限的 APPEND。可是低于上限并不保证成功：ACL、配额和其他政策仍各自生效。若上限未知，RFC 建议 APPEND 不要使用非同步 literal，让服务器保留提前许可点。

两把尺的治理对象不同。4096 是一种语法授权的共同边界；APPENDLIMIT 是可能随邮箱变化的本地运营政策。把二者混成一个数字，会让共同协议假装知道本地存储，也会让本地配额冒充线上的解析规则。

等待没有被新版协议淘汰

2021 年的 RFC 9051 把 LITERAL- 语义并入 IMAP4rev2。字符串有引号、同步 literal 和非同步 literal 三种形式；除非扩展另有规定，超过 4096 就必须同步。

这意味着，现代基础协议吸收了优化，却没有把原始等待判为落后。它保留了两种路径：小额数据可用事先委托，大额数据重新询问。当前 IANA IMAP Capabilities 注册表 仍列出 LITERAL+、LITERAL- 与 APPENDLIMIT；注册证明名称和引用，不证明今天的部署比例。

这段历史不是“旧协议慢，扩展让它快”。它记录了一次决定权迁移：服务器原先逐段授权；LITERAL+ 把授权预先交给客户端；LITERAL- 缩小委托范围；APPENDLIMIT 再提供本地政策证据。真正稀缺的不是加号，而是接收方还能在成本发生前说“不”的位置。

来源与证据边界

这些材料没有测量当前支持率、实际延迟收益或攻击频率。continuation 不是整条命令的最终接受，4096 不是上传配额，APPENDLIMIT 也不保证更小的邮件一定成功。