Updates:
1939,
2595,
3501,
5068,
6186,
6409
3.3. Implicit TLS for SMTP Submission
When a TCP connection is established for the "submissions" service
(default port 465), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in
[RFC7817]. Once the TLS session is established, Message Submission
protocol data [RFC6409] is exchanged as TLS application data for the
remainder of the TCP connection. (Note: The "submissions" service
name is defined in Section 7.3 of this document and follows the usual
convention that the name of a service layered on top of Implicit TLS
consists of the name of the service as used without TLS, with an "s"
appended.)
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.
Das macht mir die Auswahl nicht einfacher.