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

[Viktor Dukhovni <[e-mail]>]

On Wed, Jan 01, 2020 at 02:08:00PM -0500, Keith Moore wrote:

> In my mind the question is: how to explain to ordinary operators,
> administrators, IoT device vendors, etc. how to make this work
> well?    If someone is developing an IoT device that needs to send
> mail, what is that device required to do, what configuration options
> should it offer, etc.? 

Not much.  One of (configurable per site requirements):

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.

2. Connect to port 587, do STARTTLS and provide a configured username
   plus password to authenticate submission.  Much harder to support
   in low-end appliances, may need some managed trusted root CAs,
   NTP, ... unless OK to forgo authenticating the server in an
   isolated private network, but then see 1).

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

> If an IT person in some enterprise is arranging for that enterprise's
> IoT devices to be able to send mail, what service do they need to
> provide, on what port, etc?

Quite possibly all of the above, although 1 is often sufficient.

> Does a submission service that's in the signal path for outgoing mail
> for such devices need any special configuration or considerations to
> be able to handle such mail? 

IP ACLs generally suffice.

> (For example, does it need to be able to rewrite sender addresses
> containing IP address literals to make them globally meaningful while
> still being distinct from one another for different sender hosts?)  

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.

> If the operator of the IoT devices can say to the enterprise IT person
> - I need an instance of service X, as defined by RFCYYYY, that might
> make things easier and reduce the amount of gratuitous meddling that
> people do with email.

Nah, most operators don't read RFCs, TL;DR.  They google some How-To
guides, maybe skim the docs of their MTA, and glance at the IoT device
settings screen and figure out what's supported on both ends, making
tweaks until it works.

> Similarly if the developer of the IoT device knows exactly what the
> messages should look like and what service to interface to, that might
> make configuration of such devices either and reduce the chance that
> special measures will be needed for that device's email.

See above.

> But I also have seen occasions on which even experts trying to do the 
> right things, disagreed about how to do those things, in ways that 
> caused problems when their systems interacted.   So I'm not sure that 
> the standards are only for "ordinary" operators, etc.

The experts may disagree on fancy features, but the basics remain
sufficient and unchanged.  See above.


> p.s. I somehow doubt that we should recommend authentication based only 
> on IP address at any level, though.  That's poor practice even for a 
> small network that assigns static IP addresses to all of its hosts.   

Well, authentication requires credential management, ... so means for
example devices joining Kerberos domains, or manually provisioned with
passwords, ... For which the standards are much more diverse than SMTP.
If you're concerned about the complexity of configuring SMTP, then you
really don't want to contemplate securing the network.

> More broadly there's a widespread misconception that isolated networks
> are not subject to security threats or that perimeter defenses are
> sufficient to protect them, even when such networks are used to manage
> critical infrastructure or equipment that can create hazards if not
> properly managed.

It is not always a misconception, rather it can be a realistic
assessment that the cost of managing authentication may not be worth the
effort, and the barriers to get it working on specialized appliances are
quite high.

-- 
    Viktor.