Just wanted to point this out since it seems to have become a common misunderstanding – 587 is not “the future” – implicit TLS over 465 is.
I was lead to this revelation by this post
And upon reading the actual RFC from 2018 it’s clear – it’s not that STARTTLS is the way forward, it’s that SMTPS is not the way forward, and implicit TLS over port 465 (or 587) is what administrators should choose going forward.
Supporting TLS over 465 should not be classed (and likely de-prioritized) as “maintaining backwards compatibility” or any similar notion.
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).