摘要

  • RESERVE 让邮箱名不再可被其他请求者占用，但 RFC 3656 明确说明，这不代表邮箱此刻已能供客户端访问。
  • MAILBOX 才描述可访问的活动记录；通常要先在本地创建邮箱，再执行 ACTIVATE。规范推荐这套顺序，却依靠参与方合作，并未把预留设为服务器执行激活的硬性前提。

先占名字，再准备邮箱

一组邮件服务器必须回答两个不同的问题：这个名称由哪台服务器负责？客户端现在能否访问对应邮箱？2003 年 12 月发布的实验性协议 RFC 3656 把两种答案拆开。MUPDATE 试图让多个 IMAP 或 POP3 服务器共享统一邮箱名空间，同时分担邮件投递。

典型创建流程从 RESERVE 开始。客户端请求主服务器在某个位置保留一个邮箱名。收到 OK 之后，客户端才在本地执行创建操作，随后发送包含名称、位置和 ACL 的 ACTIVATE。激活成功后，数据库记录变为活动状态。位置字段可以指向实际存储邮箱的服务器；ACL 描述该邮箱的访问权限。

两类响应把边界写得很清楚：RESERVE 表示该名字已不能再被其他请求者取得，但规范特别指出，这不表示邮箱当下已对客户端开放。MAILBOX 才表示记录已经准备好供客户端访问。若把二者混为一谈，就会把名空间锁误读为可用性信号：本地邮箱可能还不存在，创建步骤也可能尚未完成。

原子性依赖参与方共同守约

MUPDATE 描述一个持有权威数据库的主服务器，以及接收复制的从服务器。客户端可以向任一方查询，但数据库修改应发往主服务器。因此，邮箱创建跨越两个边界：分布式名称登记与本地邮箱存储。协议对它们进行协调，却没有把它们变成一个原子事务。

规范措辞体现了这个限制。新邮箱 SHOULD 先保留再激活，因为设计假定所有已认证参与方会合作维持原子操作。不过，ACTIVATE 并不要求之前已有 RESERVE。规范允许这样做，以便与实际邮箱位置同步。若参与方绕过共同锁定约定，数据库就可能出现不一致；未向数据库报告的本地事务，数据库无从推知。

DEACTIVATE 会把活动名称退回保留状态，但不等于从名空间中删除它。RFC 还提醒，已知 ACL 信息在该转换中 MAY 丢失。因此，在迁移或创建中断时，名称可能仍被占用，却没有活动邮箱被公布。位置记录也不能证明客户端成功登录或读到了邮件。

副本的 OK 有明确边界

从服务器发出 UPDATE 后，主服务器先发送数据库初始列表，随后再推送变化。RFC 要求主库发生变化后，主服务器须在 30 秒内将更新流给从服务器。从服务器可以发送 NOOP；在 UPDATE 会话中，服务器只有在把该 NOOP 时刻之前所有待发送更新发完后，才能返回 OK。这个响应划定了一个同步时点，却不保证此后数据库仍持续保持全局最新。

这是有用但有限的回执：它说明某个副本在某一刻收到了哪些已排队变化。它不能证明随后发生的主库更新已抵达、本地邮箱存储运行正常，或最终用户已经访问。RFC 3656 属于实验性协议；它记录的是一种协调契约，不是当代部署状况或实测可用性。

来源