Summary

  • RFC 3656's RESERVE made a mailbox name unavailable to competing claims, but explicitly did not mean the mailbox was ready for clients.
  • Readiness appeared in the later MAILBOX state, after local creation and ACTIVATE; the server protocol recommended this sequence but relied on cooperating participants rather than enforcing it as a precondition.

First the name, then the mailbox

In a cluster of mail servers, a directory lookup has to answer two different questions. Which server owns the name? And can a client access a mailbox there now? RFC 3656, published as an Experimental protocol in December 2003, made those answers separate records. MUPDATE was designed to give IMAP and POP3 servers a unified mailbox namespace while several machines shared delivery responsibility.

Its typical creation sequence began with RESERVE. The client asked the master to hold a mailbox name at a stated location. After the server returned OK, the client performed the local mailbox-creation work and then sent ACTIVATE with the name, location and ACL. A successful activation made the record active. The location could guide a client to the server storing the mailbox; the ACL described mailbox access rights.

The distinction is visible in the responses. RESERVE means the name is no longer available for another claimant, but the RFC explicitly says it does not mean the mailbox is currently available to clients. MAILBOX is the response for a record ready to be accessed. Treating those messages as synonyms would turn a namespace lock into a false availability signal: the local object might not yet exist, or the creation step might not have completed.

Atomicity was a shared discipline

MUPDATE described a single master holding the authoritative database and slave servers that replicated it. Clients could search through either; changes to the database were directed to the master. The typical create operation therefore crossed two surfaces: a distributed name registry and the local mailbox store. The protocol coordinated them, but did not make them one atomic machine.

That limit is especially clear in the normative language. New mailboxes SHOULD be reserved before they are activated, because the design assumes authenticated participants cooperate to maintain atomic operations. But ACTIVATE does not require a prior reservation. The specification permits that behavior to simplify synchronization with actual mailbox locations. A participant that skips the shared locking convention can therefore help create inconsistent database state. The database cannot infer a local mailbox transaction that was never reported to it.

DEACTIVATE moved an active name back to the reserved state; it was not the same as deleting the name from the namespace. The RFC also warned that known ACL information might be lost during that move. These states matter during a migration or interrupted creation: a name can remain claimed while no active mailbox is advertised, and the location record alone is not proof that a client completed a login or read mail.

A replica's OK had a boundary

After a slave issued UPDATE, the master sent an initial list and then streamed later mailbox changes. The protocol required the master to send an update within 30 seconds of a master-side change. A slave could issue NOOP; after UPDATE, the tagged OK had to wait until all changes pending at the time of that NOOP had been sent. This gave the slave a bounded synchronization point, not a promise that the database stayed globally current after the response.

That is a useful but narrow receipt. It says which pending stream had drained to that replica at a moment. It does not prove that a later master update has arrived, that a local mailbox is healthy, or that an end user has accessed it. RFC 3656 was Experimental; it documents a proposed coordination contract, not evidence of current deployments or measured availability.

Sources