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.
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:
The server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout it MAY log the client off implicitly at the end of its timeout period. Because of that, clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off.
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 RFC
[ July 2007 ]