IMAP4 : The mobile application protocol we didn’t know we had


IMAP4 (Internet Mail Access Protocol) is a little discussed but widely used protocol for accessing and managing email. As it turns out, IMAP is also a great way to deliver information to mobile applications, by repurposing mobile IMAP clients for use in a wide range of mobile applications. While this is a bit of a hack, since we’re using a protocol designed for one purpose for an unintended use, it solves several problems that plague mobile applications.

IMAP is designed to do one thing and do it well — deliver email despite the intermittent connections that were prevalent when it was developed. For that reason is baked into nearly every email client and mobile device. Email delivery is also one of the most thoroughly tested services on mobile devices, and is designed to operate as an always on, background service.

IMAP was designed at a time when mobile Internet apps did not exist, and when most Internet connections were dialup connections. As with mobile apps running on cellular networks, email clients of the time needed to make best use of the intermittent connection they had. Without going into too much detail, IMAP splits accessing an email account into several tasks:

  1. Logging in and retrieving a list of folders (inbox, outbox, etc)
  2. Retrieving a summary of messages within a folder, but not the messages themselves
  3. Retrieving an individual message and/or attachments

This approach enables the mail client to quickly find out what’s in a mailbox, and then retrieve the messages needed, without retransmitting information that is not needed or that has been sent before. This maps nicely to what many mobile apps do, and can be optimized in the same way.

In this paradigm, an information service presents an IMAP interface that email clients can connect to. Let’s use an upcoming event notification service as an example, and walk through the steps an IMAP client would use to display continuously updated event information tied to your current location. The client would go through the following steps:

  1. Login with the user’s credentials, request a list of folders. The server replies with a list of folders such as “San Francisco : Mission”, “San Francisco : Civic Center”, and so on.
  2. The client subscribes to some of all of these folders, and fetches a list of message headers. The message headers contain basic information about upcoming events. IMAP’s server side search function will also be a useful way to fetch customized result sets.
  3. The client fetches message bodies and attachments in the background, or when the
    user opens an item, depending on how the email client is configured.
  4. When the user opens a message, he or she sees an HTML formatted email, with links,
    attachments, etc all preloaded, so there is usually no visible network delay because most of the message was preloaded in the background.

Why give IMAP a try?

Of course, you can do all of this with a native application that calls a web service in the background and selectively loads and caches information ahead of time. The problem is that it requires much more work on the part of the developer, and on some mobile platforms, background processes are tricky to manage (e.g. they’ll be shut down by the mobile OS to conserve memory or battery power), whereas using IMAP, one can simply subscribe to additional IMAP email account for the services the user is following. Most mobile email clients also notify the user of new or unread messages, and provide a simple notification mechanism, another bonus. Meanwhile, the service provider can track which users have read which messages, news items, etc.

Another advantage of using IMAP as a transport protocol, and using a built in IMAP agent on the phone, is it is already there, and is one of the core services on mobile devices. Your web app can behave like just another IMAP inbox the device can subscribe to, so it will be synced along with other mail accounts. Likewise, your users can subscribe using their phone’s built in mail client, or you can “skin” an existing client for look and feel, without forcing your developers to build the whole thing from scratch.

The missing piece.

Most of the pieces needed to do this are already available. The protocol is widely used and is built into nearly every mail app in some form. Only one piece is not widely available, an IMAP2HTTP utility that presents an IMAP interface to mobile apps, while communicating with an upstream web service via RESTful HTTP queries that are easy for web app developers to deal with.

Jesse Vincent’s Perl library, NET::IMAP::SERVER, enables web apps to serve data as IMAP mailboxes. In addition to libraries for popular programming languages, there is an opportunity for mobile development tools vendors, such as Titanium and PhoneGap to host IMAP-to-HTTP gateways that provide a solution for web app developers, much like the SMTP2WEB service enables web apps to process email. (Hint: it would also be nice if Google provided a similar handler for App Engine, much as it has done for inbound email processing and XMPP/Jabber messaging).

IMAP will primarily be useful for applications that continuously retrieve information, such as news readers, background search tools, and similar applications that can present information as a set of items in folders. It is a bit of a hack, but it’s a useful hack that can improve the user experience for many mobile applications. It won’t replace native apps, but will provide developers with a fast and inexpensive way to provide mobile access, and then make a decision about whether to invest in native apps further on in the product development cycle.

Brian McConnell is an entrepreneur, and the founder of the Worldwide Lexicon, an open source translation platform. Prior to founding WWL, he founded several telecom and mobile startups (where the balkanization of the mobile software industry was one of his biggest pet peeves).


Waseem Sadiq

As developer of an email client > (which makes extensive use of IMAP4) I think this is a very bad idea. If anything we should be moving *away* from IMAP and not towards it.

1. IMAP was invented like 20 years ago and is very complex to parse and get right.
2. IMAP uses raw tcp communication without any form of cachability or compressability (bad for the mobile bandwidth bill), not to mention firewalls and proxies.
3. IMAP clients and servers are insanely incompatible (sometimes even stuff from the same vendor).

I would actually suggest going the other way around and moving (mobile) email clients to a http/rest based protocol which is much simpler, cleaner and faster.



Except IMAP doesn’t do even email well. It completely misses the point on sync and requires a massive download of information that shouldn’t be required because of it’s use of sequential ints that are folder specific instead of GUIDs or at least non folder specific ints. The average IMAP implementation uses about 500% more data than the same thing done with Microsoft’s ActiveSync, and ActiveSync still isn’t great because Exchange doesn’t have a true global GUID or similar for an email message.

What we need is someone to recognize that for proper sync to occur every item must have a GUID AND a modified date (timestamp would also work) By doing so, we can get everything that changed since the last time we looked, match it up to what we already have with 100% certainty and only get what actually changed on those items.

Bruno Morency

Hi Brian,

I would love to take a few minutes with you to chat about our HTTP API that abstracts most the tricky parts of IMAP and much more:

Comments are closed.