Discussion:
Need email server aid
(too old to reply)
Chuck Kuecker
2010-04-21 16:41:19 UTC
Permalink
Hello,

I am running Ubuntu 9.10, with postfix and dovecot for my email server.
I host my own domain.

The Ubuntu machine relays emails from my Windows machine just fine, but
when I try to relay an email from an embedded system I am working with,
that resides on my local network, I get error messages in mail.log -
'relay access denied'. Sending email from the embedded system to my
local email account works fine.

I have the embedded system 'from' email set to my email address - but it
seems to make no difference if I use 'device at ckent.org' instead of
'ckuecker at ckent.org' - I can send to 'ckuecker at ckent.org', but any
attempt to send out of my local network returns the error.

I've enabled the entire local network here in /etc/postfix/main.cf -
mynetworks = 127.0.0.0/8, 192.168.0.0/16. My Windows machine SMTP is set
to use TLS, if available, and my user name. I'm thinking that I need to
send my user name and password somehow, in order to get relaying to
work. I don't see any SMTP commands that would do this.

What am I missing here?

Chuck Kuecker
Markus Schönhaber
2010-04-21 16:04:19 UTC
Permalink
21.04.2010 18:41, Chuck Kuecker:

> I am running Ubuntu 9.10, with postfix and dovecot for my email server.
> I host my own domain.
>
> The Ubuntu machine relays emails from my Windows machine just fine, but
> when I try to relay an email from an embedded system I am working with,
> that resides on my local network, I get error messages in mail.log -
> 'relay access denied'. Sending email from the embedded system to my
> local email account works fine.
>
> I have the embedded system 'from' email set to my email address - but it
> seems to make no difference if I use 'device at ckent.org' instead of
> 'ckuecker at ckent.org' - I can send to 'ckuecker at ckent.org', but any
> attempt to send out of my local network returns the error.
>
> I've enabled the entire local network here in /etc/postfix/main.cf -
> mynetworks = 127.0.0.0/8, 192.168.0.0/16. My Windows machine SMTP is set
> to use TLS, if available, and my user name. I'm thinking that I need to
> send my user name and password somehow, in order to get relaying to
> work. I don't see any SMTP commands that would do this.
>
> What am I missing here?

Difficult to tell.
Post the output of
postconf -n
and the lines from the mail.log which show such a failing transaction.
That will make it much easier to find the root of the problem.

--
Regards
mks
Chuck Kuecker
2010-04-21 23:18:51 UTC
Permalink
Markus Sch?nhaber wrote:
> 21.04.2010 18:41, Chuck Kuecker:
>
>
>> I am running Ubuntu 9.10, with postfix and dovecot for my email server.
>> I host my own domain.
>>
>> The Ubuntu machine relays emails from my Windows machine just fine, but
>> when I try to relay an email from an embedded system I am working with,
>> that resides on my local network, I get error messages in mail.log -
>> 'relay access denied'. Sending email from the embedded system to my
>> local email account works fine.
>>
>> I have the embedded system 'from' email set to my email address - but it
>> seems to make no difference if I use 'device at ckent.org' instead of
>> 'ckuecker at ckent.org' - I can send to 'ckuecker at ckent.org', but any
>> attempt to send out of my local network returns the error.
>>
>> I've enabled the entire local network here in /etc/postfix/main.cf -
>> mynetworks = 127.0.0.0/8, 192.168.0.0/16. My Windows machine SMTP is set
>> to use TLS, if available, and my user name. I'm thinking that I need to
>> send my user name and password somehow, in order to get relaying to
>> work. I don't see any SMTP commands that would do this.
>>
>> What am I missing here?
>>
>
> Difficult to tell.
> Post the output of
> postconf -n
> and the lines from the mail.log which show such a failing transaction.
> That will make it much easier to find the root of the problem.
>
>
Here's the data:

postconf -n:

lias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
home_mailbox = Maildir/
inet_interfaces = all
inet_protocols = all
mailbox_command =
mailbox_size_limit = 0
mydestination = ckenterprises.ckent.org, mail.ckent.org, ckent.org,
localhost.localdomain, localhost
myhostname = mail.ckent.org
mynetworks = 127.0.0.0/8, 192.168.0.0/16
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_recipient_restrictions = reject_unknown_sender_domain,
reject_unknown_recipient_domain, reject_unauth_pipelining,
permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt
smtpd_tls_key_file = /etc/ssl/private/smtpd.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_random_source = dev:/dev/urandom

mail.log:

Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
<addr at dest.com>: Relay access denied; from=<device at ckent.org>
to=<addr at dest.com> proto=SMTP helo=<ckent.org>
Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from


Chuck

mail.ckent.org[66.254.194.29]
Hal Burgiss
2010-04-21 23:10:46 UTC
Permalink
On Wed, Apr 21, 2010 at 7:18 PM, Chuck Kuecker <ckuecker at ckent.org> wrote:
> Markus Sch?nhaber wrote:
>> 21.04.2010 18:41, Chuck Kuecker:
> postconf -n:
>
> lias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> broken_sasl_auth_clients = yes
> config_directory = /etc/postfix
> home_mailbox = Maildir/
> inet_interfaces = all
> inet_protocols = all
> mailbox_command =
> mailbox_size_limit = 0
> mydestination = ckenterprises.ckent.org, mail.ckent.org, ckent.org,
> localhost.localdomain, localhost
> myhostname = mail.ckent.org
> mynetworks = 127.0.0.0/8, 192.168.0.0/16
> myorigin = /etc/mailname
> readme_directory = no
> recipient_delimiter = +
> relayhost =
> smtp_tls_note_starttls_offer = yes
> smtp_tls_security_level = may
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
> smtpd_recipient_restrictions = reject_unknown_sender_domain,
> reject_unknown_recipient_domain, ? ? ? ?reject_unauth_pipelining,
> permit_mynetworks, ? ? ?permit_sasl_authenticated, ? ? ?reject_unauth_destination
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_local_domain =
> smtpd_sasl_security_options = noanonymous
> smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
> smtpd_tls_auth_only = no
> smtpd_tls_cert_file = /etc/ssl/certs/smtpd.crt
> smtpd_tls_key_file = /etc/ssl/private/smtpd.key
> smtpd_tls_loglevel = 1
> smtpd_tls_received_header = yes
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
> smtpd_tls_session_cache_timeout = 3600s
> smtpd_use_tls = yes
> tls_random_source = dev:/dev/urandom
>
> mail.log:
>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
> RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
> <addr at dest.com>: Relay access denied; from=<device at ckent.org>
> to=<addr at dest.com> proto=SMTP helo=<ckent.org>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from
>


If I remember correctly, reject_unknown_sender_domain requires a
working DNS, A record, and maybe MX for the connecting IP. You might
try re-ordering that section, or just remove that as a test (be sure
to do a postfix reload).

--
Hal
Christopher Chan
2010-04-22 00:34:23 UTC
Permalink
>> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
>> RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
>> <addr at dest.com>: Relay access denied; from=<device at ckent.org>
>> to=<addr at dest.com> proto=SMTP helo=<ckent.org>
>> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from
>>
>
>
> If I remember correctly, reject_unknown_sender_domain requires a
> working DNS, A record, and maybe MX for the connecting IP. You might
> try re-ordering that section, or just remove that as a test (be sure
> to do a postfix reload).
>

That's not a unknown sender domain problem, that's postfix doing the
right thing. I suspect the OP forgot to enable authentication on his
mail client.
Hal Burgiss
2010-04-22 00:45:52 UTC
Permalink
On Wed, Apr 21, 2010 at 8:34 PM, Christopher Chan
<christopher.chan at bradbury.edu.hk> wrote:

>
> That's not a unknown sender domain problem, that's postfix doing the
> right thing. I suspect the OP forgot to enable authentication on his
> mail client.

But why would he want to do that with an embedded system on a LAN?
Simpler just to use ip based authentication.


--
Hal
Christopher Chan
2010-04-22 01:32:09 UTC
Permalink
On Thursday, April 22, 2010 08:45 AM, Hal Burgiss wrote:
> On Wed, Apr 21, 2010 at 8:34 PM, Christopher Chan
> <christopher.chan at bradbury.edu.hk> wrote:
>
>>
>> That's not a unknown sender domain problem, that's postfix doing the
>> right thing. I suspect the OP forgot to enable authentication on his
>> mail client.
>
> But why would he want to do that with an embedded system on a LAN?
> Simpler just to use ip based authentication.
>
>

Embedded systems do support setting up smtp authentication. His system's
ip was not exactly internal you know...
Chuck Kuecker
2010-04-22 14:03:44 UTC
Permalink
Christopher Chan wrote:
> On Thursday, April 22, 2010 08:45 AM, Hal Burgiss wrote:
>
>> On Wed, Apr 21, 2010 at 8:34 PM, Christopher Chan
>> <christopher.chan at bradbury.edu.hk> wrote:
>>
>>
>>> That's not a unknown sender domain problem, that's postfix doing the
>>> right thing. I suspect the OP forgot to enable authentication on his
>>> mail client.
>>>
>> But why would he want to do that with an embedded system on a LAN?
>> Simpler just to use ip based authentication.
>>
>>
>>
>
> Embedded systems do support setting up smtp authentication. His system's
> ip was not exactly internal you know...
>
>
My device better be internal now! If somehow my 192.168.0.x net is
available to the world, I need to know about it!

device at ckent.org is an arbitrary email address I gave the gadget to let
me know where an email is coming from. there's no DNS resolution for
device.ckent.org.

As long as the gadget can contact an arbitrary email server to send and
receive, ultimately, I'm doing OK. If this requires more than the really
simple code I am playing with, I have no problem adding a package to
handle that - I just want to get the smallest package possible.

Chuck Kuecker
Chan Chung Hang Christopher
2010-04-22 13:28:34 UTC
Permalink
Chuck Kuecker wrote:
> Christopher Chan wrote:
>> On Thursday, April 22, 2010 08:45 AM, Hal Burgiss wrote:
>>
>>> On Wed, Apr 21, 2010 at 8:34 PM, Christopher Chan
>>> <christopher.chan at bradbury.edu.hk> wrote:
>>>
>>>
>>>> That's not a unknown sender domain problem, that's postfix doing the
>>>> right thing. I suspect the OP forgot to enable authentication on his
>>>> mail client.
>>>>
>>> But why would he want to do that with an embedded system on a LAN?
>>> Simpler just to use ip based authentication.
>>>
>>>
>>>
>> Embedded systems do support setting up smtp authentication. His system's
>> ip was not exactly internal you know...
>>
>>
> My device better be internal now! If somehow my 192.168.0.x net is
> available to the world, I need to know about it!
>
> device at ckent.org is an arbitrary email address I gave the gadget to let
> me know where an email is coming from. there's no DNS resolution for
> device.ckent.org.

Whether device.ckent.org is a resolvable is not a problem for postfix
with the way you have configured it. ckent.org not resolving would be
another matter but since postfix did not reject you based on your
domain, I'd say you had no problem given that that is the first check in
your config.


>
> As long as the gadget can contact an arbitrary email server to send and
> receive, ultimately, I'm doing OK. If this requires more than the really
> simple code I am playing with, I have no problem adding a package to
> handle that - I just want to get the smallest package possible.
>

Hey, you could get a smtp session started...I don't see why you need to
add a package at the moment until we figure out just what your problem
is, if your box is internal as you say.
Chuck Kuecker
2010-04-22 13:59:07 UTC
Permalink
Christopher Chan wrote:
>>> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
>>> RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
>>> <addr at dest.com>: Relay access denied; from=<device at ckent.org>
>>> to=<addr at dest.com> proto=SMTP helo=<ckent.org>
>>> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from
>>>
>>>
>> If I remember correctly, reject_unknown_sender_domain requires a
>> working DNS, A record, and maybe MX for the connecting IP. You might
>> try re-ordering that section, or just remove that as a test (be sure
>> to do a postfix reload).
>>
>>
>
> That's not a unknown sender domain problem, that's postfix doing the
> right thing. I suspect the OP forgot to enable authentication on his
> mail client.
>
>
'Email client' being the simple code that sends the SMTP command packet
that is my email in my embedded system? There's nothing but opening a
socket and sending packets - no actual 'client' code at all.

One thing I have been researching is a very small email client that I
can embed. So far, I have not found the solution. My embedded system is
fairly good on memory, but there are limits you don't have with a PC
running Ubuntu.

If there's a quick and dirty way of providing authentication from the
embedded box that you know of, please let me know. In the future it
would be nice to be able to receive email as well as send it. The
original code I started from had email receive capability, but nothing
for security. I can handle SSL and such if I have to.

Chuck Kuecker
Chan Chung Hang Christopher
2010-04-22 13:23:12 UTC
Permalink
> 'Email client' being the simple code that sends the SMTP command packet
> that is my email in my embedded system? There's nothing but opening a
> socket and sending packets - no actual 'client' code at all.

I'd say that that is a client. I have had my share of writing a smtp
client or two in C for nagios monitoring which would give custom error
messages to indicate at what stage a delivery problem was encountered in
the smtp session.


>
> One thing I have been researching is a very small email client that I
> can embed. So far, I have not found the solution. My embedded system is
> fairly good on memory, but there are limits you don't have with a PC
> running Ubuntu.
>
> If there's a quick and dirty way of providing authentication from the
> embedded box that you know of, please let me know. In the future it
> would be nice to be able to receive email as well as send it. The
> original code I started from had email receive capability, but nothing
> for security. I can handle SSL and such if I have to.

postfix supports AUTH PLAIN so you can use that in your code to
authenticate. You simply want to encode the string
'username\0username\0password' in base64 and feed that to postfix after
you by invoking AUTH PLAIN.

EHLO embeddedhostname
- check response for AUTH PLAIN support
AUTH PLAIN base64encodeduserpassstring
- check response
MAIL FROM: yada at yada.yada
{rest of smtp session}
Chuck Kuecker
2010-04-22 14:33:55 UTC
Permalink
Chan Chung Hang Christopher wrote:
>> 'Email client' being the simple code that sends the SMTP command packet
>> that is my email in my embedded system? There's nothing but opening a
>> socket and sending packets - no actual 'client' code at all.
>>
>
> I'd say that that is a client. I have had my share of writing a smtp
> client or two in C for nagios monitoring which would give custom error
> messages to indicate at what stage a delivery problem was encountered in
> the smtp session.
>
>
>
>> One thing I have been researching is a very small email client that I
>> can embed. So far, I have not found the solution. My embedded system is
>> fairly good on memory, but there are limits you don't have with a PC
>> running Ubuntu.
>>
>> If there's a quick and dirty way of providing authentication from the
>> embedded box that you know of, please let me know. In the future it
>> would be nice to be able to receive email as well as send it. The
>> original code I started from had email receive capability, but nothing
>> for security. I can handle SSL and such if I have to.
>>
>
> postfix supports AUTH PLAIN so you can use that in your code to
> authenticate. You simply want to encode the string
> 'username\0username\0password' in base64 and feed that to postfix after
> you by invoking AUTH PLAIN.
>
> EHLO embeddedhostname
> - check response for AUTH PLAIN support
> AUTH PLAIN base64encodeduserpassstring
> - check response
> MAIL FROM: yada at yada.yada
> {rest of smtp session}
>
>
That's what I am looking for. Thanks!

I will report back on how it works out.

Chuck Kuecker
Chuck Kuecker
2010-04-22 15:26:31 UTC
Permalink
Chan Chung Hang Christopher wrote:
<snip>
> postfix supports AUTH PLAIN so you can use that in your code to
> authenticate. You simply want to encode the string
> 'username\0username\0password' in base64 and feed that to postfix after
> you by invoking AUTH PLAIN.
>
> EHLO embeddedhostname
> - check response for AUTH PLAIN support
> AUTH PLAIN base64encodeduserpassstring
> - check response
> MAIL FROM: yada at yada.yada
> {rest of smtp session}
>
Which species of base64 encoding do I want? Wikipedia shows several
associated with email.

Chuck Kuecker
Alvin Thompson
2010-04-26 19:06:40 UTC
Permalink
On 04/22/2010 11:26 AM, Chuck Kuecker wrote:
> Which species of base64 encoding do I want? Wikipedia shows several
> associated with email.

Chuck, it would likely be far easier to just include a lightweight SMTP
server locally on the device and take advantage of one of the billion
SMTP libraries out there for whatever language you're working with.

Since all you need to do is send mail from the device and not accept
mail (you can still *receive* mail if you want by getting it from the
server via POP or IMAP), and since you only need to accept connections
locally, configuration should be easy. There are many very lightweight
SMTP servers available for this use case. Why make more work for yourself?

Just make sure you get an SMTP server that includes a mail queue for
reliability (that excludes "ssmtp" and "esmtp" for example).
"Nullmailer" comes to mind. Nullmailer's configuration is dead simple:
you just specify the embedded device's name in /etc/mailname (this will
also be the domain part of the "from" address for your mail unless
otherwise specified), and specify your mail server address
(mail.ckent.org) in /etc/nullmailer/remotes.

Hope this helps,
Alvin
Hal Burgiss
2010-04-22 14:07:20 UTC
Permalink
On Thu, Apr 22, 2010 at 9:59 AM, Chuck Kuecker <ckuecker at ckent.org> wrote:
>
>
> If there's a quick and dirty way of providing authentication from the
> embedded box that you know of, please let me know. In the future it

IP based authentication. You have a configuration setting somewhere
that is forcing more than you need for the situation. Your LAN should
be allowed to send/relay without the username/password hassle. Its
overkill. There's a setting somewhere in all that config stuff that is
probably on by default (I don't recall offhand).

--
Hal
Markus Schönhaber
2010-04-22 08:22:07 UTC
Permalink
22.04.2010 01:18, Chuck Kuecker:

> Markus Sch?nhaber wrote:
>> 21.04.2010 18:41, Chuck Kuecker:

>>> The Ubuntu machine relays emails from my Windows machine just fine, but
>>> when I try to relay an email from an embedded system I am working with,
>>> that resides on my local network, I get error messages in mail.log -
>>> 'relay access denied'. Sending email from the embedded system to my
>>> local email account works fine.

That's to be expected. Unless explicitly configured otherwise, everyone
is able to send mail to the domain the server feels responsible for.

>>> I have the embedded system 'from' email set to my email address - but it
>>> seems to make no difference if I use 'device at ckent.org' instead of
>>> 'ckuecker at ckent.org' - I can send to 'ckuecker at ckent.org', but any
>>> attempt to send out of my local network returns the error.

Which is a very good thing. The thought, that spammer could defeat the
server's restrictions by just using a particular 'from', is what I'd
call a nightmare.

>>> I've enabled the entire local network here in /etc/postfix/main.cf -
>>> mynetworks = 127.0.0.0/8, 192.168.0.0/16. My Windows machine SMTP is set
>>> to use TLS, if available, and my user name. I'm thinking that I need to
>>> send my user name and password somehow, in order to get relaying to
>>> work. I don't see any SMTP commands that would do this.
>>>
>>> What am I missing here?
>>>
>>
>> Difficult to tell.
>> Post the output of
>> postconf -n
>> and the lines from the mail.log which show such a failing transaction.
>> That will make it much easier to find the root of the problem.
>>
>>
> Here's the data:
>
> postconf -n:
>
> lias_database = hash:/etc/aliases

Copy and paste error?

[...]
> mynetworks = 127.0.0.0/8, 192.168.0.0/16
[...]
> smtpd_recipient_restrictions = reject_unknown_sender_domain,
> reject_unknown_recipient_domain, reject_unauth_pipelining,
> permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
[...]
Looks good.

> mail.log:
>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
> RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
> <addr at dest.com>: Relay access denied; from=<device at ckent.org>
> to=<addr at dest.com> proto=SMTP helo=<ckent.org>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from

> mail.ckent.org[66.254.194.29]

Above, you said that the embedded system is in your local network. But
this log excerpt shows a client connecting from 66.254.194.29, i. e. an
IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
contained in the IP ranges you configured as mynetworks and
permit_mynetworks doesn't apply.

--
Regards
mks
Chuck Kuecker
2010-04-22 14:10:06 UTC
Permalink
Markus Sch?nhaber wrote:
> 22.04.2010 01:18, Chuck Kuecker:
>
>
>> Markus Sch?nhaber wrote:
>>
>>> 21.04.2010 18:41, Chuck Kuecker:
>>>
> <snip>
>> Here's the data:
>>
>> postconf -n:
>>
>> lias_database = hash:/etc/aliases
>>
>
> Copy and paste error?
>

Yep. My bad.
> <snip>
>> mail.ckent.org[66.254.194.29]
>>
>
> Above, you said that the embedded system is in your local network. But
> this log excerpt shows a client connecting from 66.254.194.29, i. e. an
> IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
> contained in the IP ranges you configured as mynetworks and
> permit_mynetworks doesn't apply.
>
>
OK. I see that. 66.254.194.29 is my static IP from my ISP. When I
resolve 'mail.ckent.org', that's what comes up. I certainly don't want
just anyone sending email to that IP to be able to relay!

This is what confuses me - my Windoze PC has Thunderbird set up to
access email via 'mail.ckent.org', and it's on my local network, just
like the embedded gadget and the Linux box hosting 'mail.ckent.org'. Why
does the PC connect reliably, but the embedded gadget fails reliably?

Chuck Kuecker
Chan Chung Hang Christopher
2010-04-22 13:30:29 UTC
Permalink
Chuck Kuecker wrote:
> Markus Sch?nhaber wrote:
>> 22.04.2010 01:18, Chuck Kuecker:
>>
>>
>>> Markus Sch?nhaber wrote:
>>>
>>>> 21.04.2010 18:41, Chuck Kuecker:
>>>>
>> <snip>
>>> Here's the data:
>>>
>>> postconf -n:
>>>
>>> lias_database = hash:/etc/aliases
>>>
>> Copy and paste error?
>>
>
> Yep. My bad.
>> <snip>
>>> mail.ckent.org[66.254.194.29]
>>>
>> Above, you said that the embedded system is in your local network. But
>> this log excerpt shows a client connecting from 66.254.194.29, i. e. an
>> IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
>> contained in the IP ranges you configured as mynetworks and
>> permit_mynetworks doesn't apply.
>>
>>
> OK. I see that. 66.254.194.29 is my static IP from my ISP. When I
> resolve 'mail.ckent.org', that's what comes up. I certainly don't want
> just anyone sending email to that IP to be able to relay!
>
> This is what confuses me - my Windoze PC has Thunderbird set up to
> access email via 'mail.ckent.org', and it's on my local network, just
> like the embedded gadget and the Linux box hosting 'mail.ckent.org'. Why
> does the PC connect reliably, but the embedded gadget fails reliably?
>

Where did you point your embedded system to send email? 192.168.x.x or
something else?
Chuck Kuecker
2010-04-22 15:24:10 UTC
Permalink
Chan Chung Hang Christopher wrote:
> Chuck Kuecker wrote:
>
>> Markus Sch?nhaber wrote:
>>
>>> 22.04.2010 01:18, Chuck Kuecker:
>>>
>>>
<snip>
>>>> mail.ckent.org[66.254.194.29]
>>>>
>>>>
>>> Above, you said that the embedded system is in your local network. But
>>> this log excerpt shows a client connecting from 66.254.194.29, i. e. an
>>> IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
>>> contained in the IP ranges you configured as mynetworks and
>>> permit_mynetworks doesn't apply.
>>>
>>>
>>>
>> OK. I see that. 66.254.194.29 is my static IP from my ISP. When I
>> resolve 'mail.ckent.org', that's what comes up. I certainly don't want
>> just anyone sending email to that IP to be able to relay!
>>
>> This is what confuses me - my Windoze PC has Thunderbird set up to
>> access email via 'mail.ckent.org', and it's on my local network, just
>> like the embedded gadget and the Linux box hosting 'mail.ckent.org'. Why
>> does the PC connect reliably, but the embedded gadget fails reliably?
>>
>>
>
> Where did you point your embedded system to send email? 192.168.x.x or
> something else?
>
>
Emails were sent to 'mail.ckent.org' which resolves to 66.254.194.29.
Ultimately, I need to send email to an arbitrary mail server the user
has an account on.

If I sent to 192.168.0.200, which is the Ubuntu machine, would that help?

Chuck Kuecker
Chan Chung Hang Christopher
2010-04-22 14:50:02 UTC
Permalink
Chuck Kuecker wrote:
> Chan Chung Hang Christopher wrote:
>> Chuck Kuecker wrote:
>>
>>> Markus Sch?nhaber wrote:
>>>
>>>> 22.04.2010 01:18, Chuck Kuecker:
>>>>
>>>>
> <snip>
>>>>> mail.ckent.org[66.254.194.29]
>>>>>
>>>>>
>>>> Above, you said that the embedded system is in your local network. But
>>>> this log excerpt shows a client connecting from 66.254.194.29, i. e. an
>>>> IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
>>>> contained in the IP ranges you configured as mynetworks and
>>>> permit_mynetworks doesn't apply.
>>>>
>>>>
>>>>
>>> OK. I see that. 66.254.194.29 is my static IP from my ISP. When I
>>> resolve 'mail.ckent.org', that's what comes up. I certainly don't want
>>> just anyone sending email to that IP to be able to relay!
>>>
>>> This is what confuses me - my Windoze PC has Thunderbird set up to
>>> access email via 'mail.ckent.org', and it's on my local network, just
>>> like the embedded gadget and the Linux box hosting 'mail.ckent.org'. Why
>>> does the PC connect reliably, but the embedded gadget fails reliably?
>>>
>>>
>> Where did you point your embedded system to send email? 192.168.x.x or
>> something else?
>>
>>
> Emails were sent to 'mail.ckent.org' which resolves to 66.254.194.29.
> Ultimately, I need to send email to an arbitrary mail server the user
> has an account on.
>
> If I sent to 192.168.0.200, which is the Ubuntu machine, would that help?
>

Immensely I suspect.
Chuck Kuecker
2010-04-22 22:23:49 UTC
Permalink
Chan Chung Hang Christopher wrote:
> Chuck Kuecker wrote:
>
<snip>
>>>>
>>>>
>>> Where did you point your embedded system to send email? 192.168.x.x or
>>> something else?
>>>
>>>
>>>
>> Emails were sent to 'mail.ckent.org' which resolves to 66.254.194.29.
>> Ultimately, I need to send email to an arbitrary mail server the user
>> has an account on.
>>
>> If I sent to 192.168.0.200, which is the Ubuntu machine, would that help?
>>
>>
>
> Immensely I suspect.
>
It worked with the IP, not the domain name.

I still need to get it to work with an outside address, so I guess I
need to fiddle with my DNS server next.

Thanks for the help!

Chuck
Alvin Thompson
2010-04-22 23:26:26 UTC
Permalink
On 04/22/2010 06:23 PM, Chuck Kuecker wrote:
> It worked with the IP, not the domain name.
>
> I still need to get it to work with an outside address, so I guess I
> need to fiddle with my DNS server next.
>
> Thanks for the help!

If you just need 'mail.ckent.org' to resolve to your local address, just
put it in your '/etc/hosts' file, or whatever the equivalent is on you
embedded system.

BTW, if it's an embedded system that never leaves your network, why do
you need it to work with an outside address? Why can't you just use the
local IP?
Chuck Kuecker
2010-04-23 00:39:08 UTC
Permalink
Alvin Thompson wrote:
> On 04/22/2010 06:23 PM, Chuck Kuecker wrote:
>
>> It worked with the IP, not the domain name.
>>
>> I still need to get it to work with an outside address, so I guess I
>> need to fiddle with my DNS server next.
>>
>> Thanks for the help!
>>
>
> If you just need 'mail.ckent.org' to resolve to your local address, just
> put it in your '/etc/hosts' file, or whatever the equivalent is on you
> embedded system.
>
> BTW, if it's an embedded system that never leaves your network, why do
> you need it to work with an outside address? Why can't you just use the
> local IP?
>
>
Ultimately, this will be a wireless product that will be out in the
wild, and will need the capability to connect anywhere, assuming the
user has an email account on the network, somewhere in the world. At
present, I'm just playing with basics using the built-in Ethernet port
included with the development system.

Chuck
Alvin Thompson
2010-04-23 00:49:00 UTC
Permalink
On 04/22/2010 08:39 PM, Chuck Kuecker wrote:
> Ultimately, this will be a wireless product that will be out in the
> wild, and will need the capability to connect anywhere, assuming the
> user has an email account on the network, somewhere in the world. At
> present, I'm just playing with basics using the built-in Ethernet port
> included with the development system.

In that case, you will need to configure things differently. You have 3
choices, from worst to best:

1. Include one of the tiny SMTP servers out there on the device, and
have the device connect directly to destination SMTP server. This is
the simplest solution because you will need to include an SMTP server on
the device no matter what (explained below), but this is also
problematic because there are ISPs out that will not accept mail from
'untrusted' IP addresses. If the device is mobile, you can make no
guarantees on what network or IP address the device will be using.

2. Use a password stored on the device to relay mail through your mail
server (using TLS, of course). If the device gets hacked, the hacker
has your password and can relay mail through your system.

3. The best option. On each device, include a unique public/private key
pair and use that to authenticate, encrypt, and relay mail though your
mail server. If a device gets hacked, you just have to disable the key
for that specific device on your server. Better yet, if you're also
charging a service fee and the client doesn't pay the bill on time, you
can simply disable email (and other services for the device) until they
bring their account current.

Option #3 is even better if this is an "always on" device. If that's
the case, you can provide a pass-phrase to the private key, to be
entered by you (or your henchmen) when the device starts up for the
first time. When you do that, you can guarantee 3 things (I like 3's):

1. Messages that claim to be from the device are indeed from the device.

2. Messages cannot be read by anyone except authorized parties.

3. Messages cannot be altered in any way in transit. What is sent is
what you get.

The only thing you can't guarantee with this method is that sent
messages will actually be received. This is how iPhones work (I think),
and that's why you need to connect iPhones to iTunes on order to
activate them (it's getting the pass-phrase for your private key-- at
least I think so). It's about as secure as things get.

Anyway, you will always need an SMTP server on the device to queue sent
messages if an internet connection or your server isn't available at the
moment. Otherwise, you risk unnecessarily losing sent messages.

Hope this helps,
Alvin
Chuck Kuecker
2010-04-23 02:21:26 UTC
Permalink
Alvin Thompson wrote:
> On 04/22/2010 08:39 PM, Chuck Kuecker wrote:
>
>> Ultimately, this will be a wireless product that will be out in the
>> wild, and will need the capability to connect anywhere, assuming the
>> user has an email account on the network, somewhere in the world. At
>> present, I'm just playing with basics using the built-in Ethernet port
>> included with the development system.
>>
>
> In that case, you will need to configure things differently. You have 3
> choices, from worst to best:
>
> 1. Include one of the tiny SMTP servers out there on the device, and
> have the device connect directly to destination SMTP server. This is
> the simplest solution because you will need to include an SMTP server on
> the device no matter what (explained below), but this is also
> problematic because there are ISPs out that will not accept mail from
> 'untrusted' IP addresses. If the device is mobile, you can make no
> guarantees on what network or IP address the device will be using.
>
> 2. Use a password stored on the device to relay mail through your mail
> server (using TLS, of course). If the device gets hacked, the hacker
> has your password and can relay mail through your system.
>
> 3. The best option. On each device, include a unique public/private key
> pair and use that to authenticate, encrypt, and relay mail though your
> mail server. If a device gets hacked, you just have to disable the key
> for that specific device on your server. Better yet, if you're also
> charging a service fee and the client doesn't pay the bill on time, you
> can simply disable email (and other services for the device) until they
> bring their account current.
>
> Option #3 is even better if this is an "always on" device. If that's
> the case, you can provide a pass-phrase to the private key, to be
> entered by you (or your henchmen) when the device starts up for the
> first time. When you do that, you can guarantee 3 things (I like 3's):
>
> 1. Messages that claim to be from the device are indeed from the device.
>
> 2. Messages cannot be read by anyone except authorized parties.
>
> 3. Messages cannot be altered in any way in transit. What is sent is
> what you get.
>
> The only thing you can't guarantee with this method is that sent
> messages will actually be received. This is how iPhones work (I think),
> and that's why you need to connect iPhones to iTunes on order to
> activate them (it's getting the pass-phrase for your private key-- at
> least I think so). It's about as secure as things get.
>
> Anyway, you will always need an SMTP server on the device to queue sent
> messages if an internet connection or your server isn't available at the
> moment. Otherwise, you risk unnecessarily losing sent messages.
>
> Hope this helps,
> Alvin
>
>
Great help. Thanks for the suggestions.

The final product will likely need encryption, anyway.

Chuck
Christopher Chan
2010-04-23 01:58:02 UTC
Permalink
On Friday, April 23, 2010 08:39 AM, Chuck Kuecker wrote:
> Alvin Thompson wrote:
>> On 04/22/2010 06:23 PM, Chuck Kuecker wrote:
>>
>>> It worked with the IP, not the domain name.
>>>
>>> I still need to get it to work with an outside address, so I guess I
>>> need to fiddle with my DNS server next.
>>>
>>> Thanks for the help!
>>>
>>
>> If you just need 'mail.ckent.org' to resolve to your local address, just
>> put it in your '/etc/hosts' file, or whatever the equivalent is on you
>> embedded system.
>>
>> BTW, if it's an embedded system that never leaves your network, why do
>> you need it to work with an outside address? Why can't you just use the
>> local IP?
>>
>>
> Ultimately, this will be a wireless product that will be out in the
> wild, and will need the capability to connect anywhere, assuming the
> user has an email account on the network, somewhere in the world. At
> present, I'm just playing with basics using the built-in Ethernet port
> included with the development system.

Then it will need to have to ability to be told to use smtp
authentication, username and password, to be told what port to connect
to and support ssl on port 465 and enabling tls on port 25/587.

Ultimately, I think it will more often tha not just need to be told to
connect to the owner's ISP mail relay to send email.

Besides that, why would it need the ability to accept email? I can
understand sending reports, alerts, blah, out but accepting email?
Chuck Kuecker
2010-04-23 10:46:53 UTC
Permalink
Christopher Chan wrote:
> On Friday, April 23, 2010 08:39 AM, Chuck Kuecker wrote:
>
>> Alvin Thompson wrote:
>>
>>> On 04/22/2010 06:23 PM, Chuck Kuecker wrote:
>>>
>>>
>>>> It worked with the IP, not the domain name.
>>>>
>>>> I still need to get it to work with an outside address, so I guess I
>>>> need to fiddle with my DNS server next.
>>>>
>>>> Thanks for the help!
>>>>
>>>>
>>> If you just need 'mail.ckent.org' to resolve to your local address, just
>>> put it in your '/etc/hosts' file, or whatever the equivalent is on you
>>> embedded system.
>>>
>>> BTW, if it's an embedded system that never leaves your network, why do
>>> you need it to work with an outside address? Why can't you just use the
>>> local IP?
>>>
>>>
>>>
>> Ultimately, this will be a wireless product that will be out in the
>> wild, and will need the capability to connect anywhere, assuming the
>> user has an email account on the network, somewhere in the world. At
>> present, I'm just playing with basics using the built-in Ethernet port
>> included with the development system.
>>
>
> Then it will need to have to ability to be told to use smtp
> authentication, username and password, to be told what port to connect
> to and support ssl on port 465 and enabling tls on port 25/587.
>
> Ultimately, I think it will more often tha not just need to be told to
> connect to the owner's ISP mail relay to send email.
>
> 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.

This project is very much in development - we're writing specifications yet.

Chuck
Alvin Thompson
2010-04-23 15:37:13 UTC
Permalink
On 04/23/2010 06:46 AM, Chuck Kuecker wrote:
> Remote control - one option. An embedded web server is another option -
> I might not need email if we go that way.
>
> This project is very much in development - we're writing specifications yet.

Email is probably the best way to go, because it already solves the
problem of reliably transmitting messages over an unreliable medium
(assuming all players are cooperative). Otherwise you'll spend a lot of
time 'reinventing the wheel' to get that reliability back. First, with
queuing of messages that can't be sent, then with persisting the queue
if the device is powered off before the messages are sent, then with
retrying sending messages if the server isn't available, then with
backing off retries if the server is unavailable for an extended period,
the list goes on and on. Mail servers may not be the most glamorous
software, or the new kid on the block, but mail servers do all of what
you need out of the box, and have been honed over the last 20 years of use.

I've been with a lot of projects that thought that they too could come
up with their own clever solution, and that solution sucked up more and
more of their time and resources when they could have just plopped in a
mail server and a mail library and be done with it.
Chan Chung Hang Christopher
2010-04-24 06:56:24 UTC
Permalink
Chuck Kuecker wrote:
> Christopher Chan wrote:
>> On Friday, April 23, 2010 08:39 AM, Chuck Kuecker wrote:
>>
>>> Alvin Thompson wrote:
>>>
>>>> On 04/22/2010 06:23 PM, Chuck Kuecker wrote:
>>>>
>>>>
>>>>> It worked with the IP, not the domain name.
>>>>>
>>>>> I still need to get it to work with an outside address, so I guess I
>>>>> need to fiddle with my DNS server next.
>>>>>
>>>>> Thanks for the help!
>>>>>
>>>>>
>>>> If you just need 'mail.ckent.org' to resolve to your local address, just
>>>> put it in your '/etc/hosts' file, or whatever the equivalent is on you
>>>> embedded system.
>>>>
>>>> BTW, if it's an embedded system that never leaves your network, why do
>>>> you need it to work with an outside address? Why can't you just use the
>>>> local IP?
>>>>
>>>>
>>>>
>>> Ultimately, this will be a wireless product that will be out in the
>>> wild, and will need the capability to connect anywhere, assuming the
>>> user has an email account on the network, somewhere in the world. At
>>> present, I'm just playing with basics using the built-in Ethernet port
>>> included with the development system.
>>>
>> Then it will need to have to ability to be told to use smtp
>> authentication, username and password, to be told what port to connect
>> to and support ssl on port 465 and enabling tls on port 25/587.
>>
>> Ultimately, I think it will more often tha not just need to be told to
>> connect to the owner's ISP mail relay to send email.
>>
>> 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.

How do you verify the email source before you implement the command(s)?

An embedded web server for remote control is something that would be
expected nowadays if you ask me. And maybe your own protocol and a
client gui on Windows/Linux/Mac OS X/OpenSolaris.
Alvin Thompson
2010-04-24 15:33:33 UTC
Permalink
On 04/24/2010 02:56 AM, Chan Chung Hang Christopher wrote:
> How do you verify the email source before you implement the command(s)?

If you have the device's public key, you can accept only messages
encoded with the devices private key. I believe this is done at the
transport level (the TLS handshake), so you don't have to worry about it
in your code or write any code differently--it just works. See articles
on how PKI (public key infrastructure) works. It's quite interesting.

> An embedded web server for remote control is something that would be
> expected nowadays if you ask me. And maybe your own protocol and a
> client gui on Windows/Linux/Mac OS X/OpenSolaris.

That's fine if there is aways going to be a human to send the all
messages and verify every message is sent. Otherwise, you'll need
software to send the messages reliably. See my message above pointing
out that SMTP achieves that reliability without too much additional
complexity. But I agree that you can (and probably should) add a
lightweight web server for showing status and for remote commands that
are necessarily human-controlled.

As a Java developer, I'll point out that a web server with JMS can also
approximate the reliability of SMTP, but it's much more complex to
implement and adding a Java and J2EE stack may be use up more resources
on an embedded device than he wants or has.
Chan Chung Hang Christopher
2010-04-25 11:38:55 UTC
Permalink
Alvin Thompson wrote:
> On 04/24/2010 02:56 AM, Chan Chung Hang Christopher wrote:
>> How do you verify the email source before you implement the command(s)?
>
> If you have the device's public key, you can accept only messages
> encoded with the devices private key. I believe this is done at the
> transport level (the TLS handshake), so you don't have to worry about it
> in your code or write any code differently--it just works. See articles
> on how PKI (public key infrastructure) works. It's quite interesting.

I doubt that using smtp, however secured, for auto configuration or
whatever automatic stuff is a good idea.


>
>> An embedded web server for remote control is something that would be
>> expected nowadays if you ask me. And maybe your own protocol and a
>> client gui on Windows/Linux/Mac OS X/OpenSolaris.
>
> That's fine if there is aways going to be a human to send the all
> messages and verify every message is sent. Otherwise, you'll need
> software to send the messages reliably. See my message above pointing
> out that SMTP achieves that reliability without too much additional
> complexity. But I agree that you can (and probably should) add a
> lightweight web server for showing status and for remote commands that
> are necessarily human-controlled.

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


>
> As a Java developer, I'll point out that a web server with JMS can also
> approximate the reliability of SMTP, but it's much more complex to
> implement and adding a Java and J2EE stack may be use up more resources
> on an embedded device than he wants or has.
>

Reliability of smtp? I suppose if delays of five days or a day are
tolerated or not at all....
Alvin Thompson
2010-04-25 18:25:50 UTC
Permalink
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'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.

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.

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.
Christopher Chan
2010-04-26 00:38:51 UTC
Permalink
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.
NoOp
2010-04-26 01:15:41 UTC
Permalink
On 04/25/2010 05:38 PM, Christopher Chan wrote:
...
> 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
...

Say hello to Suresh Ramasubramanian :-)
Christopher Chan
2010-04-26 01:27:31 UTC
Permalink
On Monday, April 26, 2010 09:15 AM, NoOp wrote:
> On 04/25/2010 05:38 PM, Christopher Chan wrote:
> ...
>> 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
> ...
>
> Say hello to Suresh Ramasubramanian :-)
>
>


SBC Global...you were on SPAM-L while that was still running I take it?
NoOp
2010-04-26 02:19:56 UTC
Permalink
On 04/25/2010 06:27 PM, Christopher Chan wrote:
> On Monday, April 26, 2010 09:15 AM, NoOp wrote:
...
> Say hello to Suresh Ramasubramanian :-)

> SBC Global...you were on SPAM-L while that was still running I take it?
>

Let's just say that I wasn't a spammer & at that time SBC Global didn't
much exist... :-)
Christopher Chan
2010-04-26 02:43:42 UTC
Permalink
On Monday, April 26, 2010 10:19 AM, NoOp wrote:
> On 04/25/2010 06:27 PM, Christopher Chan wrote:
>> On Monday, April 26, 2010 09:15 AM, NoOp wrote:
> ...
>> Say hello to Suresh Ramasubramanian :-)

Cor, I forgot you spelt his surname correctly!

>
>> SBC Global...you were on SPAM-L while that was still running I take it?
>>
>
> Let's just say that I wasn't a spammer& at that time SBC Global didn't
> much exist... :-)
>

Hahaha. Rats, I thought I'd get away from the world of cabals but no,
they show up anywhere. DNS and SMTP. Sigh.
Alvin Thompson
2010-04-26 20:15:19 UTC
Permalink
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.
Christopher Chan
2010-04-27 00:53:34 UTC
Permalink
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
Alvin Thompson
2010-04-27 16:23:14 UTC
Permalink
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.

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.

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

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

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

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

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

> 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.
Christopher Chan
2010-04-28 01:01:37 UTC
Permalink
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.
Alvin Thompson
2010-04-28 01:46:44 UTC
Permalink
You last post was pure smokescreen--you keep trying to argue a tangent
point to avoid addressing the actual point. Additionally, repeating what
you previously said is not addressing a point. You added nothing, so I
respond to nothing.
Res
2010-04-26 01:19:28 UTC
Permalink
On Sun, 25 Apr 2010, Alvin Thompson wrote:

>
> I've been a paid software engineer for 20 years, and people use SMTP


Sorry but that means nothing, known plenty to have claimed that, and
many second year uni students easily surpass them.
(not saying your just beating your chest, maybe you are good, but I dont
know you, and I doubt many if any here do well enough to back that claim
up)


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


Alvin, Chris has probably forgotten more about email than most people will
ever learn about it.


--
Res

"What does Windows have that Linux doesn't?" - One hell of a lot of bugs!
Alvin Thompson
2010-04-26 19:31:37 UTC
Permalink
On 04/25/2010 09:19 PM, Res wrote:
> Sorry but that means nothing, known plenty to have claimed that, and
> many second year uni students easily surpass them.
> (not saying your just beating your chest, maybe you are good, but I dont
> know you, and I doubt many if any here do well enough to back that claim
> up)

That's a logical flaw. Debate the points, not the messenger. If a PhD
came up to you and said that 2 plus 2 equals 4, it doesn't make it any
more or less true than if a high school dropout told you.

As I said in another post, you might want to check out my resume on my
web site before you make that assertion.

> Alvin, Chris has probably forgotten more about email than most people will
> ever learn about it.

Apparently not, if he thinks that:

1. HTTP is more reliable than SMTP.
2. SMTP adds too much "parsing overhead" (his words, not mine) for
sending messages. What! Sending messages is SMTP's *job*, so I imagine
the overhead is acceptable.
3. You'll lose mail sent to you if your SMTP server goes down.
4. You need a separate MX entry for each client that uses your mail server.
5. Spam can still get in your queue if the SMTP server requires a valid
client certificate.
6. Mail servers only have one queue.

Those are all ridiculous points he's tried to make.
Christopher Chan
2010-04-27 01:02:37 UTC
Permalink
>> Alvin, Chris has probably forgotten more about email than most people will
>> ever learn about it.
>
> Apparently not, if he thinks that:
>
> 1. HTTP is more reliable than SMTP.

Never said that. Just saying smtp won't necessarily make things any
better for the wireless device remote control wise. Especially if the
device itself is down. But as shown already, Alvin was not thinking
embedded smtp server in device like Chuck was thinking so there is no
right or wrong here.


> 2. SMTP adds too much "parsing overhead" (his words, not mine) for
> sending messages. What! Sending messages is SMTP's *job*, so I imagine
> the overhead is acceptable.

See above.


> 3. You'll lose mail sent to you if your SMTP server goes down.

Like when the device is down long enough for the mta to bounce the email.


> 4. You need a separate MX entry for each client that uses your mail server.

Again, Alvin missed the part where Chuck was thinking of embedding a
smtp server in the devices for accept remote commands via email. Each
device would need either an MX or a host record in DNS.


> 5. Spam can still get in your queue if the SMTP server requires a valid
> client certificate.

Never said that nor did I argue the point of using certificates. If I
were to say something, it would be, this is painful for setting up.


> 6. Mail servers only have one queue.

Which is true depending on mta and setup but I never said mail servers
only have one queue.


>
> Those are all ridiculous points he's tried to make.
>

I am sure we have both provided plenty of amusement for those who are
interested.
Alvin Thompson
2010-04-27 17:43:44 UTC
Permalink
On 04/26/2010 09:02 PM, Christopher Chan wrote:
>> 1. HTTP is more reliable than SMTP.
>
> Never said that. ...

Technically, you're right. But you certainly very strongly implied, on
several occasions, that SMTP was *less* reliable than HTTP. Otherwise,
we wouldn't be having this conversion.

>> 2. SMTP adds too much "parsing overhead" (his words, not mine) for
>> sending messages. What! Sending messages is SMTP's *job*, so I imagine
>> the overhead is acceptable.
>
> See above.

<quote who="Christopher Chan">
Hmm, none of them chose to use an existing protocol like smtp with its
email parsing overhead.
</quote>

>> 3. You'll lose mail sent to you if your SMTP server goes down.
>
> Like when the device is down long enough for the mta to bounce the email.

Not true:

1. The backup server will get the mail.

2. If you for some reason don't have a backup server, It will by default
take around 5 DAYS or more for the sending mail server to give up. I
imagine most people can get a mail server up and running in 5 days, even
if they have to buy and assemble a new computer.

3. If you for some reason don't have a backup server, AND if you can't
get the computer up and running in 5 days, the mail isn't lost. It's
returned to the sender.

4. If you for some reason don't have a backup server, AND if for some
reason you don't think you can get your mail server running in 5 days,
AND you don't want the mail simply to be returned, you can configure the
sending mail server to never give up.

But I'll concede this point: if you live in an alternate universe where
Bizarro Superman exists, and Bizzaro Superman destroys your mail server
and any backup servers, and every time another mail server tries to send
a message to your server (which Bizzaro Superman already destroyed),
Bizzaro Superman flies around the planet really fast to turn back time,
and then finds the sending server and destroys it, then you'll lose mail.

>> 4. You need a separate MX entry for each client that uses your mail server.
>
> Again, Alvin missed the part where Chuck was thinking of embedding a
> smtp server in the devices for accept remote commands via email. Each
> device would need either an MX or a host record in DNS.

Not true. http://www.postfix.org/postconf.5.html#transport_maps

>> 5. Spam can still get in your queue if the SMTP server requires a valid
>> client certificate.
>
> Never said that nor did I argue the point of using certificates. If I
> were to say something, it would be, this is painful for setting up.

<quote who="Christopher Chan">
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?
</quote>

>> 6. Mail servers only have one queue.
>
> Which is true depending on mta and setup but I never said mail servers
> only have one queue.

<quote who="Christopher Chan">
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?
</quote>

At the very least, you have substantial misconceptions on how the queues
work,if you think a flood of bounces or spam will stop mail from getting
through.
Christopher Chan
2010-04-28 01:31:51 UTC
Permalink
On Wednesday, April 28, 2010 01:43 AM, Alvin Thompson wrote:
> On 04/26/2010 09:02 PM, Christopher Chan wrote:
>>> 1. HTTP is more reliable than SMTP.
>>
>> Never said that. ...
>
> Technically, you're right. But you certainly very strongly implied, on
> several occasions, that SMTP was *less* reliable than HTTP. Otherwise,
> we wouldn't be having this conversion.

No, I was just pointing out that your supposed reliability can be
affected by external factors and if time taken was part of the
reliability, it might not fit.


>
>>> 2. SMTP adds too much "parsing overhead" (his words, not mine) for
>>> sending messages. What! Sending messages is SMTP's *job*, so I imagine
>>> the overhead is acceptable.
>>
>> See above.
>
> <quote who="Christopher Chan">
> Hmm, none of them chose to use an existing protocol like smtp with its
> email parsing overhead.
> </quote>

Well yeah. There is an overhead whether you use smtp, pop or imap as
opposed to using your own protocol for commands. After using whatever
protocol, you still have extra work to do to extract the email and strip
off its headers, check the body for commands before carrying it out.
With your own protocol, the command comes through IN the tcp session.
And don't forget the context like you love doing: my specious wireless
access point assumption.


>
>>> 3. You'll lose mail sent to you if your SMTP server goes down.
>>
>> Like when the device is down long enough for the mta to bounce the email.
>
> Not true:
>
> 1. The backup server will get the mail.
>
> 2. If you for some reason don't have a backup server, It will by default
> take around 5 DAYS or more for the sending mail server to give up. I
> imagine most people can get a mail server up and running in 5 days, even
> if they have to buy and assemble a new computer.
>
> 3. If you for some reason don't have a backup server, AND if you can't
> get the computer up and running in 5 days, the mail isn't lost. It's
> returned to the sender.
>
> 4. If you for some reason don't have a backup server, AND if for some
> reason you don't think you can get your mail server running in 5 days,
> AND you don't want the mail simply to be returned, you can configure the
> sending mail server to never give up.
>
> But I'll concede this point: if you live in an alternate universe where
> Bizarro Superman exists, and Bizzaro Superman destroys your mail server
> and any backup servers, and every time another mail server tries to send
> a message to your server (which Bizzaro Superman already destroyed),
> Bizzaro Superman flies around the planet really fast to turn back time,
> and then finds the sending server and destroys it, then you'll lose mail.

Sorry, you are living in the past. Today, it is 'it depends'. External
factors chap. A lot of mail servers are configured to bounce within a
day or even shorter. People already assume email to instantaneous and so
getting a bounce five days later for whatever reason is no longer
acceptable.


>
>>> 4. You need a separate MX entry for each client that uses your mail server.
>>
>> Again, Alvin missed the part where Chuck was thinking of embedding a
>> smtp server in the devices for accept remote commands via email. Each
>> device would need either an MX or a host record in DNS.
>
> Not true. http://www.postfix.org/postconf.5.html#transport_maps

/me rotfl. So you expect Chuck's potential customers for his wireless
remote controlled toy to have to clue to setup a routing for the thing?
I don't know why you want to throw whatever you can think of at me
without considering what might be the possible customers of Chuck. I did
not pass off your report about Lucid trashing data as some freak
accident or PEBCAS like others did.


>
>>> 5. Spam can still get in your queue if the SMTP server requires a valid
>>> client certificate.
>>
>> Never said that nor did I argue the point of using certificates. If I
>> were to say something, it would be, this is painful for setting up.
>
> <quote who="Christopher Chan">
> 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?
> </quote>

Right...who requires valid client certificates on their mxs? When you
find an example, do let me know. And of course, we want to do this so
that we can remote control a wireless capable toy via email.


>
>>> 6. Mail servers only have one queue.
>>
>> Which is true depending on mta and setup but I never said mail servers
>> only have one queue.
>
> <quote who="Christopher Chan">
> 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?
> </quote>
>
> At the very least, you have substantial misconceptions on how the queues
> work,if you think a flood of bounces or spam will stop mail from getting
> through.
>

You've never seen mail servers reporting disk full I take it. Of course,
that is a moot point now. You are right. Using smtp, pop or imap is the
way to go for remote control of a wireless/wired device. I am amazed
that nobody has implemented such a great idea. I bow to your 20 years of
software engineering.
Alvin Thompson
2010-04-28 01:52:43 UTC
Permalink
On 04/27/2010 09:31 PM, Christopher Chan wrote:
> You've never seen mail servers reporting disk full I take it. Of course,
> that is a moot point now. You are right. Using smtp, pop or imap is the
> way to go for remote control of a wireless/wired device. I am amazed
> that nobody has implemented such a great idea. I bow to your 20 years of
> software engineering.

Actually, they have. Read my previous post on being able to use SMTP as
the underlying transport for servlets and web services. JMS also uses
some of the exact same principles.
Christopher Chan
2010-04-28 02:20:15 UTC
Permalink
On Wednesday, April 28, 2010 09:52 AM, Alvin Thompson wrote:
> On 04/27/2010 09:31 PM, Christopher Chan wrote:
>> You've never seen mail servers reporting disk full I take it. Of course,
>> that is a moot point now. You are right. Using smtp, pop or imap is the
>> way to go for remote control of a wireless/wired device. I am amazed
>> that nobody has implemented such a great idea. I bow to your 20 years of
>> software engineering.
>
> Actually, they have. Read my previous post on being able to use SMTP as
> the underlying transport for servlets and web services. JMS also uses
> some of the exact same principles.
>

You still have not made a case for embedding such in a wireless/wired
printer,projector,toy,TV,whatever home/corporate device for remote
control. Your example also is rather ironic in that I proposed http as
an interface for remote control and that is just what your SERVLETS and
WEB servers are which you were trying hard to trounce. Email for remote
control might be a nice plus in edge cases.
Chuck Kuecker
2010-04-28 11:09:57 UTC
Permalink
Christopher Chan wrote:
> On Wednesday, April 28, 2010 09:52 AM, Alvin Thompson wrote:
>
>> On 04/27/2010 09:31 PM, Christopher Chan wrote:
>>
>>> You've never seen mail servers reporting disk full I take it. Of course,
>>> that is a moot point now. You are right. Using smtp, pop or imap is the
>>> way to go for remote control of a wireless/wired device. I am amazed
>>> that nobody has implemented such a great idea. I bow to your 20 years of
>>> software engineering.
>>>
>> Actually, they have. Read my previous post on being able to use SMTP as
>> the underlying transport for servlets and web services. JMS also uses
>> some of the exact same principles.
>>
>>
>
> You still have not made a case for embedding such in a wireless/wired
> printer,projector,toy,TV,whatever home/corporate device for remote
> control. Your example also is rather ironic in that I proposed http as
> an interface for remote control and that is just what your SERVLETS and
> WEB servers are which you were trying hard to trounce. Email for remote
> control might be a nice plus in edge cases.
>
>
Wow. I started something here.

I just now got back on-line after having to spend three days backing up
my Windoze 2000 computer (which handles and archives my incoming emails)
so I could install Windoze XP -which is required to run one of my new
debugger pods. It's sorta working.

It's going to take me a while to absorb this thread. Looks like I've got
some reading to do!

:)

Chuck Kuecker
Chan Chung Hang Christopher
2010-04-28 12:57:48 UTC
Permalink
> Wow. I started something here.

Nothing much.


>
> I just now got back on-line after having to spend three days backing up
> my Windoze 2000 computer (which handles and archives my incoming emails)
> so I could install Windoze XP -which is required to run one of my new
> debugger pods. It's sorta working.
>
> It's going to take me a while to absorb this thread. Looks like I've got
> some reading to do!

Really comes down to http is definitely on and whether you really would
like to offer remote control/commands via email for the clueful and
choosing between a more user friendly pop/imap option the less clueful
or embedding an mta to accept email for those who are willing to setup
the infrastructure. Checking a mailbox for commands is probably the
simplest way of receiving commands from the user when the user is not at
home and does not know how to setup a vpn, ddns, or port forwarding.

If your devices talk to each other and negotiate stuff, then also a
custom protocol or as per Alvin's insistence you could use mdns/bonjour
and smtp I suppose. Maybe he can explain he gets his servlets/web
services to be remote controlled by smtp.
Alvin Thompson
2010-04-28 19:30:31 UTC
Permalink
On 04/28/2010 08:57 AM, Chan Chung Hang Christopher wrote:
> Really comes down to http is definitely on and whether you really would
> like to offer remote control/commands via email for the clueful and
> choosing between a more user friendly pop/imap option the less clueful
> or embedding an mta to accept email for those who are willing to setup
> the infrastructure. Checking a mailbox for commands is probably the
> simplest way of receiving commands from the user when the user is not at
> home and does not know how to setup a vpn, ddns, or port forwarding.

This isn't very well worded, so I'm not sure exactly what you're trying
to say, but it seems that you're now reversing course and agreeing that
using a mail server to receive the messages would be less complex than
trying to set up a peer-to-peer network?

> If your devices talk to each other and negotiate stuff, then also a
> custom protocol or as per Alvin's insistence you could use mdns/bonjour
> and smtp I suppose. Maybe he can explain he gets his servlets/web
> services to be remote controlled by smtp.

As I mentioned in a previous post, J2EE would be too heavyweight for
this application. But yes, servlets and webservices can be decoupled
from the transport layer. They were designed that way, and you can use
any transport you want. You could use x-modem if you wanted.
Christopher Chan
2010-04-29 00:43:41 UTC
Permalink
On Thursday, April 29, 2010 03:30 AM, Alvin Thompson wrote:
> On 04/28/2010 08:57 AM, Chan Chung Hang Christopher wrote:
>> Really comes down to http is definitely on and whether you really would
>> like to offer remote control/commands via email for the clueful and
>> choosing between a more user friendly pop/imap option the less clueful
>> or embedding an mta to accept email for those who are willing to setup
>> the infrastructure. Checking a mailbox for commands is probably the
>> simplest way of receiving commands from the user when the user is not at
>> home and does not know how to setup a vpn, ddns, or port forwarding.
>
> This isn't very well worded, so I'm not sure exactly what you're trying
> to say, but it seems that you're now reversing course and agreeing that
> using a mail server to receive the messages would be less complex than
> trying to set up a peer-to-peer network?

Hahaha, you have got to be kidding. How are you supposed to discover
other devices via smtp to get peer-to-peer working? Oh, I know, push all
that to the user just like making the user set up mailboxes per device
or setup dns so that the things can get their messages. Let the user
sort it out. Brilliant! This thing is so going to sell. Nah, I am all
for a custom protocol + gui and http for remote control. Forget smtp.
Maybe pop3 or imap but I won't make that a selling point.


>
>> If your devices talk to each other and negotiate stuff, then also a
>> custom protocol or as per Alvin's insistence you could use mdns/bonjour
>> and smtp I suppose. Maybe he can explain he gets his servlets/web
>> services to be remote controlled by smtp.
>
> As I mentioned in a previous post, J2EE would be too heavyweight for
> this application. But yes, servlets and webservices can be decoupled
> from the transport layer. They were designed that way, and you can use
> any transport you want. You could use x-modem if you wanted.
>

Are your servlets/web services at all remote controlled via smtp or do
you just send reports over smtp?
Alvin Thompson
2010-04-29 04:18:22 UTC
Permalink
On 04/28/2010 08:43 PM, Christopher Chan wrote:
> Hahaha, you have got to be kidding. How are you supposed to discover
> other devices via smtp to get peer-to-peer working? Oh, I know, push all
> that to the user just like making the user set up mailboxes per device
> or setup dns so that the things can get their messages. Let the user
> sort it out. Brilliant! This thing is so going to sell. Nah, I am all
> for a custom protocol + gui and http for remote control. Forget smtp.
> Maybe pop3 or imap but I won't make that a selling point.

Specious. You would have to resolve exactly those same issues if you
used HTTP or a custom protocol. The only difference is that you would
have to write any reliability code yourself.

>> As I mentioned in a previous post, J2EE would be too heavyweight for
>> this application. But yes, servlets and webservices can be decoupled
>> from the transport layer. They were designed that way, and you can use
>> any transport you want. You could use x-modem if you wanted.
>>
>
> Are your servlets/web services at all remote controlled via smtp or do
> you just send reports over smtp?

Trying to go off on another tangent argument again?
Christopher Chan
2010-04-29 04:45:58 UTC
Permalink
On Thursday, April 29, 2010 12:18 PM, Alvin Thompson wrote:
> On 04/28/2010 08:43 PM, Christopher Chan wrote:
>> Hahaha, you have got to be kidding. How are you supposed to discover
>> other devices via smtp to get peer-to-peer working? Oh, I know, push all
>> that to the user just like making the user set up mailboxes per device
>> or setup dns so that the things can get their messages. Let the user
>> sort it out. Brilliant! This thing is so going to sell. Nah, I am all
>> for a custom protocol + gui and http for remote control. Forget smtp.
>> Maybe pop3 or imap but I won't make that a selling point.
>
> Specious. You would have to resolve exactly those same issues if you
> used HTTP or a custom protocol. The only difference is that you would
> have to write any reliability code yourself.

1) Nobody uses http for discovering other devices and I never said that.

2) There are custom protocols that eventually became standard protocols
for discovering other devices. That is what switches and routers use
today. If email or smtp were suitable to this task, they would long ago
have used it or extended it for this purpose. Call it specious all you
like, no one is ever going to use smtp or email for peer to peer
communication between devices except maybe you.


>
>>> As I mentioned in a previous post, J2EE would be too heavyweight for
>>> this application. But yes, servlets and webservices can be decoupled
>>> from the transport layer. They were designed that way, and you can use
>>> any transport you want. You could use x-modem if you wanted.
>>>
>>
>> Are your servlets/web services at all remote controlled via smtp or do
>> you just send reports over smtp?
>
> Trying to go off on another tangent argument again?
>

What's the matter? You cannot even say a simple yes, I use smtp to
remote control my web services/servlets or no, I actually just send
reports only at the moment?
Alvin Thompson
2010-04-29 17:46:44 UTC
Permalink
On 04/29/2010 12:45 AM, Christopher Chan wrote:
>> Specious. You would have to resolve exactly those same issues if you
>> used HTTP or a custom protocol. The only difference is that you would
>> have to write any reliability code yourself.
>
> 1) Nobody uses http for discovering other devices and I never said that.

That's funny, because I don't remember ever saying that people used SMTP
for discovering other services, either. Yet you somehow thought it was a
valid argument when *you* used it JUST ONE POST AGO:

<quote who="Christopher Chan>
Hahaha, you have got to be kidding. How are you supposed to discover
other devices via smtp to get peer-to-peer working?
</quote>

So back to my original point which, of course, you never addressed: You
would have to resolve exactly those same issues if you used HTTP or a
custom protocol. The only difference is that you would have to write any
reliability code yourself.

> 2) There are custom protocols that eventually became standard protocols
> for discovering other devices. That is what switches and routers use
> today. If email or smtp were suitable to this task, they would long ago
> have used it or extended it for this purpose. Call it specious all you
> like, no one is ever going to use smtp or email for peer to peer
> communication between devices except maybe you.

First of all, so your argument really is, "you shouldn't do it because
nobody has done it before?"

Second, I've already told you several times that people (not just I)
have done it before. You simply choose not to believe it. People have
also invented machines that allow them to fly. Do you choose not to
believe that as well?

> What's the matter? You cannot even say a simple yes, I use smtp to
> remote control my web services/servlets or no, I actually just send
> reports only at the moment?

I've already answered that several times, including IN THE PREVIOUS
POST. Once again, pretending you never heard something is not the best
way to win an argument.
Christopher Chan
2010-04-30 01:37:22 UTC
Permalink
On Friday, April 30, 2010 01:46 AM, Alvin Thompson wrote:
> On 04/29/2010 12:45 AM, Christopher Chan wrote:
>>> Specious. You would have to resolve exactly those same issues if you
>>> used HTTP or a custom protocol. The only difference is that you would
>>> have to write any reliability code yourself.
>>
>> 1) Nobody uses http for discovering other devices and I never said that.
>
> That's funny, because I don't remember ever saying that people used SMTP
> for discovering other services, either. Yet you somehow thought it was a
> valid argument when *you* used it JUST ONE POST AGO:
>
> <quote who="Christopher Chan>
> Hahaha, you have got to be kidding. How are you supposed to discover
> other devices via smtp to get peer-to-peer working?
> </quote>

Maybe for those who don't understand English very well this might be
misconstrued as believing smtp can be used for discovering other devices.


>
> So back to my original point which, of course, you never addressed: You
> would have to resolve exactly those same issues if you used HTTP or a
> custom protocol. The only difference is that you would have to write any
> reliability code yourself.

Amazing that there is not a protocol today that does discovery that is
unicast like http and smtp. Perhaps Alvin the Great Software Engineer
will be the one to come up with the first unicast protocol that does
discovery.


>
>> 2) There are custom protocols that eventually became standard protocols
>> for discovering other devices. That is what switches and routers use
>> today. If email or smtp were suitable to this task, they would long ago
>> have used it or extended it for this purpose. Call it specious all you
>> like, no one is ever going to use smtp or email for peer to peer
>> communication between devices except maybe you.
>
> First of all, so your argument really is, "you shouldn't do it because
> nobody has done it before?"

Of course. You are free to take all the glory by coming up with the
first unicast protocol that is used for peer-to-peer discovery. It is
not like it is not impossible I know.


>
> Second, I've already told you several times that people (not just I)
> have done it before. You simply choose not to believe it. People have
> also invented machines that allow them to fly. Do you choose not to
> believe that as well?

Too bad you are the only example of someone claiming to use smtp for
remote control. Since you say that people have done it before, then feel
free to provide links.


>
>> What's the matter? You cannot even say a simple yes, I use smtp to
>> remote control my web services/servlets or no, I actually just send
>> reports only at the moment?
>
> I've already answered that several times, including IN THE PREVIOUS
> POST. Once again, pretending you never heard something is not the best
> way to win an argument.
>

Yeah, yeah, I have no interest in winning an argument. In fact, feel
free to prove me wrong with some evidence of people using smtp for
remote control.
Alvin Thompson
2010-04-30 18:54:39 UTC
Permalink
On 04/29/2010 09:37 PM, Christopher Chan wrote:
> Too bad you are the only example of someone claiming to use smtp for
> remote control. Since you say that people have done it before, then feel
> free to provide links.
...
> Yeah, yeah, I have no interest in winning an argument. In fact, feel
> free to prove me wrong with some evidence of people using smtp for
> remote control.

Um...well, golly...how about...THIS THREAD? That's what Chuck was trying
to use SMTP for, and it seemed like a perfectly reasonable solution to
him...

Oh wait...what is this we're communicating on? Oh, that's right: A
MAILING LIST! And how does 90% of the mailing list software out there
get controlled? BY SENDING EMAIL TO IT!

I'm sure a successful business person like you (you must be successful,
because you're so smart, articulate, and well-reasoned) has heard of a
little something called Microsoft Exchange? And on Microsoft Exchange
have you seen the calendars? And how can you remotely add to someone's
calendar? BY SENDING AN EMAIL MEETING REQUEST, which Exchange receives
and uses the information in it to update the calendar.

With most issue management software out there (including launchpad), you
can update the status of issues by SENDING EMAIL TO IT.

You can email some internet-aware DVR's out there to record your shows.
In fact, I seem to remember a commercial very recently about two guys
who were caught in a robbery in a bank, but one of the guys sent a
message to his DVR so he wouldn't miss his shows. Perhaps you saw it...

There are "Shopping List" apps you can run on your pda/phone, where if
you're at the market, and your wife (elsewhere) wants to add something
to your shopping list, she can send an SMS (same principle) to the app
on your phone, and it updates your shopping list.

To confirm registration on many web sites, they send you an email. Then
you have to send them a reply email (or often you can also click on a
link). You're controlling that registration software with that email.

With most document routing software, you can approve or disapprove of a
document by sending a reply email.
Chan Chung Hang Christopher
2010-05-02 14:09:45 UTC
Permalink
Alvin Thompson wrote:
> On 04/29/2010 09:37 PM, Christopher Chan wrote:
>> Too bad you are the only example of someone claiming to use smtp for
>> remote control. Since you say that people have done it before, then feel
>> free to provide links.
> ...
>> Yeah, yeah, I have no interest in winning an argument. In fact, feel
>> free to prove me wrong with some evidence of people using smtp for
>> remote control.
>
> Um...well, golly...how about...THIS THREAD? That's what Chuck was trying
> to use SMTP for, and it seemed like a perfectly reasonable solution to
> him...
>
> Oh wait...what is this we're communicating on? Oh, that's right: A
> MAILING LIST! And how does 90% of the mailing list software out there
> get controlled? BY SENDING EMAIL TO IT!
>
> I'm sure a successful business person like you (you must be successful,
> because you're so smart, articulate, and well-reasoned) has heard of a
> little something called Microsoft Exchange? And on Microsoft Exchange
> have you seen the calendars? And how can you remotely add to someone's
> calendar? BY SENDING AN EMAIL MEETING REQUEST, which Exchange receives
> and uses the information in it to update the calendar.
>
> With most issue management software out there (including launchpad), you
> can update the status of issues by SENDING EMAIL TO IT.
>
> You can email some internet-aware DVR's out there to record your shows.
> In fact, I seem to remember a commercial very recently about two guys
> who were caught in a robbery in a bank, but one of the guys sent a
> message to his DVR so he wouldn't miss his shows. Perhaps you saw it...
>
> There are "Shopping List" apps you can run on your pda/phone, where if
> you're at the market, and your wife (elsewhere) wants to add something
> to your shopping list, she can send an SMS (same principle) to the app
> on your phone, and it updates your shopping list.
>
> To confirm registration on many web sites, they send you an email. Then
> you have to send them a reply email (or often you can also click on a
> link). You're controlling that registration software with that email.
>
> With most document routing software, you can approve or disapprove of a
> document by sending a reply email.
>

Ooh, bravo! You win! OH wait a minute...none of these examples actually
do the remote control in smtp. But great list of email related remote
controlled server software. I really loved the mailing list one. I mean,
how could I ever forget the one application that can cause tons of
contention between email administrators. Funny how the only possible
device that might be similar to Chuck's project seems to be the DVR.
Must be Geek Heaven to have to set up dns records or smtp routing
somewhere to get the email to the DVR.

Oh, and thanks for completely forgetting about discovery of fellow
devices, you know, the main thrust of the post that your reply was sent
to? Nevermind, I know, just because it has not been done is not a good
enough reason not to do it with smtp. Anyway, you win, people routinely
do remote control with email. Happy?
Alvin Thompson
2010-05-02 20:20:11 UTC
Permalink
On 05/02/2010 10:09 AM, Chan Chung Hang Christopher wrote:
> Oh, and thanks for completely forgetting about discovery of fellow
> devices, you know, the main thrust of the post that your reply was sent
> to? Nevermind, I know, just because it has not been done is not a good
> enough reason not to do it with smtp. Anyway, you win, people routinely
> do remote control with email. Happy?

For the third time, that's not a valid argument because you have to
worry about discovery no matter what protocol you use. What part of
that simple, basic logic don't you understand?

This isn't even fun anymore because it's too easy. You don't ever learn
anything; you just blunder into the same mistakes over and over again.
The only reason I continued this whole exercise is that I thought you
might learn something, if not about admitting you were wrong, then at
least about using your brain to frame arguments logically and properly.
Well, I guess the joke was on me because it was clearly a total waste of
time.
Alvin Thompson
2010-04-28 19:01:19 UTC
Permalink
You don't have to read the whole thread; what it basically boils down to
is the statements below. The givens are that you need to send messages
from (or to) this device, it's the device that's automatically sending
or receiving the messages, not the user, and your choices of technology
is a mail server (SMTP) or a web server (HTTP):

1. I believe that the mail server (SMTP) is a better choice, because the
protocol is more reliable.

2. Mr. Chan believes that how much more reliable SMTP is over HTTP is
disputable, and any increase in reliability by using SMTP is not worth
the added complexity.

"Reliability" is defined, for our purposes, as the ability for a message
to get through to its destination, without human intervention, in the
presence of foreseeable obstacles. For example, if the network
connection goes down.

Most of the debate has centered on how much more reliable SMTP really
is, and how much more complexity SMTP really adds (if any) over HTTP.

Chris, would you agree that's a fair assessment?
Christopher Chan
2010-04-29 00:32:14 UTC
Permalink
On Thursday, April 29, 2010 03:01 AM, Alvin Thompson wrote:
> You don't have to read the whole thread; what it basically boils down to
> is the statements below. The givens are that you need to send messages
> from (or to) this device, it's the device that's automatically sending
> or receiving the messages, not the user, and your choices of technology
> is a mail server (SMTP) or a web server (HTTP):

He did not say he 'needs' to send messages to the device. He was mulling
over what he should use for remote control of it which can be done by
connecting to it by http or by getting a message to it.


>
> 1. I believe that the mail server (SMTP) is a better choice, because the
> protocol is more reliable.

You don't even know the needs and you have come to a conclusion?


>
> 2. Mr. Chan believes that how much more reliable SMTP is over HTTP is
> disputable, and any increase in reliability by using SMTP is not worth
> the added complexity.

Like when this is a product for the home. Setting up a smtp daemon to
accept messages is not going to fly for the majority out there.
Supporting a dedicated mailbox that can be accessed by pop3 or imap
might fly since you are adding support for sending email out via
smtp-auth if necessary so I take it you target users that are savvy enough.


>
> "Reliability" is defined, for our purposes, as the ability for a message
> to get through to its destination, without human intervention, in the
> presence of foreseeable obstacles. For example, if the network
> connection goes down.

There is also the question of time depending on case need and in fact
whether this 'extra' reliability is wanted.


>
> Most of the debate has centered on how much more reliable SMTP really
> is, and how much more complexity SMTP really adds (if any) over HTTP.
>
> Chris, would you agree that's a fair assessment?
>

Nope. I'd say, "Forget http, go smtp" is your angle and I was entirely
focused on the extra work needed for smtp to work and other potential
issues depending on case need whereas I should have just said: "email
for remote control is a nice extra for edge cases but http is absolutely
essential" and you were making it out that there are plenty of stuff
that can be done to ensure that smtp is more reliable than http and
therefore should be the only solution.

You and I would have no problem setting up whatever infrastructure
necessary for remote control via email be it a mailbox per device or dns
or specific routing rules so that emails would actually reach the
devices. But I would not bother with a device that uses email as its
sole method of remote control. I doubt that many would like to first
setup a dedicated pop3/imap mailbox just for that let alone all the
other stuff necessary if it used an smtp daemon.
Alvin Thompson
2010-04-29 04:20:16 UTC
Permalink
Dude, what is wrong with you?

On 04/28/2010 08:32 PM, Christopher Chan wrote:
> On Thursday, April 29, 2010 03:01 AM, Alvin Thompson wrote:
>> You don't have to read the whole thread; what it basically boils down to
>> is the statements below. The givens are that you need to send messages
>> from (or to) this device, it's the device that's automatically sending
>> or receiving the messages, not the user, and your choices of technology
>> is a mail server (SMTP) or a web server (HTTP):
>
> He did not say he 'needs' to send messages to the device. He was mulling
> over what he should use for remote control of it which can be done by
> connecting to it by http or by getting a message to it.
>
>
>>
>> 1. I believe that the mail server (SMTP) is a better choice, because the
>> protocol is more reliable.
>
> You don't even know the needs and you have come to a conclusion?
>
>
>>
>> 2. Mr. Chan believes that how much more reliable SMTP is over HTTP is
>> disputable, and any increase in reliability by using SMTP is not worth
>> the added complexity.
>
> Like when this is a product for the home. Setting up a smtp daemon to
> accept messages is not going to fly for the majority out there.
> Supporting a dedicated mailbox that can be accessed by pop3 or imap
> might fly since you are adding support for sending email out via
> smtp-auth if necessary so I take it you target users that are savvy enough.
>
>
>>
>> "Reliability" is defined, for our purposes, as the ability for a message
>> to get through to its destination, without human intervention, in the
>> presence of foreseeable obstacles. For example, if the network
>> connection goes down.
>
> There is also the question of time depending on case need and in fact
> whether this 'extra' reliability is wanted.
>
>
>>
>> Most of the debate has centered on how much more reliable SMTP really
>> is, and how much more complexity SMTP really adds (if any) over HTTP.
>>
>> Chris, would you agree that's a fair assessment?
>>
>
> Nope. I'd say, "Forget http, go smtp" is your angle and I was entirely
> focused on the extra work needed for smtp to work and other potential
> issues depending on case need whereas I should have just said: "email
> for remote control is a nice extra for edge cases but http is absolutely
> essential" and you were making it out that there are plenty of stuff
> that can be done to ensure that smtp is more reliable than http and
> therefore should be the only solution.
>
> You and I would have no problem setting up whatever infrastructure
> necessary for remote control via email be it a mailbox per device or dns
> or specific routing rules so that emails would actually reach the
> devices. But I would not bother with a device that uses email as its
> sole method of remote control. I doubt that many would like to first
> setup a dedicated pop3/imap mailbox just for that let alone all the
> other stuff necessary if it used an smtp daemon.
>
Chuck Kuecker
2010-04-30 08:06:08 UTC
Permalink
Alvin Thompson wrote:
> You don't have to read the whole thread; what it basically boils down to
> is the statements below. The givens are that you need to send messages
> from (or to) this device, it's the device that's automatically sending
> or receiving the messages, not the user, and your choices of technology
> is a mail server (SMTP) or a web server (HTTP):
>
> 1. I believe that the mail server (SMTP) is a better choice, because the
> protocol is more reliable.
>
> 2. Mr. Chan believes that how much more reliable SMTP is over HTTP is
> disputable, and any increase in reliability by using SMTP is not worth
> the added complexity.
>
> "Reliability" is defined, for our purposes, as the ability for a message
> to get through to its destination, without human intervention, in the
> presence of foreseeable obstacles. For example, if the network
> connection goes down.
>
> Most of the debate has centered on how much more reliable SMTP really
> is, and how much more complexity SMTP really adds (if any) over HTTP.
>
> Chris, would you agree that's a fair assessment?
>
>
Well, I found 'mailsend', a small command line mail send client - it
seems to work for me. Receiving is another issue.

I tried to port 'sendmail' over, but have issues with the ARM build.
Once those are resolved, I will have email capability.

The build I am working with has Apache already in there, so hosting a
web page won't be an issue.From what I already know about Apache, it is
quite complex by itself already. :)

Thanks for the help, and the entertainment!

Chuck Kuecker
Christopher Chan
2010-04-30 07:27:09 UTC
Permalink
> Thanks for the help, and the entertainment!
>

Any time Chuck! I'm sure Alvin will oblige next time!

:-D
Alvin Thompson
2010-04-30 18:09:23 UTC
Permalink
On 04/30/2010 04:06 AM, Chuck Kuecker wrote:
> Well, I found 'mailsend', a small command line mail send client - it
> seems to work for me. Receiving is another issue.
>
> I tried to port 'sendmail' over, but have issues with the ARM build.
> Once those are resolved, I will have email capability.
>
> The build I am working with has Apache already in there, so hosting a
> web page won't be an issue.From what I already know about Apache, it is
> quite complex by itself already. :)
>
> Thanks for the help, and the entertainment!
>
> Chuck Kuecker

Yup. You should probably also check out "nullmailer", which I mentioned
in another post. It should port easily enough.
Alvin Thompson
2010-04-22 23:27:15 UTC
Permalink
On 04/22/2010 09:30 AM, Chan Chung Hang Christopher wrote:
> Where did you point your embedded system to send email? 192.168.x.x or
> something else?

Give that man a gold star!
Markus Schönhaber
2010-04-22 16:48:00 UTC
Permalink
22.04.2010 16:10, Chuck Kuecker:

> Markus Sch?nhaber wrote:

>> Above, you said that the embedded system is in your local network. But
>> this log excerpt shows a client connecting from 66.254.194.29, i. e. an
>> IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
>> contained in the IP ranges you configured as mynetworks and
>> permit_mynetworks doesn't apply.
>>
>>
> OK. I see that. 66.254.194.29 is my static IP from my ISP. When I
> resolve 'mail.ckent.org', that's what comes up. I certainly don't want
> just anyone sending email to that IP to be able to relay!

That's all fine, but I don't see why your embedded device should connect
to your mail server *from* 66.254.194.29 - unless the mailserver the log
excerpt comes from is outside of your local net.

Maybe you should provide some info about how your network is set up and
which mailserver you try to access how.

> This is what confuses me - my Windoze PC has Thunderbird set up to
> access email via 'mail.ckent.org', and it's on my local network, just
> like the embedded gadget and the Linux box hosting 'mail.ckent.org'. Why
> does the PC connect reliably, but the embedded gadget fails reliably?

Probably because Thunderbird on your PC is, as you said before,
configured to authenticate to the mail server, while your embedded
gadget isn't.
The smtpd_recipient_restrictions contains permit_sasl_authenticated
before reject_unauth_destination, which means that authenticated users
may relay.

--
Regards
mks
Christopher Chan
2010-04-23 01:52:26 UTC
Permalink
On Friday, April 23, 2010 12:48 AM, Markus Sch?nhaber wrote:
> 22.04.2010 16:10, Chuck Kuecker:
>
>> Markus Sch?nhaber wrote:
>
>>> Above, you said that the embedded system is in your local network. But
>>> this log excerpt shows a client connecting from 66.254.194.29, i. e. an
>>> IP that is neither in 127.0.0.0/8 nor 192.168.0.0/16. Therefore it's not
>>> contained in the IP ranges you configured as mynetworks and
>>> permit_mynetworks doesn't apply.
>>>
>>>
>> OK. I see that. 66.254.194.29 is my static IP from my ISP. When I
>> resolve 'mail.ckent.org', that's what comes up. I certainly don't want
>> just anyone sending email to that IP to be able to relay!
>
> That's all fine, but I don't see why your embedded device should connect
> to your mail server *from* 66.254.194.29 - unless the mailserver the log
> excerpt comes from is outside of your local net.
>
> Maybe you should provide some info about how your network is set up and
> which mailserver you try to access how.
>

It is simple really. He has a static ip which he uses for his domain mx.

Therefore, the ubuntu box is the natting gateway for his network which
also runs the postfix in question for his domain and has an internal ip
address of 192.168.0.200 which may or may not be his internal network's
gateway ip address. So when the embedded system connects to his postfix,
it connects to the static ip and the source ip address appears as the
source ip because it has been nat'ed.
Christopher Chan
2010-04-23 01:58:56 UTC
Permalink
> Therefore, the ubuntu box is the natting gateway for his network which
> also runs the postfix in question for his domain and has an internal ip
> address of 192.168.0.200 which may or may not be his internal network's
> gateway ip address. So when the embedded system connects to his postfix,
> it connects to the static ip and the source ip address appears as the
> source ip because it has been nat'ed.
>

correction: source ip appears as the static ip.
Preston Hagar
2010-04-22 15:28:46 UTC
Permalink
On Wed, Apr 21, 2010 at 6:18 PM, Chuck Kuecker <ckuecker at ckent.org> wrote:
> smtpd_recipient_restrictions = reject_unknown_sender_domain,
> reject_unknown_recipient_domain, ? ? ? ?reject_unauth_pipelining,
> permit_mynetworks, ? ? ?permit_sasl_authenticated, ? ? ?reject_unauth_destination
> smtpd_sasl_auth_enable = yes
> mail.log:
>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
> RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
> <addr at dest.com>: Relay access denied; from=<device at ckent.org>
> to=<addr at dest.com> proto=SMTP helo=<ckent.org>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from
>
>
> Chuck
>
> mail.ckent.org[66.254.194.29]
>


Others have had good suggestions and if you are already working them I
would continue, but I would see two things to try:

1st, in your smtpd_recipient_restrictions, put permit_mynetworks
first, followed by permit_sasl_authenticated. I am sure I will get
blased by some for this, but if you can properly restrict your
"mynetworks" only to machines that should be sending email, then it
shouldn't be a real issue. I guess you do have to worry about a virus
on a Windows machine sending out spam using your postfix machine.
Anyway, the main point here is that smtpd_recipient_restrictions is
processed in order. The first rule that matches, wins, so it could be
that your email that is going wrong is matching one of the reject
rules before it even gets to the permit_mynetworks:

http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions

Secondly, (and I am pretty sure others have mentioned this), it looks
like your client is using the external IP for your mailserver. If
they are on the same LAN, either just use the internal IP address for
the email server hostname (easy solution), or setup a split horizon
DNS server (much more complicated) that will resolve your mail
server's hostname to the internal IP for your LAN.

Hope this helps,

Preston
Alvin Thompson
2010-04-22 21:51:19 UTC
Permalink
On 04/21/2010 07:18 PM, Chuck Kuecker wrote:
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: NOQUEUE: reject:
> RCPT from mail.ckent.org[66.254.194.29]: 554 5.7.1
> <addr at dest.com>: Relay access denied; from=<device at ckent.org>
> to=<addr at dest.com> proto=SMTP helo=<ckent.org>
> Apr 21 17:01:40 ckenterprises postfix/smtpd[24088]: disconnect from

Chuck, when connecting from the embedded client to the mail server, you
have to use the local IP address for the mail server
(192.168.0.something). Right now it looks like you're trying to connect
to the mail server with the internet IP address. When you do that, the
mail server can't tell the computer's on the local network, so it
rejects the mails.

Hope this helps,
Alvin
Alvin Thompson
2010-04-21 17:17:57 UTC
Permalink
On 04/21/2010 12:41 PM, Chuck Kuecker wrote:
> The Ubuntu machine relays emails from my Windows machine just fine, but
> when I try to relay an email from an embedded system I am working with,
> that resides on my local network, I get error messages in mail.log -
> 'relay access denied'. Sending email from the embedded system to my
> local email account works fine.
...
> I've enabled the entire local network here in /etc/postfix/main.cf -
> mynetworks = 127.0.0.0/8, 192.168.0.0/16. My Windows machine SMTP is set
> to use TLS, if available, and my user name. I'm thinking that I need to
> send my user name and password somehow, in order to get relaying to
> work. I don't see any SMTP commands that would do this.

You should not have to use a name and password if the computer is on a
trusted network. You've already done the first part (adding your
network to 'mynetworks'). You also need to tell postfix to allow
relaying from those networks. Under 'smtpd_recipient_restrictions',
make sure 'permit_mynetworks' is listed. It probably has to be in a
specific order to work properly. Here's what mine looks like:

smtpd_recipient_restrictions =
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination

Hope that helps,
Alvin


p.s. - if that doesn't work, you will have to post the results of
'postconf -n' as Markus suggested.
Continue reading on narkive:
Loading...