Need email server aid

[Christopher Chan]

On Wednesday, April 28, 2010 12:23 AM, Alvin Thompson wrote:
> Wow, you just like to argue, I guess.  From now on, I'm simply going to
> ignore everything where you make the same old specious arguments. Simply
> repeating what you have already said doesn't make your points any more
> valid. If you actually made a counterpoint to my point, I'll answer. I'm
> also going to ignore smokescreens--where you try to argue some
> ridiculous tangent point that has nothing to do with the discussion,
> just because you don't want to admit YOU WERE JUST PLAIN WRONG.

Er...like just how you still keep thinking that this part of the thread 
is not about the embedded device having its own mta? I'm not backing 
down on the part about embedding an mta is good idea because 'smtp' is 
more 'reliable'. You have not proven anything about it but have gone on 
and on about the thing sending email to an external mta and yada yada.


>
> On 04/26/2010 08:53 PM, Christopher Chan wrote:
>> 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?
>
> Specious.  You can mis-configure any piece of software, not just mail.

Well, if the embedded device's stuff is somehow misconfigured, then 
there is not much hope in it no matter what is used. But an http 
interface does not have to rely on third party infrastructure as much as 
setting up an mta.


>
>> You are just talking about the characteristics of postfix's physical
>> queue management. What you described is not true for qmail or sendmail.
>
> This was Chuck's VERY FIRST sentence: "I am running Ubuntu 9.10, with
> postfix and dovecot for my email server."

That was already done and dealt with by me. Thanks for not following the 
thread. This part of the thread had moved from his postfix rejecting 
mail from his embedded device to why he wanted to embed an mta to which 
he replied remote control and I told him http might be a better idea 
than embedding an mta.


>
>> 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?
>
> Because HTTP IS UNRELIABLE! What part of that don't you understand?

If http is unreliable on the device itself, then smtp won't be any 
better because the only reason any connection will be unreliable would 
because the network had gone down.


>
>> Well, if someone wanted to gain control of the thing, they would
>> probably know what to put in the email no?
>
> You were talking about spammers, not people who wanted to take control
> of the device. Do really think that pretending you were talking about
> something else whenever someone demonstrates a flaw in your logic is the
> way to win arguments? It just makes you look like you're 12 years old.

That's only because you completely missed the part about an embedded mta 
and have failed to think of all the possible problems in setting up the 
infrastructure necessary for that scenario especially where you brought 
up mtas external to the device where I assumed you were talking about 
relays or even mxs that might get problems with a flooded queue.


>
>> 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.
>
> A central MTA is more complex than a peer-to-peer network for sending
> messages, as you propose? Are you serious?

 From the point of view of the user yes. Did you miss the part where I 
said the user? This is not some pet gpl software project. This is a 
product for an end user(s) and making it simple for them is pretty much 
imperative.


>
>>> 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.
> ...
>> He was talking about the devices accepting email.
>
> And I have already pointed out, it would be far easier to get mail to
> that device from the server via POP or IMAP. Pretending salient bits of
> information never occurred is not the best way to win an argument, either.

That I agree on in part if it was a single device like some of the items 
you listed at the end of your email. Setting up some gmail account for 
the thing won't be a big problem for some. That, however, still requires 
some clue or ability on the part of the end user to setup a mailbox for 
the thing.



>
>> So if it is not an access point, what other kind of wireless embedded
>> device needs to be remote controlled?
>
> a toy,
> a game,
> a music player,
> a DVR,
> a backup device,
> a logger,
> a printer,
> any of about 6 billion other devices,
> or how about this: SOMETHING THAT HASN'T BEEN INVENTED YET, WHICH IS WHY
> HE'S INVENTING IT.
>

And most of these would actually be better off with email based remote 
control interface and not a http interface? Networked printers all have 
an http interface for remote control but I not seen one that uses 
pop/imap or an embedded mta. http cannot be left out. Email is a nice 
addition for stuff like a toy.

Ergo, if am I just plain wrong, I guess the rest of world is too since 
nobody else thinks out of the box like you do. smtp is so reliable, 
every remote controllable device should have it. Or a mailbox they can 
pop/imap commands from.