[SirCastor]

There are lots of threads which deal with Push email, but I didn't see anything about why this is so important. (Maybe if I'd read through all of them I would have found such a discussion, but I was lazy)

The way email works is like this:
Your friend writes an email and presses the send button
Your friends computer handshakes with his mailserver, gets the message.
That mailserver handshakes with your mailserver, and gives the message.
Your computer (either by command or schedule) routinely talks to your mail server and gets the message.

The only difference between push email and regular email is the last bit. In push email the email server has the ability to contact your computer when it gets a message and do the hand off. That's it!

The entire industry pushes (no pun intended) this technology as some kind of miracle, when it's not a far cry from having your client check the server every minute (which is really excessive BTW). What's the point. If you need someone to know something immediately, then you call them. If you want to send email, then 5 minutes is not a big deal...

[nonhuman]

I believe it ends up saving battery life because your phone/device doesn't have to use it's transmitter (a relatively big power drain) every X minutes even if there's no reason for it to do so. It will only actually connect to the server when it needs to. So unless you get a really large volume of email (or don't have good server-side spam filtering... does MobileMe provide that?) you spend less time pumping electrons from your battery into the air.

Other than that, I completely agree with you. It's relatively pointless.

[SirCastor]

That makes a good deal of sense.

[besson3c]

The other so-called advantage is the ability to basically have real-time conversations with people over email, for when everything works as it should.

[Uncle Doof]

What's so great about push email?

Well, the suckers out there will decide they need it and they'll upgrade all their gear/ware to cope, thus continuing the never-ending transfer of cash from sucker to tech vendor.

Don't mind me. I still reckon that everyone who wants email should have their own SMTP server in their house.

[Don Pickett]

Originally Posted by besson3c 

The other so-called advantage is the ability to basically have real-time conversations with people over email, for when everything works as it should.

Removes one of the primary advantages of email: keeping away from people I don't want to talk to.

[TETENAL]

You don't have to reply to an e-mail regardless of whether it is delivered immediately or in 5 minute intervals.

[Don Pickett]

Originally Posted by TETENAL 

You don't have to reply to an e-mail regardless of whether it is delivered immediately or in 5 minute intervals.

Obviously. But if it's known you have push email it removes an excuse to blow people off.

[Steve Bosell]

Not having "push" email sucks because: At my work I use a blackberry, however we do not have the exchange "push" component, so emails are just forwarded from my work email to the blackberry. If I get an important email, and I am not at my desk, I reply to it using the Blackberry, then the emails go back and forth using the blackberry's email address. In a couple of weeks when I need to go back to refer to that email, I am screwed because only the original email is in my inbox at my desk, the rest of the conversation is only on the blackberry.

[BRussell]

Originally Posted by nonhuman 

I believe it ends up saving battery life because your phone/device doesn't have to use it's transmitter (a relatively big power drain) every X minutes even if there's no reason for it to do so. It will only actually connect to the server when it needs to. So unless you get a really large volume of email (or don't have good server-side spam filtering... does MobileMe provide that?) you spend less time pumping electrons from your battery into the air.

Is that true? Something has to be monitoring for the push, doesn't it? I was wondering about it because my battery life seems to have gone down after installing 2.0 and using both exchange and mobileme push. But the battery drain could be from something else (like playing all those games).

I've turned off both exchange and mobileme push. I just don't need to know about emails that fast.

[BRussell]

Originally Posted by Steve Bosell 

Not having "push" email sucks because: At my work I use a blackberry, however we do not have the exchange "push" component, so emails are just forwarded from my work email to the blackberry. If I get an important email, and I am not at my desk, I reply to it using the Blackberry, then the emails go back and forth using the blackberry's email address. In a couple of weeks when I need to go back to refer to that email, I am screwed because only the original email is in my inbox at my desk, the rest of the conversation is only on the blackberry.

Is that a pushing issue, or just a syncing/leave-messages-on-server issue?

[besson3c]

Originally Posted by Steve Bosell 

Not having "push" email sucks because: At my work I use a blackberry, however we do not have the exchange "push" component, so emails are just forwarded from my work email to the blackberry. If I get an important email, and I am not at my desk, I reply to it using the Blackberry, then the emails go back and forth using the blackberry's email address. In a couple of weeks when I need to go back to refer to that email, I am screwed because only the original email is in my inbox at my desk, the rest of the conversation is only on the blackberry.

How does having push solve this? It sounds like your problem is that your Blackberry is not setup to access your work email account?

[analogika]

Originally Posted by SirCastor 

The way email works is like this:
Your friend writes an email and presses the send button
Your friends computer handshakes with his mailserver, gets the message.
That mailserver handshakes with your mailserver, and gives the message.
Your computer (either by command or schedule) routinely talks to your mail server and gets the message.

Hint: "Push" e-mail wasn't invented for the e-mails "your friend" writes.

It was invented for urgent business matters, where, for example, stuff often gets delegated on a "first come, first serve" basis, and not missing an opportunity can mean (in my case) a week's worth of groceries paid for.

[Jawbone54]

Originally Posted by analogika 

Hint: "Push" e-mail wasn't invented for the e-mails "your friend" writes.

It was invented for urgent business matters, where, for example, stuff often gets delegated on a "first come, first serve" basis, and not missing an opportunity can mean (in my case) a week's worth of groceries paid for.

[besson3c]

I'm really starting to think that the way push email is marketed and thought of is purely a gimmick. I would wager a guess that your average Joe sees push email as a way to get email on their mobile device easier and faster, but I have a hard time understanding why a sizable population would need this? Maybe this is sort of a "flashy and shiny, gotta have it!" sort of deal? The kinds of guys that feel they need to have the latest toys and gadgets just because?

[mduell]

The other two steps (sender->sender server, sender server->your server) are push, so why shouldn't the last step (your server->.your client) be push?

I like push email because it's fast, easy, and multiplatform. You can't (easily) send an sms from a command line unix app or to a desktop computer.

[besson3c]

Originally Posted by mduell 

The other two steps (sender->sender server, sender server->your server) are push, so why shouldn't the last step (your server->.your client) be push?

Because most client computers do not exist at a static IP. Therefore, some sort of mapping and queuing mechanism is needed, which just adds more complexity.

I like push email because it's fast, easy, and multiplatform. You can't (easily) send an sms from a command line unix app or to a desktop computer.

mail -s "your subject" [email protected]

[mduell]

Originally Posted by besson3c 

Because most client computers do not exist at a static IP. Therefore, some sort of mapping and queuing mechanism is needed, which just adds more complexity.

All they need to do is check-in and sit there... perhaps we could call that IDLEing.

Originally Posted by besson3c 

mail -s "your subject" [email protected]

Not as good as push email from a security point of view (messages pass unencrypted on servers out of your control), maintainability (have to keep track of the email<->sms mapping for multiple providers), and availability (have to rely on someone else to keep another server up).

[besson3c]

Originally Posted by mduell 

All they need to do is check-in and sit there... perhaps we could call that IDLEing..

Not as good as push email from a security point of view (messages pass unencrypted on servers out of your control), maintainability (have to keep track of the email<->sms mapping for multiple providers), and availability (have to rely on someone else to keep another server up).

I just tossed in that Unix command for fun, but I'm not really sure how what you are saying relates.

So, if all a client has to do is login and idle, how are notifications sent to the idling connections? I think this is the black hole right now... Different IMAP servers handle delivering messages from SMTP to the mail store differently - Cyrus IMAP uses LMTP, Courier IMAP uses Maildrop (I think) and FAM for notification, and Exchange uses the Blackberry plug thing for use with Blackberry devices. Notifications are not a part of the SMTP spec, nor are they a part of the IMAP spec.

So, how do we solve this? Well, somebody can devise another protocol and pressure the developers of the various IMAP/Groupware servers to write this, but getting buy-in might be difficult, especially from Microsoft. On the client end, support is needed there to trigger a download of that particular message being notified. In a sense, the idea of "push" is a bit misleading, as obviously the IMAP server is not going to reach inside the client somehow and physically download and cache the message, it is simply going to tell the client that there is a new message awaiting download.

I like the idea of push as well, but I think that some of these challenges are why we are coming up with fragmented and proprietary solutions like the MobileMe/iPhone thing, Exchange/Blackberry, etc. What we really need is some momentum being put towards a new notification protocol.

[mduell]

IMAP IDLE leaves a socket open; when the server gets mail, it shoves some bits into that open connection.

I understand sending mail from the cli; I do it a lot. But email to sms gateways have all the problems I described. As well as limited message length.

[besson3c]

Originally Posted by mduell 

IMAP IDLE leaves a socket open; when the server gets mail, it shoves some bits into that open connection.

But how is the message actually delivered to that user's message store?

[mduell]

The same way any other message is delivered... I don't understand why you're concerned about that.

[besson3c]

Originally Posted by mduell 

The same way any other message is delivered... I don't understand why you're concerned about that.

There could be gaps in my understanding, but here is the problem as I see it...

It's not enough to simply support IMAP IDLE, because that is already prevalent across both servers and clients. All IDLE offers is the ability to stay in direct contact with the servers. Because push has not hit critical mass yet, most clients poll the IMAP server every x number of minutes. In the future, IMAP servers will push email to the user's mailbox, but in order to do that they need to send some sort of signal to the IMAP client to retrieve the message when one is available.

In order to deliver a message, a delivery protocol is needed. With Cyrus IMAP this protocol is LMTP, with Courier IMAP it is Maildrop. All this piece does is simply take a message from the MTA and drop it in the user's mailbox for them to access whenever they next access their email. This works differently for each IMAP server, and I don't see any way around that given that mail stores are utilized on a variety of file systems, directory paths, mailbox and database formats, etc. This has to be controlled by the IMAP server. Once the message is in the user's mailbox, the client has to retrieve it to add it to your message listing, as well as cache it for offline viewing if your client is setup accordingly.

So, the problem is that this delivery process has to entail more than simply dropping a message into the user's mailbox and waiting for the client to notice it. It needs to entail some sort of notification to the client so that it knows to grab this new message. AFAIK, there is no open format or spec for this.

If I understand the Blackberry model correctly, the Blackberry server is basically a piece that works in tandem with Exchange to do exactly this. That is, this piece notifies each connected BLackberry that a new message is available. What we need is this same sort of thing, but something that will work with all IMAP server and all clients.

Does this make sense?

Originally Posted by analogika 

Hint: "Push" e-mail wasn't invented for the e-mails "your friend" writes.

It was invented for urgent business matters, where, for example, stuff often gets delegated on a "first come, first serve" basis, and not missing an opportunity can mean (in my case) a week's worth of groceries paid for.

So, if all of your coworkers have push email too, then you are no better off. Isn't it that much more stressful as you race to reply to the email? What if you are driving somewhere? Next you'll need a technology that can read the email as it's being typed. It's like a mini arms race for email.

I guess, like a lot of technology, it doesn't solve a problem, it just makes you work that much more.

[moonmonkey]

Originally Posted by Don Pickett 

Obviously. But if it's known you have push email it removes an excuse to blow people off.

Excuse me?