摘要

  • IMAP 的 CLOSE 不只是结束当前邮箱的 Selected 状态。对可写邮箱执行它，还会永久移除全部带 \Deleted 标志的邮件，而且不逐封发送 EXPUNGE 响应。
  • 2004 年的 RFC 3691 增加 UNSELECT：同样释放选中邮箱的服务器资源、回到 Authenticated 状态，却不执行永久删除。协议因此把状态退出与不可逆提交变成两个可审查的决定。

一个同步程序已经看完收件箱。它还要保持认证连接，以便稍后检查别的邮箱，但眼下不想继续占用当前邮箱的选中状态。服务器里恰有几封邮件带着 \Deleted 标志；这些标志可能来自刚才的操作，也可能来自另一个客户端。此时程序需要的只是“离开”。

早期 IMAP 中，名字最像这个意图的命令是 CLOSE。但它的含义比“关上”更重：在可写的 Selected 状态下，服务器先永久移除所有带 \Deleted 的邮件，再把连接送回 Authenticated 状态。命令完成时只需给出带 tag 的结果，不会为每一封被移除的邮件发送无 tag 的 EXPUNGE 通知。

客户端交回的是一个工作上下文，协议却同时把尚未结算的删除标志变成最终结果。状态机上的一条退出边，携带了对持久数据的处置权。

RFC 3691 用一个极短的新命令修正了这处语义缝隙。UNSELECT 不接受参数，成功后同样释放与当前邮箱有关的资源并回到 Authenticated 状态，但一封邮件也不永久移除。它没有创造新的邮件能力；它只是让一个早已存在、却只能绕路表达的意图获得自己的动词。

邮箱被选中，是协议状态而不是界面焦点

IMAP 把连接分成不同状态。认证完成后，客户端可以列出或选择邮箱；只有进入 Selected 状态，许多针对邮件的搜索、读取、标记、复制和删除操作才有明确上下文。服务器也要维持与这个上下文有关的计数、标志与通知。

结束 Selected 状态不等于断开网络连接。桌面客户端可能从 Inbox 切到 Drafts，同步器可能暂时释放服务器资源，稍后继续使用同一认证会话。因此，从 Selected 回到 Authenticated 是一个普通而有价值的状态转换。

CLOSE 在状态图上完成了这条转换。问题在于，状态图的终点没有说出沿途发生了什么。两个操作都能抵达 Authenticated，其中一个可能删除持久内容，另一个不会。只记录“已经退出 Selected”会把最重要的差异抹掉。

\Deleted 本身也不是物理删除。它先把邮件标成等待移除，真正的 expunge 才跨过不可逆边界。这样的两阶段安排允许客户端先标记、复核，再决定何时清除；也意味着“谁设置标志”和“谁触发最终移除”可能不是同一个时刻、同一个进程，甚至不是同一个人。

当 CLOSE 同时负责退出和 expunge 时，最后那个看似行政性的清理命令，便替所有既存标志作出了最终决定。

少发响应提高效率，却不会减轻副作用

普通 EXPUNGE 命令也会永久移除全部 \Deleted 邮件，但它会为每次移除发出无 tag 的 EXPUNGE 响应。响应使用 message sequence number；这种编号表示当前邮箱中的位置，前面的邮件被移除后，后续位置会随之移动。

如果客户端马上离开邮箱，它往往不会再使用这串位置变化。标准因此解释了 CLOSE 的性能收益：当待删邮件很多时，省去客户端大概会忽略的逐项响应，可以明显减少往返数据和处理成本。

然而，响应更少不代表效果更轻。带 tag 的 OK 只能说明 CLOSE 完成，并不是“没有删除”的回执；它也不是一份逐封列出的删除清单。把响应长度当成风险大小，会恰好误读这个设计。

只读模式又增加了一层条件。邮箱若由 EXAMINE 打开，或以其他方式处于只读状态，CLOSE 不会移除邮件，也不会因为没有移除而报错。同一个命令 token 在不同选择模式下可以产生不同的持久结果。排障若只看命令名和成功码，便无法说明事实。

至少还要知道：选中了哪个邮箱、选择是否可写、执行前哪些稳定 UID 带 \Deleted、客户端选的是哪一种退出路径，以及确认响应是否真正到达。

在 UNSELECT 之前，安全退出要借别的命令绕行

IMAP4rev1 并非规定每次离开都必须 expunge。客户端可以不先执行 CLOSE，直接 SELECT 或 EXAMINE 另一个邮箱，也可以 LOGOUT；这些操作会隐式结束当前选择，但不执行 expunge。

这条规则保留了不删除的可能，却没有给“只释放当前选择并继续认证”一个干净的命令。RFC 3691 记下了当时的两种做法。客户端可以故意 SELECT 一个不存在的邮箱，让失败把连接送回 Authenticated；也可以用 EXAMINE 重新选择同一邮箱，以只读打开来摆脱原来的选择方式。

第一种办法把预期失败当成正常控制流。日志会留下一个看似真实的选箱错误，统计无法区分设计动作与故障，未来服务器若优化失败路径，还可能碰断客户端依赖的隐含语义。第二种办法为了退出可写上下文，又建立一个并不需要的只读上下文。它们都能工作，却都没有直接表达意图。

协议缺的不是另一条捷径，而是一句不会让接收者猜测的话：释放这个选中邮箱，不要处置其中的邮件。

能力协商让新动词先获得共同理解

RFC 3691 规定，支持扩展的 IMAP4rev1 服务器用 UNSELECT capability 表明能力。客户端先确认对端理解这个命令，再发送它。未知命令的失败并不能冒充一次安全退出，因为失败时连接仍可能留在 Selected 状态，服务器资源也未必释放。

这种协商把兼容责任放在边界上。客户端不必凭服务器品牌或版本号猜测；服务器也无需把陌生语法解释成某种近似动作。双方先建立同一词汇，再执行语义明确的状态转换。

UNSELECT 的响应很短：没有参数，没有专属的无 tag 响应，成功后给出带 tag 的完成结果。安全性并非来自更长的回执，而来自发送前已知的命令定义。调用者选择这个动词时，就知道它没有 CLOSE 所携带的永久移除权限。

如果命令失败，客户端也不能悄悄假定已经退出。它需要保留当前状态的不确定性并采取恢复步骤。若客户端选择 CLOSE，则必须把永久移除视为请求的一部分，而不能称其为服务器在后台顺手进行的清理。

相同终点不表示相同过程

状态机擅长压缩复杂行为，却容易把边上的数据效果藏起来。CLOSE 与 UNSELECT 都能让正常会话抵达 Authenticated；它们在“下一条允许发送什么命令”这一问题上等价，在“刚才对邮件做了什么”这一问题上完全不同。

这类错误不限于电子邮件。数据库连接可能在 commit 后关闭，也可能 rollback 后关闭；文件句柄可以在 flush 后释放，也可以丢弃缓冲区；租约可能由主动归还终止，也可能因超时失效。若遥测只写一条 closed=true，操作结果的治理依据便消失了。

更可靠的记录要拆成至少三部分：状态转换、变更授权和结果证据。selection_released 不能推导出 expunge_committed；资源已经释放，也不能证明数据一定保存或一定删除。

UNSELECT 的历史贡献正是把这项拆分写进线协议。它让普通清理只做普通清理，让破坏性提交需要另一个可见选择。

安全退出不会撤销过去，也不会保证未来

UNSELECT 不会清除 \Deleted 标志，不会找回已经 expunge 的邮件，也不会说明谁设置了标志。客户端用它退出后再次选中邮箱，原有标志仍可能存在；后续的 EXPUNGE、CLOSE 或有明确 UID 范围的操作仍可永久移除邮件。

因此，UNSELECT 保存的是决定机会，而不是替所有邮件作出永久保留决定。它也不提供并发事务：其他会话仍可能改标志或执行移除。能力通告只证明服务器承诺理解命令，不证明用户界面展示正确、操作者身份可信或日志完整。

把窄能力说得准确，反而使它更可依赖。它保证的只有一件关键事实：通过这条退出边时，不因这条命令执行 expunge。

到 IMAP4rev2，例外成为基础语法

2021 年的 RFC 9051 把 UNSELECT 纳入 IMAP4rev2 的基本 Selected-state 命令。状态说明同时列出 CLOSE 和 UNSELECT 作为回到 Authenticated 的路径；各自定义仍保留决定性差别：前者在可写邮箱中永久移除全部 \Deleted 邮件，后者一封也不移除。

从扩展能力进入基础协议，记录了一种克制的修复方法。早期协议并非完全无法安全离开；它可以通过换选邮箱、退出连接或故意失败来取得结果。真正的问题是，正常意图没有正常表达。把它变成一等命令后，调用处可以被阅读，日志可以被解释，兼容不再依赖错误路径。

互联网协议常因新增巨大能力而被记住。UNSELECT 展示了另一种进步：删掉一个不必要的权限推断。客户端请求释放资源，服务器就释放资源；只有客户端明确选择带 expunge 语义的命令时，删除标志才越过不可逆边界。

确认丢失会把两条路径的差异放大

服务器可能已经收到命令，连接却在带 tag 的结果抵达客户端前中断。若发送的是 UNSELECT，主要不确定性是邮箱是否仍处于 Selected；若发送的是 CLOSE，还要面对删除可能已经永久发生。自动重放“最后一次调用”因此不是中性的恢复办法。

恢复应先重新连接，观察当前邮箱，把仍存在的稳定 UID 与中断前证据对齐，再判断用户意图是否需要继续。库接口也要保留这种区别：一个名为“关闭邮箱”的析构动作，不应在调用者看不见的地方默认提交删除。

OK 不是逐封清单。两个独立动词的优势，是在发送前就能判断效果类别，而不是事后从最短的成功码猜测。不可逆结果越重大，授权越应在入口处可读。

来源