This is only half of the story.
Historically port 465 was briefly registered for “smtps” (sever to server), which didn’t make much sense, as SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a protocol called “urd”. So far so good…
However, as widely used email software began to use port 465 for “Submission over TLS” (client to server with Implicit TLS), the port became a de-facto standard for this use case which then led to RFC 8314, a one-time procedural exception, that assigned “Submission over TLS” to Port 465, even though the port was already assigned to another protocol.
Sources:
https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#Ports
465 This port was deprecated after RFC 2487, until the issue of RFC 8314.
https://datatracker.ietf.org/doc/html/rfc8314#section-7.3
IANA has assigned an alternate usage of TCP port 465 in addition to the current assignment using the following template [RFC6335]:
Service Name: submissions
Transport Protocol: TCP
Assignee: IESG iesg@ietf.org
Contact: IETF Chair chair@ietf.org
Description: Message Submission over TLS protocol Reference: RFC 8314
Port Number: 465
This is a one-time procedural exception to the rules in [RFC6335]. This requires explicit IESG approval and does not set a precedent. Note: Since the purpose of this alternate usage assignment is to align with widespread existing practice and there is no known usage of UDP port 465 for Message Submission over TLS, IANA has not assigned an alternate usage of UDP port 465.
Historically, port 465 was briefly registered as the “smtps” port. This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. As a result, the registration was revoked and was subsequently reassigned to a different service. In hindsight, the “smtps” registration should have been renamed or reserved rather than revoked. Unfortunately, some widely deployed mail software interpreted “smtps” as “submissions” [RFC6409] and used that port for email submission by default when an end user requested security during account setup. If a new port is assigned for the submissions service, either (a) email software will continue with unregistered use of port 465 (leaving the port registry inaccurate relative to
https://datatracker.ietf.org/doc/html/rfc8314#appendix-A
Port 465 is presently used for two purposes: for submissions by a large number of clients and service providers and for the “urd” protocol by one vendor. Actually documenting this current state is controversial, as discussed in the IANA Considerations section. However, there is no good alternative. Registering a new port for submissions when port 465 is already widely used for that purpose will just create interoperability problems. Registering a port that’s only used if advertised by an SRV record (RFC 6186) would not create interoperability problems but would require all client deployments, server deployments, and software to change significantly, which is contrary to the goal of promoting the increased use of TLS. Encouraging the use of STARTTLS on port 587 would not create interoperability problems, but it is unlikely to have any impact on the current undocumented use of port 465 and makes the guidance in this document less consistent. The remaining option is to document the current state of the world and support future use of port 465 for submission, as this increases consistency and ease of deployment for TLS email submission.