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

David Ford david at blue-labs.org
Wed Jan 31 20:52:57 CET 2007


Elliot Foster wrote:
> David Ford wrote:
>> It's a great idea, never thought otherwise.  My comment should be
>> taken to mean, don't reinvent the wheel, take the existing wheel,
>> sand it down like new, and refinish it so it's all bright and shiny
>> again.
>
> What if we want a wheel with rubber, rather than just bare wood?
> Besides, there is plenty of stuff that can be reused. 
> Procmail/maildrop would be the most obvious.  The mail server won't
> change (other than the MDA,) asterisk would work well (as Robert
> pointed out,) and we are going to need some new software on the client
> side no matter what.  I'm just talking about the glue between the mail
> server and asterisk.

Procmail doesn't need modified.  All you have to do today is enable
COMSAT=yes in your procmailrc then tell your biff how to do the
notification.  Comsat is the network's message notification service,
biff is the handler mechanism.

example procmailrc,

:0
* ^TO_ david at blue-labs.org
{
   COMSAT=yes
   ...other stuff
}

This is a procmailrc solution w/ biff, but not everyone runs procmail so
a broad MDA solution is wanted as well.  Ideally the end solution should
be agnostic from the handheld's point of view.  We want the handheld to
be able to have a [x] Use SMS for new mail notification, i.e. PUSH
email, and not worry about configuring the server to support it.

Otherwise this is a hackers only solution and useless for everyone
except us. We need to support the protocol that exchange uses since that
is very common as well.  Not have an option for every type of pushed
solution available.

Ideally the procmail/comsat/biff solution would result in an SMS
notification in the same format as is already implemented for other
phones w/ i.e. exchange.

> That's exactly what I was saying (notify the handheld of new mail.)  I
> agree about the reuse of existing solutions, but I don't know of a
> single mail server that supports biff/comsat, so I don't think that it
> would be very useful to 're-awaken' comsat/biff.  We would still need
> to modify some portion of the mail server (procmail) in order to
> notify comsat/biff.  I'm assuming all comsat/biff would do is trigger
> the notification to the handheld, so why not do that directly?
>
> In general, there's no server to patch, just a script that would be
> dropped into procmail/maildrop or whatever your MDA is.

Sendmail doesn't do comsat internally, it relies on the external MDA/LDA
to accomplish it.  Postfix comes with comsat service.  Qmail naturally
is in it's own little world of how things should be done and considers
comsat an abomination, but there still exists qbiff.

>
>> This is what "push" email does w/ exchange when you configure your
>> phone to ask for SMS for email notification.
>
> Right, I said that in my email.  I agree with you in how it
> could/should be done, but I don't think it would be very useful to use
> biff/comsat, as they would be an unnecessary middleman.  I think it
> would be cleaner to just have a script that someone can drop into
> their MDA to trigger a pull from the client.  Like I said in my
> previous email, it seems the best place to do it, because then they
> can filter for specific emails. I don't know if I would want my phone
> being woken up by every mailing list email that I get, for example.
>

Filtering is obviously and definitely good, but the script is just a
rewrite for what already exists and is already supported and means that
multiple means of notification are already possible.

It is debatable whether the phone should be capable of filtering
notifications and choosing it's reaction, or being dumb and always
reacting to notifications.  Personally I think that is akin to a profile
just like when to respond to an incoming call.

In the end, I would rather have an MDA agnostic solution that uses an
already developed protocol for new message notification where the phone
controls whether SMS notifies are used or not.  I.e. SMS push notifies
registered with exchange.  If we develop hacker only solutions, the
phone will remain a hacker only product and just won't penetrate outside
the community.

I want a phone that a hacker is drooling over and a phone that is
entirely feature functional for my secretary that -I- don't have to muck
around on the backend to make everything work.  That's an enterprise
support nightmare.

Right now Win phones and some Palm phones already have the option to
enable new mail notifications by SMS.  It's rapidly being adopted in
smart phones.  I sincerely think it's a good idea to incorporate what is
already supported as well as all of our make-me-happy stuff with our
server stuff that we control like procmail, and it should be as
invisible to the end user interface as possible.  What we do under the
hood is up to us.  What we do in front of the user needs to be clean and
functional and as agnostic as possible.

:)

-david

p.s. please don't CC me - i'm subscribed to both lists :)




More information about the community mailing list