Summary

  • RFC 9586 lets a client enable an IMAP mode that prohibits message sequence numbers and returns UIDFETCH and VANISHED responses keyed by UIDs. It removes a volatile translation table; it does not establish a complete mailbox snapshot.
  • A useful UID is still scoped by mailbox name and UIDVALIDITY. Capability advertisement, enablement, command completion, cache application and downstream synchronization remain different receipts.

An email client has 80,000 messages open. One message disappears near the beginning of the mailbox, so every later message sequence number shifts. The client has to keep translating a moving ordinal into a more durable UID while unsolicited changes arrive. RFC 9586 attacks that specific burden: stop using the ordinals.

The intervention is narrower than the name “UIDONLY” may suggest. A server first advertises the capability. A client must then issue ENABLE UIDONLY; only after enablement do message-number commands become invalid. Plain FETCH, STORE, SEARCH, COPY and MOVE are rejected in favour of UID-prefixed forms. Responses use UIDFETCH; removals use VANISHED. The server returns UIDREQUIRED when the client crosses the boundary with a forbidden identifier.

This is a genuine simplification. Message sequence numbers are relative positions. Expunging one message immediately renumbers later positions, which is why a client otherwise maintains a live map between two namespaces. UIDONLY removes that map from the protocol path and lowers the chance that a delayed response is attached to the wrong ordinal.

But the remaining identifier is not absolute. IMAP defines a UID inside a mailbox generation. The durable reference is the combination of mailbox name, UIDVALIDITY and UID. If the server cannot preserve the old namespace, UIDVALIDITY changes and the client must stop treating its old UIDs as current identities. A bare UID copied into an audit log is therefore incomplete evidence.

Nor is UIDNEXT a promised next object. It marks a lower boundary for later arrivals, not a guarantee that a message with that exact number will exist. UIDs may contain gaps; messages may be expunged; the same message's mutable flags may change while its identity remains. Stable identity and settled state are separate properties.

RFC 9586 keeps that separation visible. It does not affect EXISTS or RECENT. It can coexist with CONDSTORE and QRESYNC, with modification sequences carried in UIDFETCH, but it does not require those synchronization mechanisms. QRESYNC's optional message-sequence match data is prohibited in UIDONLY mode because it would reintroduce the discarded namespace. The result is cleaner addressing, not automatic historical completeness.

Copy and move operations reveal the same boundary. COPYUID can connect a source UID to a destination UID and destination UIDVALIDITY. The tagged result can show that the IMAP command completed. Neither receipt proves that a later indexer, archive, search view or mobile cache committed the destination object. Those are downstream claims.

The rejected design alternative is instructive. An earlier draft considered retaining ordinary FETCH shapes with a zero in the message-number slot. The specification rejected that approach because clients that believed the placeholder could corrupt their caches. Syntactic compatibility would have hidden a semantic break. A loud new response form is safer because it makes the authority change observable.

For operators, the correct evidence chain is explicit: the server advertised UIDONLY; this connection enabled it; the mailbox was selected with this UIDVALIDITY; these UIDs and modification states were observed; these changes vanished or arrived; this tagged command completed; the client durably applied the delta; and the consuming application reconciled its own result. No single green indicator should impersonate the whole chain.

Sources