Re: [Uta] Port 465

["Christian Huitema" <[e-mail]>]

>   This is a one time procedural exception to the rules in RFC 6335.
>  This requires explicit IESG approval and does not set a precedent.
>   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 requests security during
>   account setup.  If a new port is assigned for the submissions
>   service, email software will either continue with unregistered use of
>   port 465 (leaving the port registry inaccurate relative to de-facto
 >  practice and wasting a well-known port), or confusion between the de-
 >  facto and registered ports will cause harmful interoperability
>   problems that will deter use of TLS for message submission.  The
>  authors believe both of these outcomes are less desirable than a wart
>   in the registry documenting real-world usage of a port for two
 > purposes.  Although STARTTLS-on-port-587 has deployed, it has not
 >  replaced deployed use of implicit TLS submission on port 465.

Updating mail agents to use another port is of course possible, but in
practice will require manual configuration of each and every agent. It would
have to be synchronized between servers and clients, which makes automated
updates pretty hard. In short, any drastic action is likely to disrupt the
deployment of SMTP Submission over TLS. We are trying to get more
disruption, not less, so we should not mandate a change of port on a large
number of deployed clients and servers.

The port collision is only a practical problem if the same server wants to
deploy both Secure SMTP submission and the experimental "URL Rendesvous
(sic) Directory for SSM." Do we know whether that is a problem in practice?
I suspect that the overlap between the two usages is quite small, and that
if any port migration is required, it will only concern a small number of
servers deploying both services.

Given that, it is probably better that the IANA directory recognizes usage.
IANA should document that traffic on TCP port 465 can be either of those
protocols. Or alternatively, mark TCP 465 as "reserved" and just pick a
different port for SSM...

-- Christian Huitema