Summary

  • RFC 10022 lets an IMAP client request descending UID ranges near a chosen number of messages, including in UIDONLY mode. The ranges are inputs to later operations, not stored search results or stable mailbox pages.
  • Range endpoints need not identify existing messages. Batches may be smaller than requested, expunges can shrink them, separate range requests can disagree, and the requested count says nothing about bytes, latency or server cost.
  • Daniel Eggert edited the IETF consensus document. His contribution is best understood as a narrow coordination mechanism whose limits keep implementation, scheduling and operational proof with the systems that perform the work.

The first request returned batches 1 through 100. The second asked for 101 through 200. Both completed successfully. Between them, messages were expunged, the practical boundaries moved and the client discovered too late that treating the two responses as consecutive pages had left its audit trail unable to explain a gap.

RFC 10022 anticipates a version of this problem. It suggests that a client requesting consecutive batch ranges may overlap the boundary: 1:100, then 100:200, then 200:300. Comparing the repeated batch can expose a possible inconsistency. The overlap is not wasted pagination. It is evidence that the results came from a mailbox that could change between commands.

Published in July 2026 on the IETF Standards Track, IMAP UIDBATCHES Extension was edited by Daniel Eggert of Apple Inc. The extension allows a client to predetermine UID ranges containing approximately a desired number of messages. That is valuable for breaking later FETCH, SEARCH or STORE work into manageable units, particularly when UIDONLY removes access to message sequence numbers.

The standard is careful about the noun. It returns batches. It does not promise snapshots, pages, equal byte loads or equal completion times.

A UID range is an interval, not an inventory

An IMAP server advertises UIDBATCHES as a capability. After selecting a mailbox, a client supplies a desired message count and may add a range of batch indices. The server responds with UID ranges in descending order: batch 1 covers the highest UIDs, batch 2 the next group and so on.

The endpoints can be deceptive if read as an item list. RFC 10022 explicitly permits a server to return range boundaries that do not correspond to messages that exist. A range such as 163886:99703 may span roughly the requested number of existing messages while neither endpoint names one. The last range may end at UID 1 even when the lowest existing message has UID 302. Ending at 1 says “this reaches the bottom”; it does not invent message 1.

This flexibility lets a server choose efficient boundaries. It also means a client cannot calculate the number of messages by subtracting one endpoint from the other. Deleted UIDs create holes. Nor can an auditor prove that a particular message was present merely because its number falls inside a returned interval. Presence belongs to the later operation and its response.

The evidence chain therefore needs both layers. Preserve the exact UIDBATCHES response as a partitioning instruction. Then preserve which UIDs a subsequent FETCH, SEARCH or STORE actually matched, processed or rejected. Turning the first into the second loses precisely the uncertainty the protocol retained.

Equal-sized describes a count target, not equal work

The client requests messages per batch. It must request at least 500. A server must never return a range containing more messages than requested, should normally return the requested number and should aim for at least 90 percent when possible. It may return fewer when that substantially simplifies or improves the implementation, or when mailbox state changes during calculation. The oldest final batch normally contains the remainder.

Those rules constrain message count. They say nothing about message size. Five hundred short notices and five hundred mailboxes full of attachments create radically different network, storage, parsing and indexing work. A FETCH that retrieves headers differs from one that retrieves bodies. A SEARCH can be cheap under one index and costly under another criterion. STORE changes state and may trigger still more work.

Even response size is not guaranteed by the batch count. RFC 10022 says the mechanism may limit response size and can reduce work and memory compared with alternatives. “May” is the honest word. The range is a scheduling aid, not a service-level promise.

An operations dashboard should therefore never label the requested count “batch cost.” Record messages actually operated on, response octets, server execution time, client processing time, retry count and the command applied to the range. If the objective is to keep a user-visible sync under two seconds, the control loop needs observed duration and bytes, not a belief that every 2,000-message interval is equivalent.

The mailbox keeps moving after the ranges arrive

New messages receive higher UIDs, so they cannot appear inside a range that has already been returned. A range's population will not grow. It can shrink as messages are deleted. RFC 10022 lets the client track EXPUNGE or VANISHED responses and add newly arrived messages to a new top batch.

Recalculation is deliberately restricted because computing batches can be expensive. It is appropriate after selecting a different mailbox, after more than half the requested batch size has been expunged, or after more than half a batch of new messages has arrived. Otherwise the client must not resend UIDBATCHES. Servers are strongly advised to enforce the restriction rather than trust every client.

This creates a state machine, not a refresh button. The client needs the selected mailbox, UIDVALIDITY, the original EXISTS count, the batch size, later EXISTS/EXPUNGE/VANISHED events and the threshold crossing that authorized a new command. Without that record, repeated requests look like harmless polling even when they are a resource-exhaustion risk.

UIDVALIDITY deserves special attention. UIDs are meaningful within a mailbox under its validity value. A cached interval carried into the wrong selected mailbox, or across a changed UIDVALIDITY, is not merely stale pagination. It has lost its identity boundary. The range receipt must bind the server, account boundary, selected mailbox and UIDVALIDITY before it binds any endpoints.

Empty success has more than one cause

A valid UIDBATCHES command against an empty mailbox returns an untagged response with no ranges and then an OK completion. The same empty response is required when the mailbox contains messages but the client asks for batch indices that do not exist.

The response body alone cannot distinguish those cases. The command tag associates it with the request. The optional batch range says what was asked. The selected mailbox's EXISTS state supplies the surrounding fact. An interface that shortens both outcomes to “0 batches” discards the reason that determines the next action.

Errors also carry bounded meanings. A request below the server's supported minimum can receive TOOFEW. A range spanning more than 100,000 messages can receive TOOMANY; when all ranges are requested from a very large mailbox, a server may also decline because it cannot return them all. If MESSAGELIMIT is advertised, the client should keep its requested batch no larger than the announced per-command message limit.

These are not generic failures. TOOFEW protects against tiny batches that could reconstruct sequence-number-like position under UIDONLY. TOOMANY and LIMIT protect finite server work. Keeping the exact response code and capability set turns a retry from guesswork into a policy decision.

UIDBATCHES is not a disguised search page

UIDONLY prohibits clients from using message sequence numbers. UIDBATCHES gives them an efficient way to determine UID ranges without defeating that design. The minimum batch size also prevents a client from asking for tiny partitions simply to recover fine-grained positional information.

The PARTIAL extension solves a different problem through paged SEARCH and FETCH. UIDBATCHES lets a client predetermine ranges before deciding which later operation to run. A client may share some implementation strategy across servers that support UIDBATCHES, PARTIAL or a sequence-number-based fallback, but the results retain different semantics.

RFC 10022 makes one boundary explicit: UIDBATCHES is neither SEARCH nor UID SEARCH. A server supporting SEARCHRES must not store its result in the $ variable. That prevents a convenient implementation shortcut from changing a partition into a saved result set.

The same discipline should appear in product language. “Prepared 40 work ranges” is accurate. “Loaded 40 pages” implies stable membership and order that the command never promised. “Synced 80,000 messages” can only be reported after the later operations and their outcomes are counted.

Daniel Eggert's record supplies context, not operating authority

The official IETF Datatracker profile for Daniel Eggert listed RFC 10022 and RFC 9979 at the 1 September 2026 capture. Swift.org's 2022 SwiftNIO IMAP announcement identifies him as a member of Apple's team working on Mail for iOS and macOS and links his public GitHub identity. That linked profile identifies Daniel Eggert at Apple, Inc.

This dated context explains why a client-server implementation boundary is relevant to his standards work. It does not prove that a specific Apple product implements RFC 10022, that Eggert chose the behaviour of any deployed server, or that he owns the IETF's decision. The RFC is a consensus document; implementations and service results have their own owners.

The contribution is narrower and more useful. RFC 10022 defines a portable way to ask for manageable partitions while preserving server implementation choice, UIDONLY's architectural constraint and explicit anti-abuse limits. It avoids pretending that the shared mechanism can know every client's cost function or every mailbox's future state.

That restraint follows Heng Lu's Minimum Initial Specification. Standardize the smallest fact participants need to coordinate, then leave future choices local. Running-Code Primacy supplies the final test: a valid response is evidence that the server produced ranges; only the commands executed against those ranges and their observed results show whether synchronization worked.

Build a batch receipt that survives mailbox change

Start with identity: server, account boundary, selected mailbox and UIDVALIDITY. Record the capability set, including UIDBATCHES, UIDONLY, PARTIAL and MESSAGELIMIT where present. For each command, preserve its tag, requested count, optional batch indices, response code and exact returned ranges.

Join that record to mailbox change. Store EXISTS at selection and later EXISTS, EXPUNGE or VANISHED events. When recalculation occurs, record the qualifying event, accumulated count and threshold. For separately requested range windows, retain the overlapping batch and compare it rather than silently deduplicating it away.

Then follow each range into work. Record the later command, actual UIDs matched, missing or expunged messages, bytes returned or changed, server and client time, errors, retry, checkpoint and user-visible outcome. Credentials and message content do not belong in a public audit, but hashes, counts, bounded identifiers and timing can make the chain reviewable.

The result is not heavier than the ambiguity it replaces. It lets a range remain what RFC 10022 designed it to be: an efficient partition of work against a mailbox whose state still belongs to time.

Sources