Summary

  • RFC 6154, published in March 2011, defined optional special-use attributes that an IMAP server can attach to mailboxes in LIST replies. Clients could discover roles such as \Sent, \Drafts and \Trash without inferring them from display names.
  • The attribute describes a role, not a uniform filing engine. A server may put sent messages into \Sent automatically or merely advise a client to save copies there. A mailbox can carry several attributes, and more than one mailbox can have the same role.
  • Extended LIST can advertise SPECIAL-USE; optional CREATE and METADATA mechanisms let clients request or edit roles where the server permits them. The server can refuse an unsupported or conflicting request. The IANA mailbox-attribute registry records the shared vocabulary.

The folder name was a bad protocol

Imagine adding the same mailbox to two programs. One wants a place for sent copies; the other has already been using a folder whose visible name happens to look right. If the programs both create their own folder, the user can end up with two histories of what was sent. If one guesses wrong, a sent copy can disappear from the folder the user checks. The problem is small enough to look like a settings annoyance and large enough to make a person's mail history unreliable.

An earlier IETF IMAP implementation guide discussed conventional names such as “Sent Mail” and “Trash.” Conventions help humans. They leave a client with a language and naming problem: the server may use another label, the user may have renamed a folder, and a particular name does not reveal whether the server or client is responsible for filling it. A display string had become a fragile substitute for a machine-readable job description.

RFC 6154 moved that description into the IMAP LIST response. It defined seven initial attributes: \All, \Archive, \Drafts, \Flagged, \Junk, \Sent and \Trash. The server can return them with the mailbox's other attributes. The client can look for the role instead of guessing from the visible name. The folder might be named SentMail, MyDrafts or something a person chose; \Sent and \Drafts are the common signals.

The change sounds like a label on a drawer. It is really a shift in who answers the configuration question. Before, a client guessed or asked the user to translate the server's storage layout. After, a cooperating server could state which mailbox it had set aside for a function. That statement is useful because the server knows its own layout and behavior better than a new client does. The user still controls how to use the account, but the client need not reconstruct server intent from typography.

A role is not an action log

RFC 6154 refuses to pretend that all mail stores work alike. For \Sent, some servers automatically place copies of outgoing mail in the designated mailbox. Others give the client advice: save sent copies here. A client that assumes the server will do the work can leave the drawer empty. A client that assumes it must do the work when the server already does it can create duplicate copies. The attribute solves discovery of a role; observed filing behavior settles who performs it.

Other attributes are just as specific. \All may present a virtual view of the message store and may omit mail in \Trash or \Junk. \Archive names a purpose whose practical meaning depends on the server. \Drafts can be a virtual collection of messages marked as drafts or a destination suggested to the client. \Trash can reflect a server's deletion model or be a place a client uses when it does not rely on IMAP's \Deleted flag. The common marks let clients find intended roles without erasing those operating differences.

The multiplicity matters too. A mailbox can have no special-use mark, one mark or several. More than one mailbox may carry the same mark. Roles are likely specific to a user: two people may share a physical mailbox without sharing the same idea of which mailbox is their \Sent destination. A client looking for exactly one universal answer across every account would be making another guess, this time with a standardized string in hand.

The IANA registry now records mailbox attribute names and defining references. That is a vocabulary service. It lets implementations agree that \Sent is a role marker. It cannot observe whether a server stored a given message, whether a client saved a copy, or whether the user sees both copies in one view. The running mail store supplies those answers.

Discovery, request and refusal

The extension fitted into the extended LIST framework. A server supporting that form advertises SPECIAL-USE in CAPABILITY. A client can request a LIST of only marked mailboxes, or ask that the returned entries include their special-use marks. The selection option implies the return option. A server may also include the marks in an ordinary LIST reply, where this particular support has no separate capability string. Those details matter in a trace: absence of a capability string in one mode does not by itself prove that no role information could appear.

Discovering a role is the first operation. RFC 6154 added an optional USE parameter to CREATE so a client could request a mailbox with a designated role. Support for that operation is separately advertised as CREATE-SPECIAL-USE. A server can decide that a new role conflicts with an existing one, can move the designation, or can allow duplicates. If it cannot create the mailbox with the requested role, it must reject the operation without creating the mailbox. The failed request is a real boundary, not a half-created folder that the client may treat as configured.

The document also describes /private/specialuse for servers that support IMAP METADATA. A server may permit changes to roles on existing mailboxes through that entry. It must validate changes rather than blindly accepting labels that its implementation cannot support. A name change, a role change and a message movement are different operations; the protocol gives them different evidence.

The security consequence is concrete. Some servers may automatically move mail to a \Junk mailbox. RFC 6154 describes a case where assigning that role to a shared mailbox could expose legitimate messages falsely classified as junk to other people. The risk follows from the server's action behind the mark. A role is a configuration lever when the server acts on it, so the server must decide which requests to honor.

The standard establishes how roles can be advertised, requested and recorded. It does not establish where a named account actually stored its sent mail. A dated CAPABILITY/LIST exchange, any CREATE or METADATA change, and a trace of a sent message's placement would answer that question for one account. The title painted on the drawer is the weakest evidence of the three.