摘要

  • RFC 10022 允许 IMAP 客户端取得接近指定消息数量的降序 UID 范围，在 UIDONLY 模式下也能预先划分后续工作。这些范围不是快照，也不是保存的搜索结果。
  • 范围端点可能没有对应消息；批次可以少于请求数量，删除会让它继续缩小，不同窗口还可能需要重叠一批才能发现边界不一致。消息数也不等于字节数、时延或服务器成本。
  • Daniel Eggert 是这份 IETF 共识文档的编辑。其贡献的价值在于定义一个克制的公共机制，同时把实现、调度与运行结果的责任留给真正执行工作的系统。

假设服务器返回 163886:99703。习惯分页接口的人可能认为，这段范围从第 163886 封邮件连续排到第 99703 封。但 RFC 10022 明确允许这些端点都不存在。中间也可能有大量因删除留下的空洞。范围只需覆盖大约指定数量的现存消息。

这不是协议偷懒，而是它对自身证据边界的诚实表达。

2026 年 7 月发布的 RFC 10022 属于 IETF 标准轨道，题为 IMAP UIDBATCHES Extension，编辑为 Apple Inc. 的 Daniel Eggert。它让客户端先取得若干 UID 范围，再把 FETCH、SEARCH 或 STORE 等操作限制在可管理的消息数量内。UIDONLY 禁止客户端使用消息序号时，这种能力尤其重要。

但“可管理”不是“稳定”。“近似等量”也只指消息个数，不包括执行成本。

范围端点不是成员证明

服务器在 CAPABILITY 中声明 UIDBATCHES。客户端选中邮箱后，给出每批消息数，还可以限定要第几批到第几批。响应按 UID 从高到低排列：第一批靠近最新消息，后续批次逐步向旧消息移动。

RFC 允许服务器为了实现效率选择并不存在的端点。最后一批可以结束于 UID 1，即使最低的实际 UID 是 302。这里的 1 表示“已经覆盖到邮箱底部”，不是伪造一封 UID 1 的邮件。

因此，端点相减不能得出消息数。某个 UID 落在数值区间内，也不能证明那封消息当时存在。真正的成员关系只能来自后续命令的响应。

运营记录应当保留两层。第一层是 UIDBATCHES 返回的工作分区；第二层是具体 FETCH、SEARCH 或 STORE 实际命中、返回或修改的 UID。把二者压成一个“分页对象”，事故后就无法说明空洞来自删除、端点弹性还是后续执行。

这条界限还体现在 SEARCHRES 上。UIDBATCHES 不是 SEARCH，也不是 UID SEARCH；服务器不得把它的结果存入 $。分区不能因为实现方便而冒充保存的结果集。

等量只约束消息个数

客户端每批至少请求 500 封消息。服务器不得返回超过请求数量的消息；通常应尽量精确，并在可能时达到请求量的 90% 以上。若实现可因此显著简化或更高效，或计算期间邮箱发生变化，也可以返回更少。最旧的最后一批通常只是余数。

这些规则没有承诺字节数。500 封纯文本通知与 500 封带大型附件的邮件，对网络和存储造成的工作完全不同。读取信头、下载正文、按未建索引字段搜索、修改标志，也不是同一种负载。

RFC 说 UIDBATCHES 可以减少服务器工作、返回数据和双方内存使用，但这是一种设计收益，不是固定服务等级。批次数量不能直接标成“成本”。

若客户端想把一次同步控制在两秒以内，就必须记录实际消息数、响应字节、服务器执行时间、客户端处理时间、具体命令、错误与重试。只有这些数据才能反向调整批次。用消息数代替时延，是把控制旋钮误当测量仪。

邮箱变化拥有自己的时钟

新邮件取得更高 UID，不会插入已经返回的范围，所以旧范围中的消息数不会增加。但删除会让范围缩小。客户端可以利用 EXPUNGE、VANISHED 与 EXISTS 跟踪这种变化。

重新计算不是免费的刷新。RFC 10022 只在三类情况下认为重发 UIDBATCHES 合适：选中了另一个邮箱；已删除超过半个批次的消息；或新到消息超过半个批次。其他情况下客户端不得重发。服务器也应主动执行限制，避免恶意或错误客户端反复触发昂贵计算。

这要求一份可解释的状态记录：原始批次大小、自上次计算以来的删除与新增计数、阈值越过时刻，以及触发重算的具体原因。若产品只保留“最后刷新时间”，就无法区分合法重算与资源耗尽循环。

邮箱身份比时间更先。UID 必须和选中的邮箱及 UIDVALIDITY 绑定。缓存范围若被带到另一个邮箱，或跨越 UIDVALIDITY 变化，就不是普通的陈旧分页，而是失去身份语境的编号。

重叠窗口是检测工具

面对大邮箱，客户端可能先请求 1:100，再请求 101:200。由于每批数量可以近似，而且两次命令之间邮箱会变化，RFC 建议在窗口边界重复一批，例如 1:100、100:200、200:300。

比较重复批次可以发现潜在不一致，却不会自动修复它。客户端仍要决定：重新请求、扩大重叠、保留警告继续，还是阻止高风险导出。若系统去重时直接丢掉重复批次，它也丢掉了这项检测证据。

这说明批次编号不是持久分页令牌。它表示某一时刻从最高 UID 向下计算的位置。邮箱状态改变后，同一个编号不保证仍指向同一组消息。

带批次范围的请求最多覆盖 100,000 封消息。服务器至少要支持这个规模，但可以用 TOOMANY 拒绝更大的范围；超大邮箱若请求全部范围，也可能被拒绝。服务器声明 MESSAGELIMIT 时，客户端还应让每批不超过单条命令可处理的消息上限。

最小 500 的限制也保护 UIDONLY 的结构目标。若允许极小批次，客户端可能借此重建近似消息序号。UIDBATCHES 提供的是合法的粗粒度工作划分，不是绕开 UIDONLY 的位置侧信道。

空响应不是一个事实

空邮箱会收到不含范围的 UIDBATCHES 响应并正常完成。非空邮箱若请求了不存在的批次，同样会得到空响应。单看响应体，无法区分二者。

命令 tag 把响应连回原请求；批次索引说明问了什么；选中邮箱时的 EXISTS 说明背景。只有三者合并，“空”才有可执行含义。把所有空响应显示成“邮箱为空”，就是在界面层制造事实。

TOOFEW、TOOMANY 和 LIMIT 也不应统一成“稍后重试”。前者指向过小批次，后两者指向规模或频率边界。自动重试若不改变条件，只会扩大原问题。

PARTIAL 与 UIDBATCHES 也不能混为一谈。PARTIAL 提供分页的 SEARCH 和 FETCH；UIDBATCHES 让客户端在选择后续操作之前预先获得范围。实现策略可以复用，语义仍然不同。

Daniel Eggert 的名字只证明有边界的贡献

截至2026年9月1日，IETF Datatracker 的 Daniel Eggert 官方档案列出 RFC 10022 与 RFC 9979。Swift.org 2022 年发布 SwiftNIO IMAP 时，将他介绍为 Apple 负责 iOS 与 macOS Mail 的团队成员，并链接其公开 GitHub 身份。

这些是有日期的职业背景，不是产品部署声明。来源没有证明某个 Apple 产品实现 RFC 10022，也没有证明 Eggert 控制任何服务器行为或拥有 IETF 共识。编辑标准、实现软件和运营服务是三种不同责任。

他的标准贡献恰恰帮助维持这种分工。RFC 10022 规定共同语法、上限和反滥用约束；服务器保留分区算法，客户端保留调度与一致性处置，运营者对用户结果负责。

这符合 Heng Lu 的“最低初始规范”：公共层只规定互操作所需的最小事实，未来决策留在本地。运行代码优先则要求最终回到实际命令与结果，而不是让一段合法范围替已经完成的同步发言。

建立可以穿越变更的批次回执

先记录服务器、账户边界、邮箱、UIDVALIDITY 与能力集。再记录 tag、请求数量、批次索引、响应码和原始范围。关联初始 EXISTS、后续 EXISTS/EXPUNGE/VANISHED、重算阈值与重叠窗口比较。

随后追踪每段范围执行了什么命令、实际命中哪些 UID、多少消息已不存在、传输多少字节、服务器与客户端分别耗时多久、何时重试、最终写入哪个本地检查点。

凭据和邮件正文不应进入公开审计；有限标识、计数、哈希、时间和结果码足以证明决策。这样，范围仍是高效工具，却不会冒充冻结时间的页面。

来源