Tricky: LIST-EXTENDED

Traditionally, the commands LIST and LSUB show the contents of mailboxes. But new IMAP extensions have given rise to a need for specific types of lists. Because LIST and LSUB are not innately extensible, clients were forced to run a series of increasingly long commands to achieve the effect required by the extensions.

The LIST-EXTENDED extension [14] solves the problem by modifying the existing LIST command, such that it no longer requires any special commands but can be supplemented with a variety of options and search patterns. The new syntax is downwardly compatible and is used only if the first or second word after the command starts with a bracket, or if the LIST command has more than two parameters. Otherwise, the traditional LIST command serves as a fallback.

Real Names: NAMESPACE

Because IMAP 4 does not define a default namespace, two generic namespace conventions have emerged: In the "Personal Mailbox" model, the default namespace only represents the personal mailboxes of the user. In contrast, the "Complete Hierarchy" model includes all other digital mailboxes that the user can access – in addition to the user's own mailbox. The problem with these models relates to the configuration overhead associated with them.

The NAMESPACE command [15] allows clients to discover automatically the server-defined prefixes for mailboxes (Figure 3) and so distinguish between personal mailboxes, mailboxes of other users, and shared folders. This allows admins to assign public inboxes (e.g., the mailing list) a prefix of public, to distinguish shared mailboxes with the shared prefix, and to tag the per-user mailboxes as private. This not only saves manual labor, but the mailboxes on a namespace can thus also reside in different places on the network and use different formats, for example Maildir and Mbox.

Figure 3: This IMAP 4 server reveals its capabilities, indicating that, among other things, it supports NAMESPACE, as well as IDLE and ID.

Everything Goes: ACL

Mailboxes assigned with the use of NAMESPACE typically also have different access rights. Access Control Lists for mailboxes and the ACL [16] extension allow the administrator to view and modify rights using IMAP commands. The associated RFC from 1997 turned out to be lacking; thus, RFC 4314 [17] followed up by defining new access rights and adding clarity to the rights situation.

Besides the ACL string, the server needs to use RIGHTS = to indicate the rights it supports when responding to CAPABILITY: currently 11 standard rights and two virtual rights (d and c), which exist for reasons of compatibility with RFC 2086. Possible commands in combination with the RFC include: SETACL, GETACL, DELETEACL, LISTRIGHTS, and MYRIGHTS.

ACL entries consist of two components (access identifier and rights) and can be assigned to specific mailboxes. The access identifier usually consists of the username (a UTF8 string) and is also accepted by LOG and AUTHENTICATE. However, more than one identifier can exist for each user. Additionally, the RFC defines an anyone identifier, which references a generic identity that includes anonymous logins. If the identifier is preceded by -, the associated user is denied the assigned rights.

Whereas lowercase letters show the rights of the user, the RFC uses numbers for rights assignments in the context of server implementations: Postmasters can use these to assign or deny certain rights across the board, thus ensuring, for example, that users can only manage their own mailboxes.