Let's get IMAP vs. POP email protocols straight

IT pros must make a protocol choice -- POP vs. IMAP -- when they don't want outside applications interfering with email message downloading.

At some point, all IT professionals come across a service or application that needs to connect to corporate email...

systems. And they'll need to decide on the appropriate protocol for downloading messages: IMAP vs. POP.

Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) are designed for different scenarios, and their strengths and weaknesses should be understood before selecting one versus the other.

A help desk application where end users submit issues via their mail client is a common example of where an IT administrator would choose IMAP vs. POP email protocol implementation, or vice versa.

POP shows limitations in ubiquitous computing era

POP came about in response to the rise in personal computers, enabling users to simply download messages from a server to a client. POP connects to the remote mail system and downloads all available messages. Optionally, it will delete messages that were successfully retrieved from the system.

Post Office Protocol and Internet Message Access Protocol are designed for different scenarios, and their strengths and weaknesses should be understood before selecting one versus the other.

The POP email protocol does not natively support encryption either of login credentials or the data transmitted. It does not mark downloaded items as having been read nor does it allow for the creation and management of separate email folders.

POP only supports one client application connection per account at a time -- an important limitation. POP won't be useful for something like mobile devices, since users are likely to have a smartphone and a tablet or desktop PC connecting to the same mailbox.

There have been some minor changes to POP email standards over the years. RFC 2195 allows for the use of various secure challenge/response mechanisms such as CRAM-MD5 and SCRAM-SHA-1. RFC 2449 allows for the use of extensions to the protocol, which paved the way for secure socket layer/transport layer security (SSL/TLS) encryption. However, the POP protocol has stagnated since the late 1990s.

IMAP vs. POP as a protocol

IMAP had fundamentally different goals compared to POP. Whereas POP email undergoes a download-and-delete protocol, IMAP email mirrors some of the functionality of existing UNIX mail applications on the client system. This includes tagging messages, moving messages between folders and server-side storage.

Most implementations of IMAP support multiple logons so you can have many different devices connected at the same time. An iPhone and Outlook client could both connect at the same time, for example. The details of how to handle multiple connections are not specified by the protocol but are instead left to the developers of the server-side application with IMAP, versus POP where it is not an option.

The IMAP protocol was eventually updated to support downloading just the message headers with on-demand access to the message body, and built-in encryption, though the latter is mostly replaced by STARTTLS with the late 1990s RFC 2595. STARTTLS upgrades a plain text connection to an SSL or TLS encrypted connection. In addition, RFC 2195 also applied to IMAP to allow secure challenge/response mechanisms.

When to use POP in applications

A number of sources would suggest POP is an inferior protocol in every possible way and it should be avoided. On the contrary, it is still useful for specific applications.

The aforementioned help desk application would be one excellent example for POP versus IMAP, since POP only supports a single logon at once and deletes messages by default. No other program can interfere with the help desk's message downloading, and since the application likely has a back-end database, it won't need to track which messages are read or retrieved.

However, POP, by default, sends credentials and data in an unencrypted, plain-text stream. Verify that your server-side mail application supports either port-specified encryption -- typically port 995 for TLS encryption -- or utilizes STARTTLS to enable encryption on the default port of 110. Never allow credentials to pass unencrypted, even inside your own network.

Use IMAP, unless you're interacting with Exchange

If you have a server-side application processing and discarding messages, consider a POP connection. For most other purposes, IMAP is likely to win the POP vs. IMAP email protocol comparison. It's tempting to suggest using IMAP everywhere where POP is a bad fit, but that does a disservice to Exchange Web Services (EWS) and Messaging Applications Programming Interface (MAPI), Microsoft's proprietary protocols. EWS and MAPI are contenders for any native Microsoft Exchange Server software.

All popular mobile devices and desktop mail clients support IMAP. Users gain the advantage of organizing messages into folders, having multiple client applications know which messages have been read, flagging message for urgency or follow-up and saving draft messages on the server.

IMAP is meant for human interaction -- it's for an actual user's communications, instead of a server-side application that processes and discards messages on arrival. IMAP's primary use case centers entirely around user productivity, and availability of more capable protocols such as EWS or MAPI.

The same rules apply to IMAP as do to POP in regards to encryption. While IMAP does have native encryption capabilities, they are often not enabled by default. The IMAP server must support STARTTLS with appropriate encryption levels for your organization's needs. Maintain a solid cipher suite.

Next Steps

Why is IMAP disabled in Exchange Server?

Exchange 2016 installation requirements

Office 365 migration options

Dig Deeper on Exchange Server setup and troubleshooting