Summary

  • Sieve can select a mailbox by its special-use role and use a named default when no matching mailbox is found. A storage failure at the selected mailbox does not authorize the same fallback.
  • Role assignments can redirect future filing without changing a script. Multiple matching mailboxes, permission-only checks and incomplete provisioning make the destination decision more consequential than a folder label suggests.
  • The operational bargain is deliberate: avoid silently spreading correspondence across destinations, while retaining an explicit obligation to recover the failed filing path.

Plenty of space, no permission to spill

The archive is full. Another folder has room. A filter already contains that other folder's name. To a service measured by completed deliveries, the obvious repair is to put the next message there.

In this constructed example, that apparently helpful move is precisely what the specification forbids. RFC 8579, the Sieve extension for special-use mailboxes, distinguishes failure to find a destination from failure to write to the destination it found. When delivery to the selected special-use mailbox fails for a reason unrelated to that mailbox's existence, the interpreter must not subsequently try the named default as a fallback.

The rule is not a promise that every failed message will be queued, bounced or retained in one particular way. The ordinary failure behavior of the filing action still applies. What the extension withholds is narrower: permission to transform a storage problem into a destination change.

That restraint has a practical purpose. If an intermittently failing archive sometimes receives messages and sometimes causes them to land in another folder, neither location contains the correspondence a reader expects. The delivery counter can improve while the filing system becomes less dependable. A fallback name was supplied, but not as an overflow policy.

The role comes before the name

Traditional Sieve filing addresses a mailbox by name. That is easy to understand and awkward to keep aligned across clients, languages and account reorganizations. A user's archive need not be called Archive. A junk-mail folder need not be called Spam. A folder bearing either name need not be the one the user currently intends for that purpose.

The IMAP special-use extension, RFC 6154, provided attributes such as \Archive, \Junk and \Sent so that clients could discover a mailbox's role. Sieve gained a direct way to use that information through RFC 8579. Its :specialuse argument tells the filing action to look for the specified role in the user's personal namespace before using the positional mailbox name.

The result is an ordered choice, not two equal destinations. If a matching special-use mailbox exists, it takes precedence. If none is found—or the implementation does not know the requested attribute—the action proceeds as it would without the special-use argument, using its ordinary named-destination behavior.

This lets a filter follow a user's preferred location without embedding its current name in the rule. It also means that unchanged filter text does not prove unchanged filing behavior. A different assignment of the role can send later messages to a different mailbox.

The two destination references can point to the same place. Indeed, when several personal mailboxes carry the requested attribute and the named default is one of them, RFC 8579 requires choosing that default. The explicit name breaks the tie in that case. It does not overrule a different, uniquely selected special-use destination merely because the latter encounters a write error.

Absence and failure have different remedies

Consider three distinct observations. No mailbox bears the requested role. A mailbox bears it but delivery to that mailbox fails because of quota. Several mailboxes bear it, leaving a selection decision.

Only the first is the straightforward role-lookup fallback case. In the second, the destination was found; lack of capacity does not make it disappear. The extension expressly prevents trying the named default after that non-existence-related failure. In the third, the implementation must first apply the selection rules rather than pretending that there is no role assignment.

This is why a single “fallback used” metric is insufficient. It can describe a legitimate default-name branch when the role is absent, or conceal an impermissible spill after the role was successfully resolved. Those paths produce superficially similar stored mail but imply different decisions.

The strongest argument for spillover is continuity. People may prefer a message somewhere to a filing error now. That preference can be reasonable. It still needs to be an explicit service decision with understood visibility and recovery consequences, not an interpretation smuggled into a parameter whose contract addresses a different condition.

The standard deliberately preserves a failure at this boundary rather than silently widening the filing action. It does not relieve operators of the resulting service problem. Capacity, access and recovery still need an owner. Preventing an unauthorized destination change and restoring timely mail handling are complementary duties.

A positive test does not reserve space

The extension also supplies specialuse_exists. Its name invites an overconfident reading: the desired mailbox exists, therefore filing there will work.

The test is more specific. Without an explicit mailbox argument, each requested attribute must be assigned to at least one mailbox in the user's personal namespace that permits delivery in the script's user context. Different requested attributes can be satisfied by different mailboxes. With an explicit mailbox argument, that particular mailbox must exist, allow delivery and carry all the requested attributes.

Neither form turns a list of roles into a guarantee of future storage. RFC 8579 refers to RFC 5490's mailbox eligibility definition. That document explicitly warns that a successful existence test need not mean a subsequent filing action succeeds: the action may put the user over quota.

Existence, authority to attempt insertion and capacity to complete it are separate facts. A permission check can be correct when it runs, while the eventual storage operation still fails. Treating the check as a reservation manufactures an assurance the protocol did not offer.

For an operator, the useful chain is therefore not just “test passed.” It is which user context was evaluated, which role assignments were visible, which mailbox was selected, what permission evidence was available and what actually happened during filing. This is a placement investigation, not a claim that one boolean is an end-to-end receipt.

One role need not mean one mailbox

The standard permits more than one personal mailbox with the same special-use attribute. When the named default does not break the tie, the chosen mailbox is implementation-defined.

RFC 8579 recommends consistent choice while the relevant assignments remain unchanged. It does not prescribe a universal ordering algorithm. Once those assignments change, the selected destination may change too. A migration that preserves the same set of role names can consequently still alter where new mail goes.

The important distinction is between a portable role vocabulary and a portable selection result. Importing an account's current folders and attributes may preserve the former without reproducing the latter. A team comparing only script hashes could miss the change completely.

The underlying role is also limited. RFC 6154 leaves the meaning of an archival mailbox to the server. An Archive attribute does not, by itself, establish a retention duration, immutability property or institutional recordkeeping obligation. It locates a function as that system understands it. It does not certify what the organization hopes the word archive implies.

None of this requires a malicious server. Flexible local semantics can be useful. The cost is that choosing, assigning and interpreting the role remain real decisions that cannot be delegated to a familiar label.

Someone must establish the role in the first place

Optional discovery works only after there is something meaningful to discover. RFC 6154 does not require every server to provide every special-use attribute. Creating a mailbox with a role through CREATE-SPECIAL-USE is a separate optional feature. Allowing clients to change assignments through metadata is also conditional on server support and validity checks.

A historical note in RFC 6154's errata record makes the coordination gap concrete. Erratum 4422 reports an informal interoperability test on 19 July 2015 in which a server expected the client to bootstrap special-use assignments while a client expected the server to do so. Both sides supported the surrounding idea; neither performed the initial work the other assumed.

That record is Held for Document Update. Its proposed remedies are not an enacted mandatory provisioning rule, and the report is not a measurement of today's mail services. It nevertheless documents a specific ownership failure: an optional capability can exist on both sides without an agreed party establishing usable state.

Sieve can create the named default when the required conditions and creation behavior apply. With the explicit :create argument, creation is requested when needed. If the server supports CREATE-SPECIAL-USE, RFC 8579 recommends assigning the requested role to the newly created mailbox. That recommendation must not be inflated into a guarantee that every successful default-folder creation also establishes the role.

The distinction matters on the next message. Successful name-based filing can conceal the fact that role-based selection has never begun.

The search boundary is part of the control

RFC 8579 restricts attribute-based destination discovery to the user's personal namespace. Searching the entire mail store would cost more and could cause messages to be filed unexpectedly, or maliciously, into shared mailboxes bearing the same attribute.

This is not a blanket statement that no personal mailbox can be shared, or that every explicitly named default destination must be personal. It is a limit on the search that resolves the special-use role. RFC 6154 separately warns that assigning certain roles can trigger automatic behavior and expose private mail when shared destinations are involved.

The distinction keeps the control precise. A convenient global search is not an innocuous extension of discovery if it changes who can cause a mailbox to become the destination for somebody else's messages. The authority to attach a role and the scope in which that role is discovered together determine the filing path.

Evidence, not a product diagnosis

The sources establish a protocol contract, not the behavior of a named provider. No mailbox, account, incident, service-level result or adoption rate was inspected for this article. Verified erratum 5877 for RFC 8579 corrects a match operator in a later example; it does not change the selection-versus-delivery-failure rule. No example here is an instruction to alter a live mail system.

Lu Heng's agency-problem essay supplies a useful question: does the party making an administrative choice bear the consequences of that choice? Applied here, a role-setting interface, a filtering service and the person searching for misplaced correspondence can experience very different versions of “success.”

His account of BTW's purpose asks for structural description rather than advocacy. The relevant structure is not mysterious. The default handles a missing role. The filing attempt remains bound to the selected mailbox. A failure does not quietly authorize another destination. Recovery must deal with that fact instead of making the counter look better.