[Top] [All Lists]

Re: [ietf-smtp] Endless debate on IP literals

2020-01-01 21:36:14
On Wed, Jan 01, 2020 at 05:00:45PM -0500, Keith Moore wrote:

1. Connect to port 25 on a configured IP and send email like it's the 90s.
    The local MSA will limit access to suitable IP ranges.

Are we going to specify port 25 for pre-submission and only use 587 for 
"real" submission?   (and see another message about IP address 

No, it is just one option.  The reasons I mention 25 are:

  - It is not uncommon to have port 587 MSAs refuse submission without
    TLS, and not all low-end devices support STARTTLS.

  - Some minimally configurable appliances only support port 25, with
    configuration limited to the relay hostname or IP address.

  - On private corporate networks, the internal mailhub may well not
    offer a separate port 587 service, it just runs a port 25 MSA,
    acting a smarthost for various null-clients.

  - TLS is definitely unavoidable with 465.  Therefore, for bare-bones
    SMTP without TLS, 25 may be a safer bet.  Port 465 has only recently
    been brought back from the dead, deployment is likely comparatively

Not saying I like or dislike the idea - it strikes me that it might be 
the right answer but something still seems odd about it.

Just a pragmatic choice.  A device that is capable of being a TLS client
should be configurable to use 587 and/or 465, but needs to also support

3. Same as 2, but implicit TLS over port 465.

TLS is somewhat problematic for various reasons.   For devices not 
connected to the public Internet, updates are harder, including updates 
to the list of trusted CAs (since old certs will have expired).

Yes, another reason why 25 is a sound minimal default.

Also for machines that don't do DNS, TLS is still possible to use, but
the client needs to know separately what name to use for certificate

Yes, that would need to be configurable, and perhaps also opportunistic
TLS without server authentication.  Which then leaves the question of
which SASL mechanisms to enable when the server connection is not
authenticated, but now we're into advanced features that I would not
expect IoT stacks to get right, unless they license a well designed
client SMTP stack.

But I think challenge-response based on hashed passwords might be 
sufficient for purpose.

Yes, and if device passwords are not also the passwords to the owner's
bank account, social media, email, ... then having it stored on the
server may be OK, but I could mention in passing that a TLS client cert
could work, even if the server is not authenticated (again advanced

A configurable origin domain would be good, the default domain suffix
from DHCP is probably a good bet if nothing better is available.  No
"rewriting", just use a sensible default.

DHCP cannot be assumed.

Indeed, but it is one potential source of identity information for the
SMTP client.  Otherwise local configuration, or built-in defaults.

On many occasions I've configured an SMTP relay for several small hosts 
to rewrite xxx@[ip-address] to xxx(_dot_)ip-address(_at_)example(_dot_)com

Best to work a domain name if at all possible.

Nah, most operators don't read RFCs, TL;DR.

Yes, but RFCs do influence how-to guides, MTA documentation and 
configuration settings, and IoT device setting screens.

Mostly correct for MTA documentation, much less so for the how-to
guides from some random user on the Internet, and minimal designs
in low-end devices.

Disagree, but I'm not going to dive into that discussion.  Or maybe the 
"fancy features" are things that actually matter sometimes.

My point was that all you need is:

    * Connect
    * Wait for 2XX (possibly multi-line)
    * EHLO <client>
    * Wait for 2XX (possibly multi-line)
    * MAIL FROM:<sender>
    * Wait for 2XX (possibly multi-line)
    * RCPT TO:<recipient>
    * Wait for 2XX (possibly multi-line)
    * DATA
    * Wait for 3XX (possibly multi-line)
    * <body> (RFC5322, RFC2045, ...)
    * Wait for 2XX (possibly multi-line)

which works on port 25 to a nearby suitably receptive smarthost.
Everything else is advanced features for clients that expect
more from SMTP than fire and forget submission.  Of course
things become more fun with EAI, PIPELINING, DSN, ... but
perhaps not for IIoT.

I see a need for authenticated submission even from isolated networks, 
and think that both IoT devices and submission servers (or 
pre-submission servers) need to support some of those, and need to know 
which ones to support.

Operators often struggle with server-side SASL, IP ACLs are simpler and
less fragile for isolated networks.

Some of the existing SASL methods do appear to be suitable though.

Password stores can be difficult to manage, and Cyrus SASL non-trivial
to configure.  Then you get nightmares like OAUTH...  Just "AUTH PLAIN"
is hard enough.

p.s. I suspect ietf-smtp doesn't want to dig down into details of how
IoT devices should authenticate submissions - at least not just yet -
and such a topic might be better discussed in a working group that's
specifically tailored to that purpose.   For now I just want people to
realize that some long-held assumptions may not be universlaly valid.

The below are reasonably simple choices.

    * IP-based ACLs
    * Self-signed TLS client cert (if the MSA supports public key
      fingerprints, obviating the need for a PKI).

All the other choices are IMHO much too advanced for the average server
operator or SMTP client implementor.


ietf-smtp mailing list