On Tuesday, April 27, 2010 04:15 AM, Alvin Thompson wrote:
> 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.
Yawn. Show me a wireless product on that market that uses smtp for
remote control.
>
> 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.
Actually, these guys were just incompetent. They gave me a lot of
amusement. From a botched migration from Exchange 5.5 to Exchange 2003
to their fantastic spam/anti-virus filtering system that clogs mailboxes
with hundreds of spams daily. Glad I was just a nobody in a tiny office
in HK that their IT team views as insignificant. Pretty much destressed
me from my days in Outblaze fighting spammers and scammers.
>
> 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.
Did you ever imagine emails being misrouted? That's what happened at
Oerlikon. All the redundancy in the world will not solve incompetent
admins. Nice to rely on somebody else to deliver your remote commands eh?
>
>> 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".
News flash: He already has a sending solution. Why are you changing the
point of this part of the thread? It has long gone from how to send
email to whether it was a good idea to have a mta installed in the
embedded device for the purpose of receiving commands via email. His
initial need for email server aid was for help on his problem of
receiving email from the embedded device, not for help on receiving
email for accepting remote commands.
>
>> 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.
Hahaha. If one really wants to mount a DOS attack on smtp servers, they
would just as easily be affected by the same methods as any other
service. Tying up all available connections will work on any service.
Likewise, the counter to that will work for any service too. The SMTP
protocol has nothing special about it that makes it somehow less
susceptible to a determined DOS attack. The bounce floods and other
stuff I mentioned are, for some, regular occurrences that are not
necessarily due to a determined and willful DOS attack.
>
> 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?
You are just talking about the characteristics of postfix's physical
queue management. What you described is not true for qmail or sendmail.
>
> 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?
I think I know why this whole thread has gone off the rocks. You are
thinking about his Ubuntu box running an MTA. I am talking about his
consideration of using email for remote control of his embedded wireless
device.
>
> 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.
Well, not running on port 25 will defeat the entire purpose of using
email to deliver remote commands to the embedded device unless an mta
somewhere was specifically setup to route appropriately. Why give the
user so much work when just presenting a http interface would be so much
easier for them and relatively have less to worry about with regards to
security?
>
> 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.
Well, if someone wanted to gain control of the thing, they would
probably know what to put in the email no?
>
> 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.
Oh sure. Hopefully, if this is for the home, the user has clue enough to
do what is needed and correctly. But again, that email address implies a
central mta that will route the mails to the right device. I must thank
you for bring up more examples of how much more complex things can get
to have a system setup that uses smtp for remote control/communication.
>
> 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.
I am sure admins would love to setup the dns records for the entire
wireless system to have the ability to accept commands via email. As for
home users (if that is the market) I think a simple http interface is
the only practical and realistic choice.
>
> 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.
Hands up all those who want an access point that needs all this to work
securely!
>
> 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.
Ahem. As I suspected. Let me quote my question to Chuck and his answer:
-----
> Besides that, why would it need the ability to accept email? I can
> > understand sending reports, alerts, blah, out but accepting email?
> >
> >
Remote control - one option. An embedded web server is another option -
I might not need email if we go that way.
-----
He was talking about the devices accepting email.
>
> 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.
So if it is not an access point, what other kind of wireless embedded
device needs to be remote controlled?
>
>> 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.
Same question as above.
>
>> 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.
No, you need to follow the threads and not just jump in halfway.
>
>> 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.
>
I think we can end this thread here since we were talking about
completely different things. A good day to you Alvin.
Christopher