摘要

  • RFC 2062 把旧 IMAP 形式移出主协议，却保留了一份供新旧实现相遇时使用的有限地图。
  • 新服务器不必支持旧命令，并且原则上不得发出旧响应；客户端对若干旧响应则需要忽略、接收或转换。
  • 能够接收旧形式，不等于发送方继续生产旧形式获得了永久许可。

连接两端很少在同一天升级。新服务器可能仍会遇到旧客户端，新客户端也可能连上旧服务器。迁移期间真正需要的不是“全盘保留”或“一刀切删除”，而是明确谁可以发、谁需要收，以及这种例外何时结束。

RFC 2062 只有八页，而且是 Informational 文档。它明确说明自己不是 Internet 标准。它的任务是把 RFC 1176、IMAP2bis 实践和 RFC 1730 中已经退出 IMAP4rev1 主体的语法集中保存。历史被记录下来，但不再占据新协议的默认生产路径。

旧命令包括 FIND ALL.MAILBOXES、FIND MAILBOXES、带额外关键字的 SUBSCRIBE MAILBOX 和 UNSUBSCRIBE MAILBOX，以及 PARTIAL。旧 FETCH 项还包括 BODY[0]、RFC822.HEADER.LINES 和若干 PEEK 形式。RFC 2062 没有要求新服务器实现它们；实现者可以为了旧客户端而选择兼容，却不能把这种选择说成新客户端应当继续使用旧命令的理由。

PARTIAL 说明替代语法并非换个名字。它通过 FETCH 返回数据，却没有在响应里标明返回区间；多个命令又可能乱序执行，因此客户端不能只把片段连续拼接，而必须逐步处理和同步。后来的局部 FETCH 可以承担相似功能，同时形成更清楚的请求—响应证据。

响应规则更能体现方向。新服务器原则上不得发送旧响应。MAILBOX 只有在回答旧 FIND 命令时才有例外。客户端必须忽略旧的逐消息 COPY 响应，并把旧 STORE 响应按 FETCH 处理。“兼容接收”在这里分别意味着受条件解析、无害丢弃和语义归一化，而不是照单全收。

RFC 2683 后来明确警告：某些服务器碰巧接受旧命令，不代表客户端发送它们就是正确行为。RFC 2061 也把兼容建议和主协议义务分开，并建议即使为了老客户端，也不要重新实现已经退出的 bboard 命令。容忍是退场通道，不是旧语言的续期权。

这条方法在后续版本中仍可见。RFC 3501 将 RFC 2062 作为历史材料保留。RFC 9051 则通过能力声明和 ENABLE IMAP4rev2 让版本选择显性化；同时声明两个版本的服务器，一般不会主动返回 rev2 已删除的形式，除非 IMAP4rev1 客户端明确请求相关行为。这是相似的工程方向，不能反推为 RFC 2062 对后者的直接因果。

运维证据也必须有方向。解析器测试通过，只能证明组件能接收；它不能证明组件被配置为发送。服务器接受 FIND，不能证明客户端应当发送 FIND。IANA 登记了能力名，也不能证明某个产品实际部署或某次连接走了哪个模式。

可验证的退役至少保留四类记录：允许的输入语法、选用的输出语法、对端协商模式和线上实际字节。先停止旧输出，再统计残余旧输入，把例外限定到具体对端，最后在需求消失后移除解析器。这样，兼容性承担的是有限接收义务，而不是替旧生产行为无限续命。

来源