bryankeithmoore

Nothing gets fixed until people realize it's broken. And yet, it's also true that using TLS for mail submission and access has been best common practice for several years, with most providers specifying TLS in their connection instructions and some even deprecating cleartext. This RFC might result in more service calls as users start being told their connections aren't secure, but it also tells providers what to do to fix the problem.

Except that most consumer ISPs block outgoing traffic on port 25 to make spamming more difficult. So you won't be able to send mail directly to the recipient's SMTP server.

For the case of mail submission, there is a lot of legacy hardware/firmware out there still in use that simply doesn't support TLS, and is mission-critical, and is likely to become obsolete before anyone upgrades it. A lot of that traffic is considered nonsensitive by those who need it so trying to force them to be secure isn't going to go over well. Despite that, RFC 8314 recommends that MSPs deprecate cleartext submission and mail access, but it doesn't specify a timetable because the situations vary too widely from one provider to another.

For message relaying, your proposal might indeed work. The vast majority of inter-domain mail traffic goes through a very small number of providers. No mail provider can afford to not be able to exchange mail with gmail, or office365, or ...

See my reply below. My draft originally included the mail relaying case but trying to address both submission and relaying in the same document made the document unwieldy. In theory they both use the same protocol (more-or-less) but there are numerous subtle differences that make the two cases vastly different when negotiating encryption.

The IETF UTA working group has documents in process to address the mail relaying case; I'm sure they'd appreciate review and feedback.

This document only addresses email submission and access because a single document that covered email submission, access, relaying, key lookup/verification, and message encryption would be huge and take forever to get consensus on. It made more sense to divide up the work. It just happens that this piece got finished first, probably because it's the simplest piece. Others are working on improving the security of relaying which is harder because in general there's no a priori explicit relationship between an SMTP client and an SMTP server relaying the message - so the client has no way to know on initial contact whether its connection with the server has been intercepted (which would allow the interceptor to downgrade the connection to cleartext and thwart automatic future use of TLS). But even when relaying is more secure, the messages will still be in the format submitted while being relayed, and after being delivered - i.e. usually cleartext.

Making whole message encryption work on a large scale, and incrementally deployable, is hard, because there are lots of corner cases to deal with. For instance, if you leave messages encrypted on the recipient's server, then the server can't assist in searching the text of those messages, which makes searching slow and especially bad for mobile devices. Or you want to know when sending a message if it's safe to encrypt it or not, but even if you define some service to query whether there's a public key associated with the recipient's domain name, that service may not work well if the recipient has their mail forwarded elsewhere. You want the message encryption service to be widely applicable but you also want the user interface to be simple - and corner cases complicate user interfaces.

Or you could start over from scratch (as has been and is being tried by others) and see how hard it is to displace the existing system without an incremental upgrade path. Hopefully we'll get there one way or another.