Need email server aid

Christopher Chan christopher.chan at bradbury.edu.hk
Mon Apr 26 00:38:51 UTC 2010


On Monday, April 26, 2010 02:25 AM, Alvin Thompson wrote:
> On 04/25/2010 07:38 AM, Chan Chung Hang Christopher wrote:
>> I doubt that using smtp, however secured, for auto configuration or
>> whatever automatic stuff is a good idea.
>
> You use it to automatically receive email, don't you?  I imagine even
> the important ones...

I wonder how much pain was caused when the mail system of a company went 
down for a day (pretty normal if you ask me...like this huge European 
textile conglomerate called Oerlikon that runs Exchange) since my 
important emails are probably not quite the same level as those for 
accountants, executives and sales personnel.


>
> I've been a paid software engineer for 20 years, and  people use SMTP
> for this role all the time.  Talk about a track record--SMTP reliably
> transports BILLIONS of messages PER DAY.  It has been honed for that
> purpose for over 20 years.  It's the most vetted software on the planet.
>    You can even use SMTP instead of HTTP as the transport for servlets,
> JSP pages and web services.  It's just like HTTP in this role except,
> you know, it's reliable.

I worked for Outblaze Ltd. (now Lotus Live) and I ran the mail system 
there. I know how reliable mail delivery can be. I don't know what Chuck 
is building, but if it is a decentralized intelligent access point 
system he is building, I doubt that smtp would be something he wants to 
use for access point autoconfiguration (like when a neighbour dies and 
it is therefore time to use another route) and communication.


>
> If you've ever used that thingy they call the World Wide Web, you've
> sometimes clicked in a link and nothing happened, or the page didn't
> fully load.  Then you either had to click the link again and/or reload
> the page.  That's because HTTP is unreliable and sometimes the signal
> doesn't get through.  When was the last time you sent an email that was
> properly addressed, wasn't detected as spam, and the email system was
> properly configured, that didn't get through?  In fact, I'm willing to
> bet you a gazillion dollars that this message will indeed make it to the
> mailing list, and when the mailing list sends this email out to all of
> it's subscribers, all of them, including you, will get it.  Assuming
> their systems are properly configured.

Assuming there are no queues due to a bounce flood, due to spam clogging 
the queues and a host of other possible impediments, you expect 40 
different mx/host records to be setup for a roll out involving 40 of 
Chuck's access point?


>
> I can't believe Thunderbird's spell checker knows the word "gazillion".
>
>> /me stares at list of various protocols, proprietary and open, used for
>> router/switch/access-point configuration/communication.
>>
>> Hmm, none of them chose to use an existing protocol like smtp with its
>> email parsing overhead.
>
> That argument subverts the point you were just trying to make.  The
> configuration of the devices you just mentioned is meant to be done
> MANUALLY--not automatically--, by a human in real time.  So the human
> takes on the task of verifying the message was sent.  For example, when
> he sees the "Changes Saved" screen.

Oh really? I have 49 wireless access points that I manage here and you 
bet that I do not manually configure each one. If I was told that they 
would be managed over smtp, I would start looking elsewhere for a 
wireless solution.

BTW, switches are not always configured manually too. They can be 
configured automatically without any need to hook up a serial cable.

>
> Overhead, BTW, had nothing to do with it.  Unless you expect people to
> be reconfiguring their system millions of times per day.

Did you miss the part about communication? How are you doing neighbour! 
I am fine thanks! All over email? Hahahahahhahaha.


>
>> Reliability of smtp? I suppose if delays of five days or a day are
>> tolerated or not at all....
>
> You're proving MY point with that one.  That shows that SMTP will not
> stop until it sends the message, even if it takes 5 days.  HTTP would
> have long since given up.  In fact, you can configure SMTP to NEVER stop
> until it gets the job done, or until it dies trying.  Just like Arnold
> in that movie.
>
> If there are no problems with the connection and SMTP is configured for
> speed, it will generally take in the order of milliseconds to send a
> message to its destination.
>

I am sure that wireless access points would love smtp for remote 
control. I am sure that they will eventually be able to restore any 
connectivity problems they have and carry out the latest commands 
arriving via email and therefore make an http interface moot.




More information about the ubuntu-users mailing list