Summary

  • RFC 2180 allowed several compliant responses when one IMAP session changed a mailbox while another was using it; a successful command did not prove that every session immediately saw the same namespace or data.
  • The practical bargain was client tolerance: software had to reconcile delayed EXPUNGE information, partial results, ghosted content and changing sequence numbers rather than encode one server's preferred behavior as the protocol.

A successful deletion could leave a readable mailbox

Suppose two clients have selected mailbox FOO. Client one sends DELETE FOO and receives tagged OK. A third client then asks for FOO and is told that it does not exist. Yet client two, which selected the mailbox before deletion, may still issue STORE or FETCH against its contents.

That is not a contradiction accidentally tolerated by RFC 2180. It is one of the documented strategies. A server may remove the name from the visible namespace while retaining the mailbox for sessions that already hold it, finally destroying the data when the last reference closes. It may instead reject deletion while the mailbox is in use, or complete the deletion and disconnect the other sessions with BYE.

Each choice preserves a different operational property. Refusal protects active sessions but can make a popular mailbox practically undeletable. Ghosting preserves continuity for those sessions but delays erasure and prevents immediate reuse of the name. Disconnection makes removal decisive but sacrifices session continuity. The memo did not pretend architecture could avoid that trade-off.

The same split appears on rename. A server may change only the mailbox's name attribute. A client that already selected it can continue issuing commands such as FETCH, because those commands refer to the selected state rather than the old name. An APPEND FOO, however, may fail and optionally return a NEWNAME hint. The content surface and the namespace surface have diverged.

Sequence numbers could be stale before the client was allowed to learn why

Concurrent expunge creates a sharper problem. IMAP message sequence numbers describe positions in the currently selected mailbox. When a message is expunged, later positions shift. But RFC 2060 prevents an EXPUNGE response from interrupting certain commands, including FETCH, STORE and SEARCH. A second client can therefore act while its sequence map is waiting for an update.

RFC 2180 records several permitted server strategies. A server may retain ghost copies long enough to answer the outstanding FETCH. It may return data only for messages that still exist and finish with tagged NO. It may return ordinary data for surviving messages, NIL-shaped data for expunged ones and finish with tagged OK. Or it may avoid the situation by refusing to expunge while multiple clients hold the mailbox.

NIL is particularly revealing. An empty flags list or an empty body can mean that the requested data is genuinely empty. In the documented practice, the same shape can stand in for a message that vanished before the client learned of the expunge. The client cannot convert one syntactically valid response into more certainty than it carries. When ambiguity matters, it should issue NOOP, receive pending EXPUNGE responses, update its sequence map and decide whether to retry.

STORE exposes another limit on the meaning of success. With .SILENT, a server may update every still-existing message in the requested set and return OK, even though some sequence numbers named messages already expunged elsewhere. The receipt says the allowed work on extant messages completed. It does not say the original set remained intact.

COPY froze meaning for one command, not for the mailbox

COPY received a narrower rule. Pending expunge notices can accompany it because clients must wait for the result before cascading another copy. The server identifies the requested messages using sequence numbers as they stood at the start of the command. Those positions may be different by the end, but if the command succeeds, the messages identified at the beginning must appear in the destination. If the copy fails, the destination must be restored to its earlier state.

This is a bounded snapshot of meaning, not a frozen mailbox. It protects one command from a moving index. It does not prove that the source stopped changing, that every client shared the same sequence map, or that the copied messages were still available to a later command.

An interoperability note, not a universal implementation claim

The RFC Editor information record classifies RFC 2180 as Informational. Its own introduction says that it neither defines IMAP4 compliance nor exhausts valid behavior; RFC 2060 remained the compliance reference. The document records practices of some servers and behaviors judged reasonable by the IMAP mailing list.

That scope matters. The memo does not establish what any current service does. It does not measure adoption, prove a deployment, or certify a product. Its historical contribution is more precise: it made protocol freedom visible and assigned the resulting burden. A robust client could not be written against the habits of one familiar server. It had to be written against the full space the protocol allowed.

Later work narrowed particular costs without erasing the distinction. RFC 2177 let an idling client receive unsolicited mailbox updates more promptly, but it still respected ambiguity limits. RFC 7162 added modification sequences, VANISHED and QRESYNC machinery to make resynchronization more efficient. Neither turns a tagged OK into proof of instant global convergence.

The durable lesson is that a command receipt, a namespace view, a selected-session view and retained bytes belong to different reality layers. Confusing them makes software brittle and deletion promises misleading. RFC 2180 did not eliminate divergent reality. It specified how clients could continue when reality briefly diverged.