Summary

  • IMAP message sequence numbers describe a message's current position and can shift after an expunge. UIDs persist across sessions, but only within a mailbox and a UIDVALIDITY generation.
  • A changed UIDVALIDITY is an explicit withdrawal of continuity. The client must discard stale cache entries and UID-addressed actions rather than risk fetching, flagging or deleting a different message that inherited the same number.

The dangerous message was the one that still had the right number

Imagine a mail client leaving a train station with an offline copy of an inbox. In its cache, UID 4821 is an invoice. The user marks that message for deletion while disconnected. Before the client returns, the server restores the mailbox from an older storage system that could not preserve its original UID assignments. The rebuilt inbox contains another message numbered 4821.

If the server pretends that nothing changed, the client's perfectly formed command can delete the wrong mail. Authentication does not help: the user is authorized, the connection is protected, and both sides are following the syntax. The error lies in identity. A valid number from an obsolete generation has been allowed to act as a valid reference in a new one.

IMAP's answer is severe and economical. The server changes UIDVALIDITY. The client sees the mismatch, empties that mailbox's cached UID state and abandons pending actions aimed at the old UIDs. Bandwidth and time are lost. The invoice and the new message are not confused.

The mechanism is a small constitutional clause for stored state: continuity may be useful, but it cannot be presumed after the system that supplied it has changed.

A place in a list was never an identity

IMAP has always had two useful ways to number messages. A message sequence number is its relative position in the currently selected mailbox. In a mailbox containing twenty messages, the values run from 1 to 20. That makes ranges and arithmetic convenient. If the server announces that the count rose from 17 to 20, a client knows that three positions appeared at the end.

The convenience has a trap. Permanently remove message 6 and the old message 7 becomes message 6; every later position moves down by one. A number once held by one message may later belong to another. RFC 2060, the 1996 IMAP4rev1 specification, describes this reassignment directly. The current RFC 9051 retains the same distinction.

For an interactive session, relative position is workable because the server reports changes and the client can update its map. For disconnected use, it is a bad memory key. A laptop or phone may be absent while other clients add mail, change flags and expunge messages. When it returns, “message 6” is a coordinate in today's list, not proof of yesterday's object.

IMAP4 gave messages a longer memory

RFC 1730, published in December 1994, defined IMAP4 around remote mailboxes and offline resynchronization. Its UID was a 32-bit message identifier assigned in strictly ascending order within a mailbox. UIDs need not be contiguous, and—unlike sequence numbers—they persist across sessions.

That design let a client keep local state without downloading and comparing every message body after each reconnect. It could remember that UID 4821 had already been seen, associate a draft action with UID 4821, and ask the server what changed since the last visit.

But the word “unique” invited more confidence than the storage layer could always support. Existing mail stores had not necessarily been built to retain a permanent IMAP number beside every message. A non-IMAP program could reorder a store. A mailbox could be deleted, then another mailbox could be created later under the same name. A restoration or migration could keep the mail while losing the old UID metadata.

The protocol could demand perfect persistence and thereby exclude such systems. Or it could let them recycle numbers silently and make offline actions dangerous. It chose a third option: persistence with an observable failure boundary.

UIDVALIDITY named the generation, not the mailbox

Every mailbox carries a 32-bit UIDVALIDITY value. When UIDs from an earlier session no longer persist, the new value must be greater than the old one. RFC 1730 already proposed a mailbox creation time as one sensible source. RFC 9051 also mentions an incrementing counter. Neither algorithm is the point. The point is that the server must distinguish the new UID generation from the one a client cached.

UIDVALIDITY is often misread as a globally unique mailbox identifier. RFC 2683, the IETF's 1999 implementation recommendations, explicitly rejects that interpretation. Two mailboxes may have the same UIDVALIDITY. UIDs are unique only within a mailbox. The durable reference is mailbox name, UIDVALIDITY and UID together.

This scope is not bureaucratic decoration. If Archive and Inbox both have UIDVALIDITY 77 and both contain UID 4821, the values do not identify one server-wide message. Likewise, a UID does not become globally meaningful because it has 32 bits, nor does concatenating two 32-bit fields create universal identity.

RFC 3501 and the current base specification impose a stronger invariant inside the proper scope. The tuple must continue to refer to one immutable message on that server. The message body, envelope, internal date, size and structure cannot quietly become different content under the same tuple. Mutable flags are excluded because changing them is part of normal IMAP operation. An expunged UID cannot be reassigned under the same UIDVALIDITY generation.

Honesty cost more than pretending

Servers were strongly encouraged to preserve UIDs, because a UIDVALIDITY change is disruptive. Yet the standards did not hide the hard cases. If a backend has no persistent UID store, it may have to generate new UIDs for every session and a new UIDVALIDITY each time. The UIDPLUS extension in RFC 4315 even defines UIDNOTSTICKY for legacy stores that cannot promise persistence, while saying new stores should avoid that condition.

This is the same trade-off seen in many Internet protocols: make the normal case efficient, but keep a truthful escape route for the case in which the invariant breaks. The escape route must be visible. A server that lost UID continuity but preserved the old UIDVALIDITY would save a synchronization cycle by lying about the state it could no longer guarantee.

RFC 2683 describes the worst consequence plainly: a client using a stale UID can delete the wrong mail. The risk is not confined to deletion. A stale action could flag, copy, move or fetch a different message. The more faithfully a client replays its offline intent, the more damaging false continuity becomes.

Invalidation revoked local authority

RFC 4549, published in 2006 to guide disconnected IMAP clients, turns UIDVALIDITY into an operational decision. Before replaying actions against a mailbox, the client checks the current value. If it differs from the cached value, the client must empty the local cache for that mailbox, remove pending actions referring to its old UIDs and treat them as failed.

That response can feel wasteful. The client may still possess correct message bodies. Most UIDs may even happen to map to the same mail after a migration. The protocol refuses to infer identity from resemblance. Once the server says the generation changed, the client no longer has evidence that its saved number names the same object.

The invalidation is deliberately local. A UID problem in one mailbox need not erase every mailbox. RFC 2683 warns against allocating UIDs from one global server-wide pool partly for this reason: it consumes the 32-bit space faster and can turn one exhaustion event into a system-wide UIDVALIDITY reset. Mailbox scope confines both the namespace and the blast radius.

A URL could carry its own staleness test

The same principle escaped the synchronization engine. RFC 2192, published in 1997, defined an IMAP URL that could include a mailbox, UIDVALIDITY and UID. A program opening the URL should compare the saved validity value with the server's current value to decide whether the reference has gone stale.

That detail exposes the deeper function of UIDVALIDITY. It is not a timer that tells a message when to expire. It is not proof that the server is honest. It is evidence about whether a previously issued identifier remains inside the generation in which it was meaningful.

A bare number travels easily. A safe reference carries enough context to know when it must stop travelling.

Faster synchronization still began with identity

As mailboxes grew and mobile connections became intermittent, full comparison became expensive. RFC 7162 combined CONDSTORE and QRESYNC so clients could learn changed flags and expunged UIDs efficiently. QRESYNC's VANISHED response compactly reports messages that disappeared, and a reconnecting client can often synchronize in one round trip.

The first state value a client supplies to QRESYNC is its last-known UIDVALIDITY. Only if that matches does the rest of the delta state—modification sequence and known UIDs—belong to the mailbox generation now open. On mismatch, the server ignores those later parameters. An exquisitely precise list of changes is useless if it describes the wrong identity space.

Efficiency therefore sits below validity. Modification sequences answer “what changed?” UIDVALIDITY first answers “are these still the same things?”

Thirty years later, relative numbers could be switched off

In May 2024, RFC 9586 defined the Experimental UIDONLY extension. After a client enables it, the session no longer accepts message sequence numbers in commands or returns them in responses. UID-based forms take over, and expunges appear through VANISHED. Both client and server can avoid maintaining part of the map between shifting positions and stable UIDs.

UIDONLY is not mandatory, and the RFC makes no claim that every service deploys it. Its direction is nevertheless revealing. Three decades after IMAP4 introduced UIDs, protocol work was still reducing dependence on relative positions. Yet UIDONLY does not make a UID eternal, server-wide or portable between mailboxes. The generation boundary remains.

The progress is not from small numbers to bigger numbers. It is from ambiguous coordinates to explicitly scoped evidence.

The identifier survived because the protocol allowed it to fail

IMAP's lasting achievement was not a magic number that never changed. It was a division of responsibility. The server, which controls the message store, must say whether UID continuity survived. The client, which controls its cache and queued intent, must withdraw trust when the generation changes. Neither side is permitted to manufacture continuity from convenience.

That is thin coordination in its most useful form. The shared protocol does not prescribe a single storage engine, migration method or client database. It defines the invariant, the failure signal and the safe response. Running systems remain free to differ, but they cannot use that freedom to make an old identifier silently command a new object.

The UID can survive a session because UIDVALIDITY can announce the moment it did not survive a rebirth.

Sources and limits

The 1994 origin of persistent IMAP UIDs and UIDVALIDITY comes from RFC 1730; the sequence-number distinction and identity invariant from RFC 2060, RFC 3501 and RFC 9051. RFC 2683 supplies implementation lessons, RFC 2192 the stale-URL test, RFC 4315 the legacy UIDNOTSTICKY signal, RFC 4549 the disconnected-client response, RFC 7162 the QRESYNC dependency and RFC 9586 the Experimental UIDONLY direction. These documents do not establish present deployment share, product behavior, message authenticity, cryptographic integrity or one universal method of constructing UIDVALIDITY.