Email Push Service :) smtp+dnotify+Asterisk+... :)

Elliot F. elliotf-openmoko-discuss at
Wed Jan 31 08:42:23 CET 2007

Andreas Kostyrka wrote:
> * Elliot F. <elliotf-openmoko-discuss at> [070131 03:45]:
>> Or you could simply modify the mail server to trigger a script when a message is delivered, rather than having to poll each directory/file.  A procmail/maildrop filter would be one way 
>> to implement it easily (allowing you to filter for messages from specific people, to certain folders, etc.)
> With the specific problem that you have nowhere to push to. Normal
> GPRS has to live with a strict NAT firewall. That's (and because of
> billing aspects) probably why pushmailservices usually have their own
> APN.

My point was that the mail server (MDA, as I was suggesting with 
procmail) would trigger the event that notifies the phone client that a 
new message arrived.  I wasn't suggesting that the server is going to 
connect to port 1025 on the phone and deliver via SMTP.  :)  The client 
would be notified and pull any new messages.

>> I really like this idea.  As I understood it, many previous "push email" services relied on sending an SMS message to the phone, which made the phone perform the actions that you 
>> describe (get new mail.)  However, hooking in directly to the incoming call would save the money that SMS messages cost.
> Nope, real push mail is just that. It just needs support from the
> network. Or a special low bandwidth protocol to poll.
> E.g. one of the highest prices mentioned here was 1KB at 3cent (CDN).
> Still, one could design a protocol that sends one "I'm alive byte" say
> 30 minutes, and listens all the time for an "you've got mail byte".

Don't forget protocol overhead.  UDP header alone is 8 bytes, plus IP 
header, and it doesn't get much more lightweight than that.  Of course, 
you won't know if the packet actually made it to the destination.  :)

> That would mean, a standby cost of 1KB every 20 days. That's assumming
> a keep alive is needed every 30 minutes. Guess it would make sense to
> support an additional mode where (for the home network) the phone
> senses the right standby before the NAT firewall kills our TCP
> connection. (But that should be manual, because the reconnects needed
> during probing will use up some KB)

Why bother polling at all?  You would be repeatedly starting up or 
maintaining a data connection when there may/may not be a need.  I'm not 
sure, but I would assume it would also use more power while maintaining 
the connection (due to the radio.)  Why not use some sort of method to 
notify the client when there is a message (via SMS or call from a known 

>> I'd be interested in seeing/hearing what hooks/services will be exposed.  Will the incoming calls trigger a dbus message or something similar?
>>> 5. skript2 will switch on GPRS and fetch the new
>>>   mail via POP or IMAP
>>>   and after downloading the mail it will inform
>>>   the user (depend on the dailingprofil)
>>> So did I missed something? Why is push services
>>> and the software for this such a hype?
> Yeah, the original poster missed the fact, that in most billing plans
> switching off GPRS is expensive. E.g. GPRS is billed usually in blocks
> of 10/100KB (this applies btw also to xMB included plans in Austria).
> So switching off GPRS while you've fetched a 2KB email is plain stupid.

There's no reason to be insulting.  Please try to be respectful and 
educate rather than insult.  Besides, I don't think turning on GPRS 
and/or leaving it on to poll is any better.  You're wasting battery life 
and data with maintaining a persistent connection/polling.  Also, I 
believe that voice calls cannot be received when a data connection is 
active.  Please correct me if I'm wrong.

Getting a call from a known number and not having the phone ring is free 
in most places.  It's free, doesn't take much battery life, and doesn't 
spend data by polling.  That is the best part of Robert's idea.

>> Because it's very handy, and very well integrated.  Blackberry and Windows Mobile (or whatever it's called) have the pieces at both ends that are required for the integration.
> Yeah, and the support of the network providers ;)

Which isn't strictly necessary.

More information about the community mailing list