Summary

  • An IMAP mailbox ACL is a set of identifier-and-rights entries. A logged-in user may match a personal identifier, one or more groups and anyone, so one entry is only an input to the authorization decision.
  • GETACL shows rules, LISTRIGHTS shows what a server can grant to an identifier, and MYRIGHTS shows the server’s effective answer for the current user. They are deliberately different questions.
  • DELETEACL removes an entry; a negative-right identifier subtracts authority during calculation. RFC 4314 clarified that distinction, but kept identity combination and negative-right support partly local.

The clean edit that did not settle the question

Access-control screens encourage a comforting story. Find the row bearing a user’s name, remove it, save, and the user is gone. That story is true only if the row was the user’s sole path to authority and if the running system has already recomputed the decision.

Shared mailboxes made the weakness visible early. A support queue could belong to a team. A person might have a direct grant, inherit another through a group, and receive a third through a public or organisation-wide identity. The rule list described several reasons for access. It was not itself the final answer.

RFC 1730 had made the remote mailbox a manipulable network object: clients could select folders, read messages, set flags and alter mailbox state on a server. Once more than one person could work on the same object, access control also had to travel through the protocol. A local filesystem permission visible only to the server operator was not enough for a remote mail client that needed to discover what its user could do.

RFC 2086, published on the Standards Track in January 1997, added that surface. A server announced ACL in its capability list. The extension defined a mailbox ACL as a set of pairs: an identifier and a string of rights. The client could retrieve or modify those pairs without learning the server’s entire account database.

One session could arrive under several names

The apparent simplicity of a pair concealed the main design problem. RFC 2086 reserved anyone for the universal identity, including anonymous access. User names accepted by LOGIN or AUTHENTICATE represented their corresponding users. Other identifiers could mean groups or other locally defined principals.

Several of those identifiers could apply to the same session. Fred might match fred, support-team and anyone at once. The RFC deliberately did not impose one universal combination algorithm. A server might take the union of all applicable grants; another might use only the most specific matching identifier. That choice belonged to the implementation and its local security model.

This was not a gap that a client could safely fill. A graphical editor could display rows, but it could not infer the running server’s group membership, forced owner rights or precedence rule. The same visible list could therefore yield different effective outcomes on two conforming systems.

The protocol’s answer was not to centralise identity. It was to expose the final calculation. MYRIGHTS mailbox asked the server which rights the logged-in user actually had for that mailbox. The reply was executable-state evidence from the component that would enforce the next command.

Three queries, three layers of reality

The extension separated questions that administration tools often collapse.

GETACL returned the identifier-and-rights entries stored for a mailbox. It answered: what rules are declared here? It did not say which entries applied to the current user, or how the server combined them.

LISTRIGHTS took a mailbox and an identifier and reported what rights could be granted. Some rights could be mandatory; others could be offered in tied sets because the underlying implementation could not separate them. It answered: what changes can this server represent for this principal?

MYRIGHTS returned the current user’s effective rights. It answered: after identity matching and local combination, what does the enforcing server say this session may do?

The distinction matters because a control panel may succeed at changing its model and still fail to change authority. A rule readback proves persistence. A MYRIGHTS readback proves the server’s current calculation for one session. Only the attempted mailbox operation establishes whether the relevant action was accepted, and even that does not identify the human behind the credentials.

Deletion removed a reason, not necessarily the result

DELETEACL mailbox fred removes the pair for fred. If Fred retains w through support-team or anyone, deletion has done exactly what its name says while leaving effective write authority intact.

RFC 2086 also reserved identifiers beginning with a dash for negative rights. RFC 4314 made their purpose sharper. An entry such as -fred with w subtracts write authority associated with Fred even if another matching identity would otherwise supply it. A negative entry participates in the calculation; DELETEACL merely removes one positive or negative pair.

Negative-right support remained optional. That is important. A client could not promise a universal “deny overrides allow” button merely because the protocol had a notation for subtraction. It first had to discover what the server supported and then verify the effective result.

Two uses of the minus sign also had to remain separate. In the rights argument of SETACL, -w means remove w from the selected entry. In the identifier position, -fred denotes a negative-right entry. The first edits one row; the second changes how the calculation may subtract authority. Similar punctuation did not make them the same operation.

Rights became narrower without abandoning old clients

The first extension used compact letters: lookup, read, seen-state, other flag writes, insert, post, create, delete and administer. Some boundaries were too broad. Implementations disagreed, for example, about whether c or d controlled deletion of an entire mailbox.

RFC 4314 replaced RFC 2086 in December 2005 and split the ambiguous operations. k governed creation of a child mailbox; x governed deleting or moving a mailbox; t governed setting the message’s deleted flag; e governed expunging messages. The old c and d survived as virtual compatibility rights so an older client could receive an intelligible projection while a newer server enforced finer distinctions.

That migration is a small history of protocol restraint. The revision did not pretend deployed software could be replaced at once. It narrowed authority in the new model, advertised extra rights through RIGHTS=, and maintained a lossy but defined view for old implementations.

It also imposed a rule on new editors: preserve rights you do not understand if you allow a user to edit the rest. Otherwise a client built before a new permission existed could read an entry, write back only the letters it recognised and silently destroy the unknown grant. Extensibility required ignorance to be conservative.

Revocation had a time boundary too

Even a correct effective-rights change might not govern an already selected mailbox immediately. RFC 4314 allowed a server to cache rights when a mailbox was selected. After SETACL or DELETEACL, operations such as STORE or EXPUNGE might continue under the cached decision until the mailbox was selected again.

A server that checked every command could send updated flags, refuse selected-state operations or close the connection after read access vanished. But the specification did not manufacture one instantaneous distributed revocation point. It identified the session boundary that operators had to test.

Ordering mattered as well. If a client pipelined SETACL and MYRIGHTS, the server had to complete the modification before calculating the reply. The protocol could make one connection’s evidence ordered; it could not prove what another session had cached or what a human client would display.

The list itself disclosed power

An ACL was sensitive even when it contained no message text. It could reveal that a mailbox existed, which users or groups existed, and who administered them. RFC 2086 already warned that an unauthorized GETACL must not expose a restricted mailbox. RFC 4314 required the response to look like the response for a nonexistent mailbox when the requester lacked listing authority.

The later RFC also rejected treating read access as enough to inspect the ACL: identifiers in the list were security information of their own. And the extension did not encrypt that information. Without STARTTLS, negotiated privacy in authentication or another protection mechanism, ACL data travelled in the clear.

Authorization and confidentiality therefore stayed separate. A correct answer about who may read a mailbox was not a guarantee that the answer itself was private in transit.

A standard that admitted its local remainder

RFC 4314 listed its own deficiencies. The method for combining identities remained implementation-defined. Users, groups and special identifiers inhabited one namespace. A friendly interface could not always explain a server’s local model. It lacked general ownership-changing operations familiar from filesystems.

The document nevertheless called the backward-compatible revision worthwhile because RFC 2086 had already been deployed in multiple implementations. RFC 9051 later defined IMAP4rev2 and kept registered IMAP4rev1 extensions generally usable unless a specification said otherwise. That is continuity of a protocol surface, not evidence that every current mail service implements ACL or negative rights.

The durable result is narrower. IMAP did not make one rule list sovereign over every mail server. It standardised enough questions for a client to distinguish declared entries, grantable operations and effective authority, while leaving the executing system responsible for its identity graph and final decision.

Sources