RFC Errata
Found 1 record.
Status: Reported (1)
RFC 8314, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", January 2018
Note: This RFC has been updated by RFC 8997
Source of RFC: uta (sec)
Errata ID: 5326
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Chris Newman
Date Reported: 2018-04-13
Section 7.3 says:
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
It should say:
Historically, port 465 was briefly registered as the "smtps" port. This registration was misleading because the "SMTP relay" service registered as "smtp" on port 25 can not use a different port because the SMTP transport MX infrastructure has no way to specify a port. As a result, the registration was revoked and was subsequently reassigned to a different service. In hindsight, the "smtps" registration should have been reserved or renamed to "submissions" (to parallel the "submission" SMTP service on port 587 [RFC6409]) rather than revoked. Some widely deployed mail user agent software used the "smtps" port for the "submissions" service when an end user requested security during account setup.
Notes:
The "made no sense" statement is technically and factually incorrect. Not only is implicit TLS SMTP submission service on port 465 deployed and used, but the rest of the document recommends using it (thus contradicting the "made no sense" statement). When two ports provide the same service in both cleartext and implicit TLS, the naming convention is to use an "s" suffix for the implicit TLS port. So the problem with the "smtps" was it violated that naming convention.
The proposed errata corrects the technical/factual error and clarifies the distinction between the two different services (SMTP submission & SMTP relay) that both use SMTP.