tl;dr - Your program should support 465 and optionally 587 – implicit TLS via
submissions over port 465 is where we’re moving to, according to RFC 8314 from 2018.
Thanks to some feedback from very helpful folks on r/sysadmin, it's clear that STARTTLS is even worse than I thought!
After experiencing a bit of pain making my somewhat complicated email setup work properly with SNI-based forwarding, I realized that up until now I’ve also believed that STARTTLS on 587 was the “future” and TLS via 465 was SMTPS.
Eventually I realized that to properly forward email authentiated with STARTTLS on 587, you need a protocol-aware proxy. It also very much seems that not many people have done that – there aren’t many inbound email relay/proxy solutions out there.
Then I found revelation via this post on linuxguideandhints.com. Looks like a lot of people and email services have it backwards, we’re supposed to be moving to 465, not away from it.
And upon reading Section 3.3 of RFC 8314 it’s clear – it’s not that STARTTLS is the way forward, it’s that SMTPS is not the way forward and unfortunately it happened to be used on the same port. Implicit TLS is the future, and it should be done over port 465 (SMTPS, which is not the same thing, is deprecated).
Supporting TLS over 465 should not be classed (and likely de-prioritized) as “maintaining backwards compatibility” or any similar notion.
The relevant information is in section 3.3:
The STARTTLS mechanism on port 587 is relatively widely deployed due to the situation with port 465 (discussed in Section 7.3. This differs from IMAP and POP services where Implicit TLS is more widely deployed on servers than STARTTLS. It is desirable to migrate core protocols used by MUA software to Implicit TLS over time, for consistency as well as for the additional reasons discussed in Appendix A. However, to maximize the use of encryption for submission, it is desirable to support both mechanisms for Message Submission over TLS for a transition period of several years. As a result, clients and servers SHOULD implement both STARTTLS on port 587 and Implicit TLS on port 465 for this transition period. Note that there is no significant difference between the security properties of STARTTLS on port 587 and Implicit TLS on port 465 if the implementations are correct and if both the client and the server are configured to require successful negotiation of TLS prior to Message Submission.
The transition is not to
submissions over 587 via STARTTLS, it’s to
submissions via implicit TLS on port 465 (as opposed to SMTPS over port 465 which is now deprecated).
Hopefully this gets shared widely since it seems to be a common misunderstanding – 587 is not “the future” – implicit TLS over 465 is.