Summary

  • UIDPLUS attached destination UIDVALIDITY and newly assigned UIDs to successful APPEND and COPY results, turning a completed mutation into a mapping a disconnected client could use immediately.
  • Its receipts remained deliberately local: permissions or nonpersistent stores could suppress them, COPYUID did not establish global message identity, and UID EXPUNGE removed only the intersection of an explicit UID set and messages already marked \Deleted.

Success without a reference

IMAP separated two numbering systems. Sequence numbers described the current view of a selected mailbox and could change when another message was expunged. UIDs were designed to remain stable within a mailbox generation. That distinction let a disconnected client cache state and return later without treating the third visible message as the same thing merely because it was still third.

But a state-changing command exposed a gap. APPEND asked the server to create a new message in a destination mailbox. COPY asked it to create destination instances of existing messages. Base IMAP could confirm success, but the client still had to discover which destination UIDs the server had allocated. It might select the mailbox, search for a marker it had inserted, fetch candidates and compare them. The extra work was not proof that the mutation had failed. It was the cost of a success result that did not name its product.

RFC 2359 introduced UIDPLUS in 1998 for precisely this class of disconnected operation. RFC 4315 replaced that document in 2005, tightening the rules and describing when a server could legitimately omit the result. The extension did not invent a second transaction system. It put more evidence into the existing tagged success boundary.

APPENDUID closed one open loop

When APPEND succeeded, APPENDUID could appear inside the tagged OK. It carried two parts: the UIDVALIDITY of the destination mailbox and the UID assigned to the new message. A client could therefore record not merely that its upload was accepted, but the mailbox generation and local identifier under which it could later address the result.

The generation mattered as much as the number. UID 3955 is not an identity by itself. It is meaningful only within the relevant server, mailbox name and UIDVALIDITY. If that validity changes, the old pairing cannot be carried forward as if nothing happened. UIDPLUS returned a usable reference because it returned the boundary that made the reference valid.

Multiappend widened the response from one UID to an ordered set. The order of returned UIDs follows the order of messages supplied to APPEND. The set cannot smuggle in unrelated identifiers or use * as an indefinite endpoint. Those constraints make the response checkable: the client knows how many messages it sent and which result position belongs to each one.

COPYUID preserved correspondence through renaming

COPY posed a harder problem because the same content crossed a mailbox boundary and received new names. COPYUID returned the destination UIDVALIDITY, a source UID set and a destination UID set. The two sets have equal cardinality, and their positions define the mapping: first source to first destination, second to second, and so forth.

This was not a promise that UIDs travel with messages. It was evidence that a particular command caused these destination allocations. A client could update its local model without guessing from message order or content similarity.

Message sequence numbers could not safely do the same job. Other clients might expunge messages while COPY was being processed, shifting visible positions. RFC 4315 therefore grounds the mapping in UIDs and constrains the returned sets to the messages involved. The receipt survives renumbering because it does not depend on the display order that renumbering changes.

The scope still stopped at the client that received the reply. RFC 8474 later observed that another client could not look at the destination mailbox and infer the same cross-mailbox mapping from COPYUID. Object identifiers addressed a broader identity problem. UIDPLUS had solved a command-result problem, not universal sameness.

UID EXPUNGE narrowed the destructive set

The extension's command applied the same precision to deletion. Ordinary EXPUNGE permanently removed every message in the selected mailbox carrying the \Deleted flag. In a shared mailbox, another client might have set that flag on messages the reconnecting client had never intended to remove.

UID EXPUNGE accepts a UID set and removes only messages that satisfy both conditions: their UIDs are in that set, and they are already marked \Deleted. A listed UID without the flag survives. A flagged message outside the set also survives. The command is an intersection, not a broad purge and not a replacement for the flagging step.

Without UIDPLUS, the documented fallback was awkward: temporarily clear \Deleted from messages that must survive, issue EXPUNGE, then restore the flags. The fallback could reproduce the desired outcome under suitable conditions, but it enlarged the window of shared-state manipulation. UID EXPUNGE made the intended irreversible scope explicit in one command.

A receipt could disclose too much

More evidence was not always safer. A user might be allowed to drop a message into a mailbox without being allowed to select or examine that mailbox. Returning its UIDVALIDITY and a newly allocated UID would reveal information about a store the permission model otherwise kept opaque. RFC 4315 therefore says the server should not send APPENDUID or COPYUID in that case.

The response could also be omitted for a UIDNOTSTICKY destination. Such a store does not promise that UIDs persist between sessions. Returning a durable-looking reference from a nonpersistent namespace would invite a false inference, so the protocol marks the store and permits silence. The specification discourages new stores with that property, but it does not pretend legacy constraints do not exist.

Absence of the receipt is not a negative command result. The client can fall back to selecting and searching the destination if it has the necessary access, often using a unique marker placed in the message. The distinction is essential: mutation success, permission to inspect and identifier persistence are three separate facts.

MOVE made response order visible

The later MOVE extension combined destination creation with source removal. A UIDPLUS server could report COPYUID for UID MOVE, but timing now mattered. If the server first emitted EXPUNGE responses, source-side sequence numbers shifted before the client learned the destination mapping. RFC 6851 advised sending COPYUID in an untagged OK before those removals; IMAP4rev2 made that ordering part of its integrated behavior.

The lesson was not that a response becomes truer by arriving early. It becomes usable while the state needed to interpret it is still coherent. A mapping, a deletion notice and a final success can all be correct individually and still impose needless ambiguity if the protocol orders them badly.

The receipt had a jurisdiction

UIDPLUS is a history of bounded evidence. APPENDUID answered which new local reference followed one append. COPYUID answered how one source set corresponded to one destination set. UID EXPUNGE answered which already-marked messages one client intended to remove. Permission, mailbox generation and response order defined where each answer remained valid.

That restraint is why the extension endured. It did not promote a local number into a universal identity or a successful response into a transaction proof. It made a smaller claim exactly enough: the server had performed this mutation, and here are the destination references produced within this mailbox generation.

Sources and limits

The original extension is RFC 2359, replaced by RFC 4315. The base protocol context is RFC 3501; MOVE interaction is in RFC 6851; the limit that motivated cross-client object identifiers is explained by RFC 8474; and the integrated IMAP4rev2 behavior is in RFC 9051. IANA's IMAP capabilities registry records UIDPLUS. These sources do not measure deployment share and do not turn a UID mapping into delivery, authentication or global identity evidence.