On Sun, Jan 05, 2020 at 02:38:02AM -0500, Keith Moore wrote:
But the IIoT MSA might still be operating in an environment without
DNS, so it can't be expected to do all of the sanity checking and
fixup that an MSA on the public Internet would do.
The usual-suspect MSAs (at least Postfix and Exim) operate just fine in
isolated non-DNS networks. An MSA only needs DNS when:
* Delivering to someone else's domain on the public internet, via
the MX records for that domain.
* Attempting to do DANE SMTP.
neither of these apply on isolated non-DNS networks.
I'd also like to see if there's a way to use TLS to let the connection
be secured by a certificate on the client end, using a certificate
issued by the device manufacturer.
For SMTP, what I have in mind is a SLTTRATS SMTP extension that acts
like STARTTLS except that the the client and server roles on the TLS
connection are flipped - the SMTP client is the TLS server and vice
versa.
That's possible now, using STARTTLS. No need for a new ESMTP extension.
The client ignores the server certificate, while the server, requests a
client certificate and uses it to authenticate the client (by
certificate or public key fingerprint).
Then the IIoT devices don't need a trusted CA list, the IIoT MSAs that
they talk to do - but the MSAs are closer to the public network so the
update might be easier.
They don't need a CA bundle if they are not going to authenticate the
server. Since they can't be assumed to have a reliable clock, certs
work poorly in any case, so they could at best be (on site) configured
with a list of public key fingerprints of trusted MSAs. In most cases
this is likely overkill. A rogue MSA can just reject connections
blocking mail delivery, and no amount of authentication will stop that.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp