White Paper: POP goes the email

Modern email server protocols such as IMAP offer more features than established ones such as POP. But IMAP extensions can make...

Modern email server protocols such as IMAP offer more features than established ones such as POP. But IMAP extensions can make communication between client and server problematic

A brief history of POP

POP was designed primarily to support the offline access mode and is used widely on the Internet. POP servers and clients are widely available commercially and as freeware. POP is an Internet standard (Internet Standard 53, published as Standard 53, Request for Comments 1939, having passed the Internet standards process. It has remained virtually unchanged for years and as a result is a simple, well documented, mature protocol that is both proven and effective. In fact, nearly all Internet Service Providers (ISPs) support and use POP.

POP functionality

POP was designed for use in offline mode. Typically, email arrives from the network and is placed in the user's inbox on the server. POP is then used to transfer the email from the user's inbox on the server to the user's computer.

POP is designed so that mail client software can determine which messages have been previously downloaded from the server. The mail client can then download only new messages. POP also provides the ability to selectively delete messages from the server.

POP can be used by a mail client to perform basic resynchronisation of the inbox on both the server and on the user's computer, leaving the most recent messages on the server after they have been downloaded. The messages can then be downloaded a second time to a second computer. There is no way to propagate changes made to either the messages or the messages filed in other folders back to the server.

Some POP implementations provide additional options, such as downloading only headers at one session to review the topics, and then downloading selected bodies and attachments in a subsequent session to minimise connection times over slow links.


POP is a simple protocol and has been finalised as an Internet standard. As a result, an abundance of feature-rich, refined and tuned implementations are currently available. POP servers are widely available both as freeware and commercially on a number of operating systems. Moreover, there are almost no interoperability issues between POP servers and mail clients. As a result, users can use just about any POP mail client with any POP server.

IMAP, the Internet message access protocol

A brief history of IMAP

IMAP has existed in various manifestations for more than 10 years. However, it has only recently generated much interest and discussion, primarily because it supports offline, online and disconnected/resynchronisation modes. While IMAP is not currently an Internet standard, it is on the Internet Engineering Task Force (IETF) standards track and is expected to attain Internet standard ranking eventually. The following is a brief chronology of IMAP standards:

• IMAP version 2 (IMAP2) was published as RFC 1176 in August 1990 as an experimental protocol

• A later version, IMAP version 2bis (IMAP2bis) added support for Multipurpose Internet Mail Extensions (MIME), but was never published as an RFC

• IMAP version 4 (IMAP4) was published as RFC 1730 in December 1994 as a proposed Internet standard. IMAP4 includes support for MIME and resynchronisation

• A draft of IMAP4, revision 1, published as RFC 2060 in December 1996, includes some minor adjustments to work with the digital signature standards specified in RFC 1847

• There are a number of companion documents published as RFCs

• If the large development efforts currently underway are any indication, as IMAP matures and progresses on the standards track, it is quite likely that many clients and servers will be made available

IMAP Functionality

IMAP has a much larger set of protocol commands than POP because it supports both online and disconnected/resynchronisation modes. Online mode is more complicated to support than offline mode because the protocol must allow the mail client to store and manipulate all the mail on the server in a general way. Resynchronisation mode requires additional functionality so that the mail client can determine the synchronised state of the mailboxes. The following list outlines some of the features required in the IMAP protocol to support the three mail access modes. IMAP must be able to:

• Manipulate hierarchical mailbox collections on the server

• Access any mailbox on the server: inbox, filed mail or shared

• Access several mailboxes at once

• Fetch message status, headers and structures

• Fetch message bodies and sub-parts or attachments (MIME integration)

• Change message status on the server

• Store, copy and move messages on the server

• Search mail stored on the server

• Provide unique message identifiers for mailbox resynchronisation

These features are a superset of the features found in POP, so you could correctly conclude that IMAP can do everything POP can do. However, this does not mean a given IMAP implementation is better for a particular user than a given POP implementation.

As an example, suppose we compare the best IMAP implementation for online mode with the best POP implementation for offline mode for a user who travels constantly with a laptop computer. The IMAP implementation is less effective in this situation since the user would require a network connection to access, read and reply to email, which is not possible in transit or on a plane. The POP solution is a better solution because the user can quickly download mail during a network connection and then read the mail when disconnected. An IMAP solution in offline mode might also be appropriate in this situation. The important point is that the access mode is likely to be more important to the user than the access protocol.

IMAP Extensions

Extensions add capabilities to IMAP and keep pace with the ever-growing needs of users and their increasingly sophisticated mail client applications.


Performed on the server instead of on the client, it is vital for slow links in online mode to avoid waiting minutes to open a large mailbox. Currently, sorting is only available in experimental implementations only.


IMAP has search facilities, but only for one mailbox at a time. The facilities allow all mailboxes to be searched only if they are individually opened, searched and closed. The scan extension can be used to search across all the mailboxes a user has on a particular server, which makes searches across the collection of mailboxes much more efficient, especially for certain server implementations.


Allow users to modify stored messages for items such as labels, priorities, message status and user-editable subject. Currently, there is only a rough specification and no implementation is available.


Manage disk limits for mail stored by users on the server. Since users of IMAP-based clients leave most or all of their mail on the server, disk space usage on the server is an issue.


Access Control List (ACL)

Allows an individual to grant or deny other users access to mailboxes.

Resynchronisation optimisation

Makes operations in resynchronisation modes more efficient by reducing the amount of network traffic needed to resynchronise.

On-server filtering

Allows filtering to be performed on the server as mail arrives. Without it, filtering must be conducted in a quasi-online mode and may be inefficient over slow links. An IETF working group is being assembled to consider the on-server filtering extension, but no accepted specifications or implementations are currently available.

When an IMAP client and server connect, they negotiate which extensions they will use, based on the extensions made available by the server and those the client can use. The absence of an extension needed by a particular client may result in a lack of full functionality in the client and/or poor performance. So while extensions are vital because they allow IMAP to grow, they have the potential disadvantage of introducing interoperability problems.

Note that POP does not have an extension mechanism, nor is it of particular importance because the protocol operates primarily in offline mode and the access protocol has little to do with the available email client features. Extensions are also unlikely to be needed with offline IMAP clients.

IMAP deployment

As mentioned previously, IMAP is much larger and more complex than POP. IMAP client implementations - especially feature-rich ones - are therefore larger and more complicated than POP clients. To date, there are few sites that use IMAP and few ISPs that support it. A number of client and server implementations exist, although they have not reached the maturity of POP client and server implementations.

Online mode

The most popular and widely used IMAP implementations work in online mode. However, the features found in these clients do not match those in offline clients, partly because of current IMAP limitations. For example, IMAP does not allow any modifiable attributes per message. IMAP clients cannot allow users to change priorities, add labels or edit the subjects of received and filed email. In addition, IMAP does not support some of the searching and sorting options found in many POP mailers. Many of these limitations are being remedied through IMAP extensions.

Offline mode

Similarly, IMAP implementations are not yet tuned for offline mode. Users who try to use it offline may receive doubled messages when transfers are interrupted. These problems should be resolved in the near future.

Disconnect/Resynchronisation mode

Very few IMAP implementations perform resynchronisation. IMAP clients must contend with two resynchronisation issues that the core IMAP functionality does not support. The first is resynchronisation of editable message attributes, such as status, labels, priorities and edited subjects. The second is that of other information stored by a mail client, such as filter configuration, options, settings and address book

Matching IMAP servers and clients

The current state of IMAP implementations and the nature of IMAP extensions will probably make it vital to match the IMAP server to the IMAP client. The consequences of mismatched implementations, versions and extensions may include difficulty in configuration, poor performance and lack of functionality. These are some factors to be considered when exploring the IMAP option:

There have been several versions of the IMAP protocol, in particular IMAP2 and IMAP4, and not all IMAP servers and clients implement the same version. This can result in lack of functionality, difficulty in configuration and poor performance.

Some IMAP servers may not implement proper unique message identifiers.

A client operating in resynchronisation mode cannot be used with such servers.

Not all clients and servers use the same mailbox naming conventions. Usually, a client can be configured to work around this, but reconfiguration is not always simple and may require more knowledge of IMAP than most email users have.

An IMAP client implementation may assume that an IMAP operation, such as checking for new mail, is fast and efficient, when in fact that operation is quite slow on a particular server. The result can be extremely poor performance.

The extensions mechanism also raises interoperability issues, particularly because no set of extensions is required by the standard. If a particular extension required by a particular client is not available, the client will probably not work as well as it should. In the long term, possibly a year or two, these issues are likely to subside as IMAP is better understood, interoperability problems are corrected, implementations become more uniform and important extensions become widely deployed.

While a comparison of POP and IMAP is useful, the bottom line for IT managers is knowing how their mail software behaves on a day-to-day basis. This is likely to be affected more by the mode in which the mail software operates rather than the access protocol used.

Compiled by Paul Philips

Read more on Operating systems software