Section 3.2 says in part:
o In cases where an application protocol allows implementations or
deployments a choice between strict TLS configuration and dynamic
upgrade from unencrypted to TLS-protected traffic (such as
STARTTLS), clients and servers SHOULD prefer strict TLS
configuration.
In the STARTTLS services I know, submission, POP, and IMAP, this
doesn't match the way clients work. They're normally configured to use
TLS but fall back if it's not available, and they all know if the
strict TLS service on port 993 or 995 isn't available, to try port 143
or 110 instead. Presumably any middlebox sophisticated enough to strip
STARTTLS can also block the other ports.
I would say instead that they SHOULD use TLS on either port, remember
that it worked (which they all do), and complain if it later stops
working.
You should also mention MTA-STS (RFC 8461) which is the mail
equivalent of HSTS and is widely supported at least among large mail
providers. I'd also think a stronger reference to TLSA would be useful
since clients should fail if they have a TLSA record and there's no
TLS certificate to match.
R's,
John
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
