Need email server aid

[Alvin Thompson]

Dude, stop it! Now you're just using smokescreens, contrived examples, 
and specious arguments to avoid conceding the point. At least in the 
other emails you were trying to prove your case, even if your case was 
flawed, but this post was pure tripe. Stop wasting people's time with 
this nonsense. The only reason I'm rebutting the ridiculous non-logic in 
your last post (below) is that I don't want other people thinking this 
garbage is valid information, just because your pride prevents you from 
admitting you spoke too soon.

On 04/25/2010 08:38 PM, Christopher Chan wrote:
> 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.

That's specious. A company's HTTP server could just as easily go down. 
Or their DNS server. Or their electricity.

In reality, you're proving MY point with this. If a company's SMTP 
server goes down, all new messages will go to the backup server. When 
the company's SMTP server goes online again, the messages will be 
delivered safe and sound. Even without a backup server, the sender's 
SMTP server will queue the message and retry it for days. End result: 
Godzilla could come along and step on the building with your mail 
server, and you won't lose a single message. If your HTTP server goes 
down, you're screwed.

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

A "decentralized intelligent access point"? Now you're just trying to 
come up with a mythical, contrived example to make your points seem more 
credible. Here's a news flash: since Chuck started this thread with the 
subject "need email server aid", and asked about sending messages from 
the embedded device he's building, chances are he's building a device 
that (among other things presumably) SENDS MESSAGES".

> 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?

Wow. Only a few words but so many conceptual errors. Where to begin?

1. As far as bounce floods are concerned, it's generally accepted that 
it's easier to mount a DOS attack on an HTTP server (and practically 
every other type of server) than SMTP. That's because SMTP has only one 
purpose: to send messages reliably. As a result, its protocol is very 
strict and well-defined (if a bit complex). Also, you'd have to mount a 
DOS attack on all backup servers as well, and somehow prevent the 
sender's mail server from queuing the message.

2. SMTP servers have multiple queues. The "active" queue is for messages 
scheduled to be delivered. If a message can't be delivered, it gets 
removed from the "active" queue and placed in the "deferred" queue. That 
way, a flood of "bounces", as you call them, can't fill up the "active" 
queue and prevent legitimate messages from getting through. Did you 
really think you were the first person ever to think of that?

3. We've already established that every client that connects to Chuck's 
mail server should present a valid certificate. So where are all those 
spam emails and bounces (enough to clog up this "single" queue) coming from?

4. Even if Chuck were NOT to use certificates, he could easily configure 
his SMTP servers to use a port other than the standard port 25.  Do you 
really think spammers are going to take the time to try every port? Even 
if they did, unless they were lucky, the spammers would be blocked for 
port scanning before they found it.

5. Even if Chuck were NOT to use certificates, AND if he used the 
standard port, he could easily reject mail that didn't adhere to a 
specific syntax.

6. Even if Chuck were NOT to use certificates, AND if he used the 
standard port, AND he didn't reject mail based on syntax, the server 
would only accept mail sent to a proper destination address. What's to 
stop him from using destination addresses like 
"embedded_device_ZX124959734W at my.server.com"?  I'm guessing that address 
might be hard to guess by a spammer.

7. Even if Chuck were NOT to use certificates, AND if he used the 
standard port, AND he didn't reject mail based on syntax, AND he for 
some reason accepted mail sent to any address, he could use SPF entries 
in DNS to allow only legitimate senders.

8. Even if Chuck were NOT to use certificates, AND if he used the 
standard port, AND he didn't reject mail based on syntax, AND he for 
some reason accepted mail sent to any address, AND he didn't use SPF 
entries in DNS to allow only legitimate senders, he could use 
"greylisting" to avoid spam. 99% of all spammers won't wait even a 
single second to send a mail to a particular server. Either it works the 
first time or they go on to the next address.

9. Why on earth would Chuck need to add MX entries for each device? MX 
entries are only for mail destinations. The devices don't ACCEPT mail, 
they SEND it. If you want to send mail from one device to another, have 
the devices get mail addressed to them from the mail server via IMAP or POP.

10. Once again, you arbitrarily posited that Chuck's device might be an 
access point because you thought it would help prove your case. Don't 
pretend that's what it actually is here.

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

Once again, you arbitrarily posited that Chuck's device might be an 
access point because you thought it would help prove your case. Don't 
pretend that's what it actually is here.

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

What on earth are you talking about?  Please try to make sense when you 
write things.

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

Once again, you arbitrarily posited that Chuck's device might be an 
access point because you thought it would help prove your case. Don't 
pretend that's what it actually is here.