Summary

  • RFC 5258 separates the criteria that select mailbox names from the options that add information to already selected names; preserving only the returned tree loses the request that gave each node meaning.
  • With RECURSIVEMATCH, a parent can be returned because a descendant meets the subscription criteria, even when the parent is not subscribed or is marked \NonExistent; CHILDINFO records that causal boundary.

The tree on screen is the answer to a question

A folder tree looks like an inventory. Its indentation implies containment, the disclosure control implies children, and every visible row appears to represent an object that exists. That visual grammar is useful. It is not the authority model RFC 5258 gives to an IMAP LIST response.

LIST-EXTENDED turns mailbox discovery into an explicit query. The reference name and mailbox patterns define a canonical matching surface. Selection options restrict or expand which names qualify. Return options request information about those qualified names. RECURSIVEMATCH can add an ancestor for context when a descendant, not the ancestor, meets the operative criteria.

The same server state can therefore yield different legitimate trees for different requests. One command can list subscribed names. Another can list all local names and annotate which are subscribed. A third can include remote names. A fourth can expose a parent solely because a subscribed descendant sits below it. The visible hierarchy is real for that request, principal and instant. It is not a timeless catalogue from which every other claim follows.

An audit record that stores only the response rows discards the governing question. To explain why a node appeared, it needs the advertised capability generation, authenticated principal, reference name, original patterns, canonicalized matching patterns, selection options, return options, server time and complete responses. Without that receipt, a later client or operator can mistake query scaffolding for an independently selected mailbox.

Selection determines names; return determines information

RFC 5258 draws a line that many APIs blur. A selection option tells the server which mailbox names the operation should select. Ordinarily a name must match at least one canonical LIST pattern and satisfy every selection criterion. RECURSIVEMATCH is the documented exception because it has special rules for parents.

A return option controls the information supplied for each matched name. It must not cause additional mailbox names to be reported. This sounds like syntax, but it is an authority boundary. Selection can change membership. Return can enrich the evidence attached to that membership. If an implementation treats an annotation request as a filter, or a filter as a request for metadata, the result may look plausible while answering a different question.

The two uses of SUBSCRIBED demonstrate the difference. As a selection option, SUBSCRIBED asks LIST to choose subscribed names instead of existing mailboxes. The returned set can be smaller than the existing mailbox set, and it can contain a subscribed name that no longer refers to an existing mailbox. As a return option, SUBSCRIBED merely adds accurate subscription state to every name already selected by the underlying LIST operation. It neither limits the answer to subscribed names nor creates new names.

SUBSCRIBED selection implies the corresponding return option, so selected rows carry the \Subscribed attribute. That convenience does not erase the distinction. A compliance or migration tool must still know whether subscription was the reason a row qualified or merely an attribute reported about a row that qualified for another reason.

The distinction also explains why LIST (SUBSCRIBED) is not simply a new spelling of LSUB. RFC 5258 requires the extended LIST attributes to retain their ordinary meanings and be accurately computed. LSUB carries older special behaviour. A client that normalizes both transcripts into one generic “subscribed folders” object loses the specification's reason for defining the new operation.

A returned parent may have failed the subscription test

RECURSIVEMATCH exists so a client can build useful hierarchy context around a filtered result. Suppose Foo/Baz is subscribed, but Foo is not. A request whose pattern shows only one hierarchy level would ordinarily omit both: the parent fails the subscription selection, while the subscribed child falls outside the pattern.

When the client adds RECURSIVEMATCH, the server may return Foo with a CHILDINFO item naming SUBSCRIBED. The parent still has to match the command's canonical LIST pattern. The descendant that caused the response does not. The resulting row therefore says: this name supplies hierarchy context because at least one descendant meets the stated criterion. It does not say the parent itself meets that criterion.

That causal difference is easy to lose in a UI. A tree builder receives one row for Foo, sees a subscription-related response and draws a folder. If it discards CHILDINFO, the row can be cached as a subscribed mailbox. If it converts every visible node into a selectable target, an explanatory ancestor acquires powers the server never reported.

RFC 5258 prevents another ambiguous use: RECURSIVEMATCH cannot be sent by itself or only with REMOTE. It exists to explain recursive satisfaction of another selection criterion. With no such criterion, the server must reject the command with BAD. The validity rule is a reminder that “recursive” is not a generic request for the whole tree.

The parent may not exist

IMAP hierarchy syntax does not require every textual ancestor to be an existing mailbox. A server can have Customers/ABC without a mailbox named Customers. RECURSIVEMATCH must still be able to expose the ancestor needed to render the descendant's position.

In that case the response can attach \NonExistent to the parent and add CHILDINFO for SUBSCRIBED. The attributes are additive. The correct reading is not paradoxical: the parent name does not designate an existing mailbox, and it was returned because a descendant satisfied the subscription criteria. \NonExistent also implies \NoSelect.

The same additive rule allows a name to be both \Subscribed and \NonExistent. Subscription is state associated with a name; existence is a separate state of a mailbox object. A deleted mailbox can leave a subscribed name behind. Treating subscription as existence would erase precisely the stale state that a repair or cleanup operation needs to see.

For leadership, the important lesson is not that IMAP permits an odd tree. It is that a result row can be a join across different reality layers: a name that matches a pattern, a subscription record, an existence test and a descendant cause. A database or client cache that flattens those facts into folder.exists = true manufactures authority.

The prior RFC 2342 question remains separate. NAMESPACE describes how personal, other-user and shared names are structured; it does not prove existence or access. RFC 5258 adds a narrower operating problem: even after executing a discovery query, the appearance of a node may be caused by a descendant rather than by that node's own state. Namespace grammar and LIST causation need separate receipts.

CHILDINFO is a reason, not the child list

CHILDINFO records the selection criteria that caused a nonmatching ancestor to be returned. It says at least one descendant met those criteria. It does not name the descendant, freeze it or promise that the next request will find it.

The specification warns clients to handle the case in which no qualifying descendant remains by the time they follow up. Another actor may delete or rename the child between the LIST response and the next command. Access control can also change. This makes CHILDINFO a time-bounded observation, not a durable foreign key.

Its criteria are still operationally valuable. They distinguish a solicited recursive response from an unsolicited response and help attribute rows to different pipelined LIST commands that asked different questions. If a client sends several commands without waiting, command tags alone do not give every untagged LIST row its business meaning. The CHILDINFO reason, request parameters and receive order form the dependency record.

Servers should suppress redundant CHILDINFO when they are also returning a matching child, but “should” is not a safe inference rule for absence. A client must accept a redundant reason without double-counting the mailbox, and it must not conclude that a missing CHILDINFO means no matching descendant exists when the response was not authorized to carry that item.

CHILDINFO is also not \HasChildren. CHILDINFO explains why selection caused a row to appear. \HasChildren supports hierarchy navigation by stating that the mailbox has children under the applicable access view. One is causal query provenance; the other is child-state metadata.

An expansion arrow is scoped to a principal and an instant

The CHILDREN return option asks for \HasChildren or \HasNoChildren. Clients use those attributes to avoid fetching an entire large hierarchy before drawing a collapsed tree. The optimization moves a server observation into a familiar piece of user interface: the expansion arrow.

Even this apparently simple annotation has limits. A server should not report \HasChildren when children exist but the authenticated user cannot access any of them. It may not always be able to compute that access efficiently. An attribute that was correct during processing may be stale when the user expands the node because a child was deleted or made inaccessible in the interval.

\HasNoChildren means there are no child mailboxes accessible to the currently authenticated user. It does not assert that no child exists for any principal. Nor is it the same as \NoInferiors, which says that inferior mailboxes do not exist and cannot be created in the future. A UI that converts both into a permanent leaf property discards the difference between current visibility and structural impossibility.

The safe cache key therefore includes server, account or authenticated principal, namespace generation, mailbox name, access-policy generation and observation time. The safe UI treats expansion as a discoverable action whose result can change. It does not authorize deletion of cached descendants or declare a global absence solely because one principal received \HasNoChildren.

Remote and later extensions enlarge the projection, not its authority

REMOTE is unusual among selection options because it expands the population to remote as well as local mailboxes. It has no parallel return option. The anomaly is explicit: the option changes which operational domain LIST examines. It still does not make a returned remote name proof of reachability, selection success or message access.

Later standards build more information onto the same surface. LIST-STATUS can attach status data. SPECIAL-USE can expose role attributes. NOTIFY and CONTEXT can support updates. ACL defines rights that remain distinct from the appearance of a name. These capabilities can make a mailbox tree richer and more current without turning it into a canonical inventory independent of the request and principal.

The IANA registries preserve the shared vocabulary for capabilities and mailbox-name attributes. Registry presence proves that peers have a common token and normative reference. It does not prove that a particular deployment advertises the extension, computes every attribute correctly, exposes the same remote population or keeps its client cache synchronized.

RFC 9051 carries modern IMAP forward, but the evidence question remains local and concrete. What exact command ran, against which server state, for which authenticated identity, and why did each row appear? A broad “supports IMAP4rev2” field cannot answer it.

Preserve the cause before the tree drives action

A defensible discovery record stores more than names. For each invocation it retains capabilities, server and session identity, authenticated principal, reference name, raw patterns, canonical matching interpretation, selection options, return options, command tag and complete untagged responses. For each row it records direct selection versus recursive inclusion, all attributes, CHILDINFO criteria and processing time.

Downstream systems then join that projection to separate evidence: current existence, subscription owner and generation, ACL rights, SELECT or EXAMINE result, STATUS generation, synchronization state, message retrieval and rendered user outcome. None is inferred merely from indentation.

Lu Heng's reality-layer discipline makes the management rule clear. The returned parent is real as an element of one query result. The matching child is real as the cause reported at one instant. The mailbox object, subscription, access right and screen node are separately real. An efficient abstraction remains trustworthy only while those joins are reversible.

The leadership failure begins when the convenient tree becomes the source of truth for migration, retention, access review or deletion. A node that existed only to explain a descendant can then be processed as a mailbox; an access-scoped leaf can be declared globally empty; a stale subscription can be promoted into an existing object. Preserve the question and the cause before granting the answer operational power.

Sources