Spiced Up

Quick Search: ESEARCH

The IMAP standard already includes two search functions in the form of SEARCH, which searches email messages on the basis of their Message Sequence Numbers (MSNs), and UID SEARCH, which uses the unique identifier. One disadvantage, however, is that you cannot limit the number of returned results.

ESEARCH [10], on the other hand, gives the seeker various result options. Thus, you can limit the search results to a minimum and maximum value or return only a certain number of results. Even finding all results is quicker because the search results are returned as a sequence set, which is compact and saves bandwidth. What's more, this set can be used in a subsequent command.

New: SORT and THREAD

The next two extensions, SORT and THREAD, share a common RFC [11]. SORT surprisingly is not a fixed part of the IMAP protocol. Representing email in threads is not really new either, and ultimately only a sort algorithm. SORT and THREAD take place on the server side, thus saving client resources (Figure 2). Both extensions have to process the terms to be sorted in line with the requirements of I18NLEVEL=1, which is part of an RFC [12] that regulates the handling of international character sets.

Figure 2: The contents of mailboxes can be download in a targeted way, as shown here in Thunderbird, and also backed up and searched locally if needed.

The server advertises its sorting capability by returning SORT as a response, and it also outputs the threading algorithm for the THREAD capability. A server response thus might be THREAD=ORDEREDSUBJECT, which is the simpler of the two available threading algorithms the RFC introduces as "the poor man's threading." The algorithm first sorts email by subject then, given the same subject line, sorts by delivery date, where ORDEREDSUBJECT then converts these messages into threads.

Of course, this can cause problems if someone replies to a thread but changes the subject line. In this case, the REFERENCES algorithm chips in. It is much more sophisticated than ORDEREDSUBJECT and needs six main steps to create a thread (explained in detail by RFC 5256 [11] on pages 8-11).

More Accessible: UIDPLUS

According to the RFC, UIDPLUS [13], part of the Lemonade specification, is an extension that handles particularly hard-to-reach clients. The extension is designed to reduce time and resource consumption. To do so, it defines an additional command: UID EXPUNGE deletes messages that have both the \Delete flag set and a unique identifier (UID) that appears in the sequence set of the currently selected mailbox. It proves to be particularly suitable when a client that is only temporarily connected re-synchronizes with the server.

If the UID EXPUNGE extension is used instead of EXPUNGE, the client no longer accidentally deletes messages from other users that have been marked for deletion while it was offline. In this case, the second criterion does not apply because the UIDs of the deleted messages do not belong to the mailbox. This behavior becomes relevant when users share mailboxes or for users of both mobile and fixed clients.