Re: Need email server aid

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'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.

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.

/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.

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

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.