Re: [Uta] Port 465

[t.p. <[e-mail]>]

----- Original Message -----
From: "Christian Huitema" <[e-mail]>
To: "'Chris Newman'" <[e-mail]>; "'Salz, Rich'"
<[e-mail]>; <[e-mail]>
Sent: Saturday, March 08, 2014 7:33 PM
> >   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.

Christian,

My ISP, not a small one, required me and everyone else to change their
ports a few years ago.  There was parallel running, so it did not have
to be synchronised between clients and servers.  I would imagine the
numbers affected would be in seven figures. We had no choice, so it
happened.  (Interestingly, the ISP provided instructions on how to make
the change but got it wrong, so some SMTP skills were needed to make the
migration).

Tom Petch

> 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
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta