© Christian Draghici, 123RF.com

© Christian Draghici, 123RF.com

IMAP 4 protocol extensions

Spiced Up

Article from ADMIN 14/2013
By , By
A set of protocol extensions keeps the legacy IMAP 4 protocol usable, which also helps mobile clients. We present a healthful mix of useful extensions.

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).

Table 1

A Client Talks to an IMAP 4 Server. 

Client Server Explanation
  * OK IMAP4rev1 Service Ready Server greets client
a001 login mrc secret   Client logs in
  a001 OK LOGIN completed Server acknowledges
a002 select inbox   Client selects Inbox as the active folder
  * 18 EXISTS 18 messages found
  * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) Defined flags
  * 2 RECENT 2 urgent messages (e.g., new mail)
  * OK [UNSEEN 17] Message 17 is the first unseen message Message 17 is unread; all older messages have been read
  a002 OK [READ-WRITE] SELECT completed Client may make changes to mail
a003 fetch 12 full   Client requests information about message 12
  * 12 FETCH (FLAGS (\Seen) Mail has been read
  INTERNALDATE "17-Jul-1996 02:44:25 -0700" Delivered 17 July 1996
  RFC822.SIZE 4286 More than 4KB
  ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" Mail header:
  "IMAP4rev1 WG mtg summary and minutes" Date
  (("Terry Gray" NIL "gray" "cac.washington.edu")) Subject
  (("Terry Gray" NIL "gray" "cac.washington.edu")) From
  (("Terry Gray" NIL "gray" "cac.washington.edu")) Sender
  ((NIL NIL "imap" "cac.washington.edu")) Reply to
  (("John Klensin" NIL "KLENSIN" "MIT.EDU")) To
  From the German Wikipedia entry for IMAP.

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.

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>


		<div class=