RFC8314文档中对465端口和587端口的阐述

最近在学习SMTP的时候发现SMTP在使用加密传输的时候涉及到465和587两个端口，网上对两者之间的区别众说纷纭，后来查到了RFC官方文档中对于这个争论较久的问题的定义和详细说明，这里做转载和翻译用于记录。

1、RFC8314原文

我们查看RFC8314官方文档中的相关叙述，和该问题相关的主要是3.3、4.2、5.5和7.3这四个部分，由于本文只讨论两个端口的作用和历史缘由，因此涉及到加密过程和原理的4.2、5.5两个部分不在这里提及，其余部分的原文内容如下：

3.3. Implicit TLS for SMTP Submission

When a TCP connection is established for the “submissions” service
(default port 465), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in
[RFC7817]. Once the TLS session is established, Message Submission
protocol data [RFC6409] is exchanged as TLS application data for the
remainder of the TCP connection. (Note: The “submissions” service
name is defined in Section 7.3 of this document and follows the usual
convention that the name of a service layered on top of Implicit TLS
consists of the name of the service as used without TLS, with an “s”
appended.)

The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 7.3). This
differs from IMAP and POP services where Implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate core
protocols used by MUA software to Implicit TLS over time, for
consistency as well as for the additional reasons discussed in
Appendix A. However, to maximize the use of encryption for
submission, it is desirable to support both mechanisms for Message
Submission over TLS for a transition period of several years. As a
result, clients and servers SHOULD implement both STARTTLS on
port 587 and Implicit TLS on port 465 for this transition period.
Note that there is no significant difference between the security
properties of STARTTLS on port 587 and Implicit TLS on port 465 if
the implementations are correct and if both the client and the server
are configured to require successful negotiation of TLS prior to
Message Submission.

Note that the “submissions” port provides access to a Message
Submission Agent (MSA) as defined in [RFC6409], so requirements and
recommendations for MSAs in that document, including the requirement
to implement SMTP AUTH [RFC4954] and the requirements of Email
Submission Operations [RFC5068], also apply to the submissions port.

See Sections 5.5 and 4.2 for additional information on client
certificate authentication. See Section 7.3 for port registration
information.

7.3. Submissions Port Registration

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

de facto practice and wasting a well-known port) or (b) confusion
between the de facto and registered ports will cause harmful
interoperability problems that will deter the use of TLS for Message
Submission. The authors of this document believe that 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 been deployed, it has not replaced the deployed use of
Implicit TLS submission on port 465.

2、个人理解

将上面的几段原文阅读整合之后，个人的理解如下：

首先要说明原文中多次出现的submission的意思实际上是指客户端使用SMTP协议来对服务端进行数据传输，下面提及的SMTPS等价于原文的TLS submission。

当年IANA为TCP的465端口注册了用途，用于SMTP的TLS加密传输，且没有指定UDP的465端口用途，这就是465端口在历史上被用为SMTPS端口的由来。

为什么说是历史上呢，因为这个注册在不久之后就被撤销了，也就是说这个注册没用了，465端口要被回收拿去给其他的服务用了。而撤销的原因是“这种注册没有意义，因为SMTP传输MX基础结构无法指定端口，因此始终使用端口25。（This registration made no sense, as the SMTP transport MX infrastructure has no way to specify a port, so port 25 is always used. ）”

但是后来又觉得当时应该把这个465的SMTPS（隐式TLS）端口保留或者是重命名而不是撤销，因为已经有许多邮件服务软件使用了465端口作为SMTPS（隐式TLS）的传输端口，如果为SMTPS（隐式TLS）服务分配了新端口，则已经使用被注销的465端口作为SMTPS服务端口的电子邮件软件相当于是使用了一个和实际SMTPS（隐式TLS）端口不匹配的端口，并且实际使用端口和理论注册端口的不同也有可能导致各种问题。

因此尽管已在端口587上部署了STARTTLS，但它尚未取代在端口465上部署的SMTPS（隐式TLS）的使用。

随着时间的推移，出于一致性以及其他原因，需要将MUA软件使用的核心协议迁移到隐式TLS。但是，为了最大程度地使用加密来进行提交，需要在几年的过渡期内支持两种通过TLS进行消息提交的机制。因此，在此过渡期间，客户端和服务器应在端口587上实施STARTTLS，并在端口465上实施隐式TLS。请注意，如果实施正确且客户端和服务器都配置为要求在消息提交之前成功协商TLS，则端口587上的STARTTLS和端口465上的隐式TLS的安全属性之间没有显着差异。

A mail user agent (MUA) is a program that allows you to receive and send e-mail messages; it’s usually just called an e-mail program.

MUA软件即指我们平时使用的集收发读写邮件于一体的邮件客户端软件。

简而言之，465端口最开始被注册用于SMTPS，随后被撤销，但是因为已经被用了，现在又恢复了，并且还多增加了一个587端口用于STARTTLS加密传输，并且在配置正确的前提下两者一样安全。目前的主要任务是把邮件从明文传输迁移到加密传输，在迁移的过渡期间应当支持587端口的STARTTLS和465端口的隐式TLS。