Note (edit): Some people prefer me to call IMAP’s Push-Email “notifications”. That’s fine of course. Just replace “Push” with “notification”.
Everybody who’s into IMAP already knows: IMAP does Push E-mail. Nowadays nearly all IMAP servers are implementing the necessary features for it.
Marketing people wanting to sell their proprietary mail server solution have been claiming that IMAP is not true push e-mail because it doesn’t push the entire E-mail to the client. This is incorrect and just marketing. It’s true that IMAP gives you as a client developer the opportunity to decide to waste bandwidth or not at the cost of one single round trip. Round trips are less important for Push E-mail, as a push event is a background event.
What happens is very simple. In stead of pumping the entire message through, it sends the new total count of your folder. This makes sense, because if you are not interested in push events, you only wasted a few bytes of bandwidth and if subsequent push events happen you get automatically upgraded. Just compare your local number with the new number and make a decision.
C: a IDLE
S: idling+
S: ...
S: * 3 EXISTS
C: DONE
C: a OK
C: b FETCH 3 (ENVELOPE)
S: * 3 FETCH (ENVELOPE ("Tue, 19 May...))
S: b OK
C: c IDLE
S: idling+
We see that we have to exit IDLE to fetch the message’s ENVELOPE. This is why NOTIFY is being introduced. With NOTIFY you simply set at the start of the session what you want the IMAP server to send you during a push event.
If you want it to pump the entire E-mail through, you can instruct it. True push E-mail according to the marketing guys! Nobody really cares about this. though. People with a technical understanding know that you just want to fetch the fields that are interesting and absolutely not the entire mail: that way a spammer could bankrupt you if he knows that you are using expensive GPRS while roaming.
NOTIFY makes the client implementation more simple. You can e.g. request the X-Priority header and/or your company’s custom header. “X-Came-From The-Boss: Yes”. Based on that info you can choose to make the phone perform certain actions.
C: a notify set (selected MessageNew (uid
body.peek[header.fields (from to subject)]) (all)
MessageExpunge) (subtree Lists MessageNew (uid) (all))
S: ...
S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)] {75}
S: Subject: Re: good morning
S: From: alice@example.org
S: To: bob@example.org
S:
S: )
S: ...
GPRS and IDLE or NOTIFY are fine by itself too. When we wait long enough in the select(), most GPRS chips will automatically go into low power mode. This way you can wait up to 30 minutes before an IMAP server thinks that you got disconnected. Such very high timeout times are specified for e.g. mobile purposes and high latency situations (IMAP from Mars!). Misconfigured NAT gateways that make timeout decisions more early are a problem. The biggest problem is that there’s no way to find out what the timeout for a session at the NAT is.
IMAP as a protocol makes it possible to process alien Push events too. Most IMAP servers, including Cyrus, provide a small daemon that handles the pushing. Cyrus, for example, has “idled” for this purpose. Very often you can quickly make a plugin for the IMAP server such as converting the IDLE event to an SMS and sending it to the user’s phone.
Just remember that with a good GPRS chip with correct power management, this ain’t really needed
If you are a phone builder and you are integrating a GPRS, UMTS or EDGE chip, I recommend getting the power management of it right. In the future your users will stay connected with the IMAP server: the timeout for the NOOP can be high. I hope the people who maintain the NAT gateways of GPRS, UMTS and EDGE at the many mobile networks will consider such use cases in stead of closing sessions at extremely small timeouts.
Tinymail does Push E-mail with IMAP :-)
