摘要

  • RFC 2061 的旧版兼容建议不属于 IMAP4 的强制要求；选择回退，只代表客户端愿意继续尝试互通，不代表所有功能获得等价实现。RFC 2061
  • 预览后的标志补偿与复制后的元数据保留，是两种不同的证据问题：前者不能保证中间没有变化，后者不能由成功回复证明。RFC 2061、RFC 2060

一封邮件已经出现在预览窗里，邮箱却未必原封不动。RFC 2061 建议以 BODY[section] 替代 BODY.PEEK[section]，再按需清除 \Seen。字节可以拿到，“不改变标志”的承诺却需要另算。这正是它留下的兼容问题：客户端愿意接通旧服务器，是否也说清了自己放弃什么？RFC 2061

1996 年：接纳旧软件是一项选择

1996 年 12 月，University of Washington 的 Mark Crispin 发表这份资料性备忘录，而非互联网标准。文中称 IMAP2bis 当时很常见，随 Pine 广泛分发，却没有确定的协议说明文档。作者承认材料来自不完备的实现知识与流传经验，聚焦最可能遇到的旧变体；这些陈述不是市场份额测量，更不能说明今天的部署情况。是否容忍旧软件，仍由实现者决定。RFC 2061

时间线不能压成一个“旧版 IMAP”：1990 年 8 月的 RFC 1176 是 IMAP2 基线，不是 IMAP2bis 的定本；1994 年 12 月的 RFC 1730 规定 IMAP4，1996 年 12 月的 RFC 2060 则是 IMAP4rev1，同时支持两版须分别查阅。1994 年 12 月的 RFC 1732 涵盖更广的旧版兼容，包括较罕见变体，不能与范围收窄的 RFC 2061 互换使用。

先选路径，再逐项核对承诺

按 RFC 2061，CAPABILITY 返回 OK 时可获知服务器支持的 IMAP4 变体；客户端若一个也不认识，就按 IMAP2bis 处理，BAD 则指向 IMAP2bis 或更旧版本。这是客户端分流的经验规则，不是未知服务器的可靠指纹。超时、认证或安全失败不能统统算作 BAD，识别结果也不能替后续命令及其效果作保。RFC 2061

以下三类是本文对备忘录的分析归类，不是 RFC 2061 的正式术语。

分析类别 具体做法或界限 承诺在哪里缩小
可用、目标近似等价的替代 LIST 改用 FIND ALL.MAILBOXES；序列中的 * 换成服务器主动发来的 EXISTS 回复所报的消息数。 前者的语法和回复类似 RFC 1176 的 FIND MAILBOXES，但后一个命令本身不大可能提供有用信息；消息数代换不等于冻结邮箱快照。
语义近似或补偿 SEARCH 扩展退回 RFC 1176 语法，可能拆成多次搜索；BODYSTRUCTURE 换成不可扩展的 BODY；HEADER、TEXT、MIME、HEADER.FIELDS、HEADER.FIELDS.NOT 段选择改用段编号。 不能靠改名补出相同字符集、搜索条件或更丰富的结构与段选择语义；读取和标志补偿还须单独检验。
没有等价功能 UID 获取项、UID 命令与 CLOSE 均无功能等价物；LSUB、SUBSCRIBE、UNSUBSCRIBE 无直接功能等价物。 消息序号不是持久标识替身，EXPUNGE 拼接其他命令也不能冒充 CLOSE。

这些映射及缺口来自 RFC 2061。旧式 bboards 另有含义，不能当作订阅功能的通用替代；备忘录甚至建议新软件不要实现这些旧命令，服务旧客户端的服务器也不例外。兼容并不是把一切旧功能重新堆回去。

先改再补，不是从未改过

RFC 2060 明确区分：普通 BODY[section] 隐式设置 \Seen，BODY.PEEK[section] 不会。它还允许其他代理改变标志，并建议服务器自动发送标志更新。因此，本文对 RFC 2061 补偿办法的判断是：在标志可变且共享的场景里，取回后再清除是一串状态写入，不保证其他观察者看不到中间变化。

原先已有的 \Seen 不能盲目清掉；即使操作前没有，另一客户端也可能在补偿前设置它。仅凭操作前后的两个值，不能保证清除的是本次读取造成的变化。这是条件性的并发分析，不是 RFC 2061 记载的事故，也不表示所有服务器共享标志；该文没有提供原子恢复机制。RFC 2061、RFC 2060

“静默”也有类似边界。FLAGS.SILENT、+FLAGS.SILENT、-FLAGS.SILENT 改用相应的非 SILENT 写法，客户端忽略返回的无标签 FETCH。忽略只是本地处理选择，回复仍然产生，服务器上的修改及其他参与者可能观察到的效果也不会因此消失。RFC 2061

成功回复没有附送的保证

COPY 的问题不是能否收到成功，而是成功没有证明什么。RFC 2061 说，IMAP2bis 对复制是否保留标志和内部日期含糊不清，无法据此知道服务器行为。RFC 2060 的保留要求是 SHOULD，不能追溯套给 IMAP2bis。逐台实验可以证明某次观察，补不出缺失的普遍契约。RFC 2061、RFC 2060

错误上下文同样不能丢：IMAP2bis 的 TRYCREATE 出现在单独的非请求 OK 回复中，不在 NO 内。解析器须辨认这种提示形式，却不能把提示当成失败的 COPY 已经成功。反向互通的结论也有前提：备忘录对“编写良好的”IMAP2bis 客户端连接 IMAP4 服务器，仅报告带引号字符串中的反斜杠问题；含反斜杠或双引号时建议使用字面量。这不是对全部旧软件的兼容担保。RFC 2061

文中以 LOGIN 代替不可用的 AUTHENTICATE，同时明确不讨论安全。它只是历史兼容建议，不是今天明文登录或安全降级的依据。2018 年 1 月的 IETF 文件 RFC 8314 提供邮件提交与访问的后来 TLS 安全边界，不能倒推为 1996 年已有相应部署。RFC 2061

后来的观点，只用于解释这道边界

Lu Heng 在 2026 年论自愿采用的文章中写道：“Non-adoption is not a violation.” 本文借此理解客户端自愿选择兼容范围，而不是把拒绝回退算成协议违规。他在 2025 年讨论现实层与象征层的文章中写道：“Most conflicts persist because participants mix these layers.” 本文仅借其区分名义宣称与可执行效果的视角，提醒读者：识别到某个能力名称，不等于验证了某次操作。两篇文章都是后来的解释框架，不是 IMAP 实现测量，更不能证明 Mark Crispin 在 1996 年的意图。

来源与证据边界

来源 用途与限度
RFC 2061：IMAP4 与 IMAP2bis 的兼容 1996 年 12 月的主要史料；记载自愿兼容、命令映射和明确未知项，不是完整实现调查。
RFC 2060：IMAP4rev1 规范 1996 年 12 月的同期规范；核对正文获取、标志更新与复制语义，不替旧变体补写承诺。
RFC 1176：IMAP2 规范 1990 年 8 月的旧语法基线，不是 IMAP2bis 的确定描述。
RFC 1730：IMAP4 规范 1994 年 12 月的版本，须与 1996 年修订区分。
RFC 1732：IMAP4 与 IMAP2、IMAP2bis 的兼容 1994 年 12 月的较广兼容背景，不能代替 RFC 2061 的具体建议。
RFC 8314：邮件提交与访问的 TLS 安全要求 2018 年 1 月的后续安全依据，仅用于划清历史登录建议的适用边界。
Lu Heng：最小初始规范、局部后续决策与自愿采用 2026 年的协调观点，用于解释自愿选择兼容范围，不作为 1996 年史实。
Lu Heng：现实层、象征性权力与清晰表达为何显得刺耳 2025 年的解释框架；应用于命名与实际效果的区分，是本文的分析。