Summary

  • RFC 2342's NAMESPACE response disclosed how a server wanted a client to interpret personal, other-users and shared mailbox names.
  • That map was deliberately incomplete and permission-sensitive; mailbox discovery, existence, selectability, readable state, display and human attention required separate evidence.

Three maps arrived before any door opened

Imagine an IMAP client receiving a flawless response: one personal namespace with an empty prefix and slash delimiter, one other-users namespace beginning with a tilde, and no shared namespace. The syntax is complete. The three positions are in the right order. The client can now build names such as ~mark/INBOX without guessing the server's local convention.

Nothing in that response says that Mark exists. Nothing says his INBOX is visible to this authenticated user, that the server will list it, that SELECT will succeed, that a message is present or that a person has read one.

That is the narrow achievement of RFC 2342. Before NAMESPACE, clients often asked users to type the prefix for personal or shared mailboxes. The extension made those naming conventions discoverable. It standardized a map legend, not the buildings drawn on the map.

The distinction matters because a clean control-plane declaration is easy to promote into a stronger claim. A client sees a shared prefix and renders a “Shared” section. An operator sees a successful NAMESPACE exchange and marks mailbox discovery healthy. A support system treats an advertised other-users branch as proof that delegated access is working. Each conclusion crosses a boundary the response never claimed to cross.

The response described grammar, not inventory

The untagged response contains three ordered namespace fields: Personal, Other Users', and Shared. Each field can be NIL or a list of one or more namespace descriptions. A description provides a prefix and either a hierarchy delimiter or NIL; extensions may follow.

Servers can expose multiple namespaces in any class. Delimiters may differ between them. A prefix may contain no delimiter at all. RFC 2342 even allows a server to expose only a subset of the namespaces it supports, leaving clients to accept manually entered prefixes for the rest.

Those design choices make the scope explicit. NAMESPACE tells the client how names are partitioned and joined. It does not enumerate the full set of namespace classes, much less the mailboxes inside them.

NIL is bounded evidence too. It says that a class is not available in this response for this connection. It does not prove that the server has never implemented such a namespace, that another user sees the same response, or that a manually supplied prefix could not reach a hidden branch. RFC 2342 says namespace exposure may vary per user.

Lu Heng's distinction between a coordination artifact and running reality is useful here. A prefix is executable only as an input to a later command. It gains operational meaning when a client uses it and the server evaluates that request in the current account, permission and mailbox state. Publication of the convention does not pre-authorize the result.

LIST was a separate, lossy observation

RFC 2342 showed how a client might append % to an Other Users' prefix and issue LIST. It also warned servers not to reveal users who had not granted list access. A server could return only authorized names. It could reject the broad pattern with NO and require a concrete username. Its own example first fails to list #Users/%, then succeeds for #Users/Mike/% when the user supplies Mike's name.

This is not an inconsistency. It is the security design. The existence of a naming domain does not entitle a client to enumerate its occupants. A namespace can be advertised while its contents remain filtered, partially visible or undiscoverable through a wildcard.

Modern IMAP makes the separation sharper. RFC 9051 says LIST returns a subset of mailbox names from the complete set available to the client and may return zero or more responses. A name can carry \Noselect or \NonExistent. A subscription listing can include a subscribed name for a mailbox that no longer exists.

Therefore “NAMESPACE succeeded,” “LIST returned a name,” “the name is subscribed” and “the mailbox exists and is selectable now” are four different propositions. Treating them as one state creates false certainty precisely where permissions, lifecycle changes and races are most active.

Visibility and reading were different rights

RFC 4314 divides mailbox authority into specific rights. The l right makes a mailbox visible to LIST or LSUB. The r right permits SELECT and STATUS. The s right governs persistent Seen/Unseen information. Other rights separately control flags, insertion, creation, deletion, expunge and ACL administration.

That split defeats a common shortcut. A mailbox can be listable without being readable. RFC 9051 gives the concrete case: LIST-STATUS can encounter a mailbox for which the user has l but not r, and the response must reflect that it cannot be selected. The naming plane, visibility plane and read plane are not synonyms.

Even s is not a human-reading oracle. A Seen flag can be changed by protocol operations. A client may fetch content in a way that sets it, preserve it across sessions or manipulate it under rights rules. The flag records server-side message state. It does not observe eyes, comprehension or attention.

RFC 8440 later let extended LIST return MYRIGHTS information. That can reduce round trips and place stronger evidence beside a listed mailbox. It still does not merge the states. Rights describe permitted operations; they do not prove an operation occurred, succeeded, rendered content or reached a person.

SELECT opened a mailbox, not a reader

SELECT is the state transition NAMESPACE is often mistaken for. On success it moves the connection into selected state and returns mailbox data such as FLAGS, EXISTS, UIDNEXT and UIDVALIDITY. On failure, NO can mean no such mailbox or that the mailbox cannot be accessed.

That exchange proves considerably more than a prefix. It proves that this connection selected this mailbox at this time under the server's current state. It still leaves later receipts outstanding: did FETCH return the requested body, did the client decode it, did rendering succeed, was the window visible, and did a person read it?

None of these later events can be inferred from the naming convention. Nor can they be inferred safely from one another. A successful FETCH can feed a background indexer. A rendered message can sit behind another window. A Seen flag can be set without comprehension. Human reading belongs outside the IMAP protocol state machine.

The durable lesson was evidentiary modesty

RFC 2342 solved a real interoperability problem. It let clients stop hard-coding server-specific mailbox roots. It also preserved local variation: multiple roots, per-user exposure, distinct delimiters, NIL classes, extensions and permission-aware discovery.

Its restraint is the historical lesson. The specification did not turn a directory of name forms into an inventory oracle. It gave clients a deterministic way to construct better questions while leaving the answers with later commands and current authorization.

That is a strong pattern for infrastructure systems. A schema can say how to identify something without proving the thing exists. A capability can say a command is understood without proving a requested action will succeed. A successful control response can move an investigation forward without closing it.

The server drew three mail maps. The disciplined client still had to knock on each door.