Spiced Up

When the first version of the Internet Message Access Protocol 4 (IMAP 4) appeared in 1994, mobile phones looked more like bones you would give your dog than phones – and they couldn't do much more than bones either. Digital data trickled off the Internet through modems in homeopathic doses. The Universal Mobile Telecommunications System (UMTS) and mobile email clients did not even exist, and email was only tentatively gaining ground.

Growing Demand

To adapt IMAP 4 to modern demands, and especially mobile clients, the Network Working Group of the Internet Engineering Task Force enriched the IMAP protocol in a whole series of RFCs with extensions that give IMAP new features, but without disturbing clients and servers that use older versions.

Many of the protocol extensions are still at the proposal stage; the unofficial IMAP wiki [1] has a fairly comprehensive list (see Figure 1) if you are interested in finding out more. Some of these extensions are also part of the Lemonade (License to enhance message-oriented network access for diverse environments) profile. Under this umbrella, RFC 4550 [2] gathered more than 20 IMAP protocol extensions explicitly to improve communication with mobile clients.

Figure 1: This matrix attempts to clarify which IMAP servers implement which enhancements.

Although it's possible that no server has implemented the more exotic extensions, administrators are amazed that they need to enable other extensions on the server because they are not an integral part of the protocol (Table 1).

In this article, we present a selection of commonly used extensions and briefly explain their purpose. More details are available in the related RFCs, which are often dozens of pages long.

Discoverers: CAPABILITY

The CAPABILITY command [3] is not an extension but an important function of IMAP 4. The client uses it to discover which extensions the server supports. The server returns a long line that lists its capabilities as key words. If the ID command [4] is enabled on the server side, the client is allowed to send information about itself to the server, such as its version number and name. However, the RFC says that the server and client should not use this information to try and work around bugs; instead, they are meant to help the postmaster identify bugs and notify the software vendor.

Silent Observer: IDLE

According to the IMAP 4 protocol, a client must actively ask the server whether new email is available or whether someone has deleted existing messages, although it makes more sense for the server to notify the client when new email arrives because such on-demand requests save resources. Although the server might occasionally respond with EXISTS (e.g., if the size of the mailbox changes), the client cannot rely on this behavior and has to ask anyway.

If the server returns IDLE [5] as a capability, the client can allow it to send unsolicited messages about new email while the client is in IDLE mode. To enable this, the client sends an IDLE command to the server, which replies with a continuation request (+). As long as the IDLE status exists, the server can send messages without sequence numbers (untagged), such as EXISTS or EXPUNGE. The client itself cannot send any commands of its own at this time.

The master/slave relationship ends as soon as the client sends a DONE. In this case, the server sends any outstanding untagged lines and responds with a sequence number to the DONE. If the client fails to terminate the IDLE command by sending DONE, the server can throw it out, assuming a timeout is defined. Thus, the RFC recommends that clients send another IDLE after 29 minutes to avoid this fate.