Spiced Up

Pre-Filtered: NOTIFY

IDLE has the disadvantage that it neither controls nor limits what commands the server sends and how it responds to certain events. Because idle also only works for a single mailbox, the server and client set up another TCP connection for each additional mailbox query. NOTIFY [6], however, puts the client in charge. It extends IDLE, letting the client determine the mailboxes from which it wants to receive messages. This makes NOTIFY a multi-mailbox IDLE while also streamlining communication.

The client uses NOTIFY SET to specify both the mailboxes and the kind of information it wants to receive. The server then sends a set of attributes  – along with the FETCH response – to the client that now becomes a passive observer. The NOTIFY effect continues until the client sends a new NOTIFY command or one of the entities closes the IMAP connection.

Because some mobile clients only want updates for messages that match a certain search pattern, the NOTIFY RFC also defines additional attributes for the UPDATE option, which take effect in this case.

Fully Synchronized: QRESYNC

The QRESYNC [7] extension quickly resynchronizes a user's mailbox. It is an extension of the CONDSTORE command. CONDSTORE in turn checks a mailbox for state changes that occur when a user is using different email clients or multiple users share a mailbox. If a user on client A changes the status of an email to "unread," you also want client B to notice this; the client needs to sift through the mailbox again (resync) to do this.

Although CONDSTORE identifies these changes and resolves conflicts caused by simultaneous access by multiple clients, Thunderbird and other mail clients need to send the UID FETCH and UID SEARCH commands in this case. In contrast, QRESYNC allows for a resync, including tracking of deleted files at one fell swoop. The VANISHED response introduced for this (and replacing EXPUNGED) discovers deleted email efficiently.

Use of the SELECT command on the client side removes the need for concurrent connections to the server that only exist to prevent resyncs. QRESYNC especially benefits mobile devices because they often have to retrieve their data more often because of poor network coverage. Little wonder that this extension is one of the Lemonade extensions mentioned earlier.

To use QRESYNC, the server needs to return ENABLE [8] as a capability. The ENABLE extension lets clients enable a particular capability explicitly. In the case of QRESYNC, the RFC requires the clients to have previously sent a targeted ENABLE QRESYNC to the server.

On the Move: MOVE

Before the IETF issued a helpful RFC [9] with two statements – MOVE and UID MOVE, making it possible to move email messages between mailboxes  – the only option was to combine several independent commands (COPY, STORE, and EXPUNGE) to achieve the same effect.

This implementation was found to be suboptimal for several reasons: If communications break down between the three steps, the move processes become stuck. This effect also confuses users because their clients still show the messages in this intermediate state. Additionally, in shared mailboxes, the third step might move not only the selected messages but also, inadvertently, messages marked for deletion by third parties.

MOVE solves these problems, whereas UID MOVE moves messages on the basis of their unique identifiers. For a client to discover whether a server supports this feature, the server needs to respond to the CAPABILITY request with MOVE.