- Unsupervised Learning
- Posts
- The IMAP IDLE Command
The IMAP IDLE Command
With the recent launch of the iPhone there’s been renewed interest in so-called “push” email technology. “Push” means that when an email message arrives in your mailbox on the server, it is by one method or another replicated to your client, e.g. your desktop email application or mobile device.
Definitions
Let’s start by addressing our definition of “push”. I’m not sure there is a *true* definition of this, as it’s more of a concept than a hard technical standard. As such, I’ll offer my own thoughts on the matter:
What IDLE Isn’t
IDLE is not — according to my definition above — a true push technology. IDLE requires an active IMAP connection in order to work, and that connection cannot be initiated by the server.
Client connects to IMAP server and verifies that the server supports the IDLE command.
If the client also supports it, the client sends the IDLE command to the server.
Having received the IDLE command from the client, the server is now able to “push” messages down the existing connection to the client, as they come in.
In other words, IDLE’s push functionality only works when an existing, healthy connection already exists between the client and server. Anything that disrupts that connection kills the ability for the server to send messages down to the client. And only the client can re-initiate the connection once it has broken.
From the IDLE RFC:
Conclusion
This isn’t to say that IDLE isn’t useful; it clearly is — especially for receiving emails more immediately on stable network connections. But in a mobile device environment it’s often difficult to maintain the requisite and relatively delicate IMAP connections over long periods of time. This will continue to be a challenge for mobile email providers not using more robust server-to-client delivery methods like those available from RIM and Microsoft.:
—The IDLE RFChttp://www.ietf.org/rfc/rfc2177.txt
[ July 2007 ]