RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search