非官方中文译本声明：本页为 IETF RFC 8314《Use of Transport Layer Security (TLS) for Email Submission and Access》（邮件提交与访问使用 TLS） 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8314。

RFC 8314：邮件提交与访问使用 TLS（Use of TLS for Email）

标准跟踪 · K. Moore（Windrock, Inc.）、C. Newman（Oracle）· 2018 年 1 月 · 类别：Standards Track · ISSN: 2070-1721 · 更新：RFC 1939、2595、3501、5068、6186、6409

摘要

本规范概述了当前关于使用传输层安全（TLS）为邮件用户代理（MUA）与邮件提交服务器或邮件访问服务器之间的邮件流量提供保密性的建议。本文档更新了 RFC 1939、2595、3501、5068、6186 与 6409。

本备忘录的状态

本文档为互联网标准跟踪（Standards Track）文档。

本文档是互联网工程任务组（IETF）的成果，代表了 IETF 社区的共识，并已通过公开评审，由互联网工程指导组（IESG）批准发布。关于互联网标准的更多信息参见 RFC 7841 第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc8314 获取。

Copyright (c) 2018 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（https://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含《简化 BSD 许可证》文本（见信托法律条款第 4.e 节），并按该许可证所述"不提供担保"地提供。

目录

1. 引言

通过 Internet 消息访问协议（IMAP）[RFC3501]、邮局协议（POP）[RFC1939] 和/或简单邮件传输协议（SMTP）提交 [RFC6409] 提供电子邮件服务的软件，通常具备传输层安全（TLS）[RFC5246] 支持，但往往未能以最大化最终用户保密性的方式使用它。本规范描述了当前关于在邮件用户代理（MUA）与邮件访问服务器之间，以及 MUA 与邮件提交服务器之间交互时使用 TLS 的建议。

简言之，本备忘录现建议：

本备忘录不涉及 SMTP 在邮件中继（Message Relay）时使用 TLS 的情形（即不适用 [RFC6409] 的邮件提交场景）。改进 SMTP 在邮件中继时对 TLS 的使用需要另一种不同的方法。解决该主题的一种方法见 [RFC7672]；另一种方法见 [MTA-STS]。

本备忘录中的建议并不取代端到端电子邮件加密的功能，也不作为其替代。

1.1. 本文档如何更新先前的 RFC

本文档通过两种方式更新 POP（RFC 1939）、IMAP（RFC 3501）与提交（RFC 6409、RFC 5068）：

  1. 如第 3 节所述，为这些协议新增隐式 TLS 端口作为标准跟踪（Standards Track）端口；
  2. 如第 4 节与第 5 节所述，更新适用于这些协议的 TLS 最佳实践。

本文档通过以下方式更新 RFC 2595：以本文档第 1 节与第 3 节所述的对隐式 TLS 的偏好取代 RFC 2595 的第 7 节，同时更新适用于 RFC 2595 中协议的 TLS 最佳实践（如本文档第 4 节与第 5 节所述）。

本文档在第 5.1 节中更新了 RFC 6186（如文内所述）。

2. 本文档使用的约定与术语

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"NOT RECOMMENDED（不推荐）"、"MAY（可以）"与"OPTIONAL（可选）"，当且仅当它们以全部大写字母出现时（如这里所示），应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

"隐式 TLS"一词指：每当在某个特定 TCP 端口上建立 TCP 连接时，若该端口被该服务器专用于 TLS 连接，则自动协商 TLS。提出"隐式 TLS"这一术语，是为了与 POP、IMAP、SMTP 邮件提交及其他协议中使用的 STARTTLS 和类似命令形成对比——后者由客户端与服务器在已建立的明文 TCP 连接上显式协商 TLS。

"邮件访问服务器（Mail Access Server）"一词指提供 POP、IMAP 及任何其他用于访问或修改已收消息，或访问或修改邮件用户账户配置的协议的服务器。

"邮件提交服务器（Mail Submission Server）"一词指提供 [RFC6409]（或其前身或后继版本）所规定协议的服务器，用于提交待投递给收件人的外发消息。

"邮件服务提供商（Mail Service Provider，简称 MSP）"一词指邮件访问服务器和/或邮件提交服务器的运营者。

"邮件账户（Mail Account）"一词指用户在某 MSP 处的身份、其认证凭据、由该 MSP 存储的任何用户电子邮件，以及该 MSP 维护的任何其他每用户配置信息（例如垃圾邮件过滤指令）。大多数 MUA 支持访问多个邮件账户。

对于 MUA 以其用户名义访问的每个账户，它必须具有用户指定的服务器名称、端口、认证凭据及其他配置信息。MUA 使用的这些信息被称为"邮件账户配置（Mail Account Configuration）"。

本规范使用 [RFC5234] 中描述的增强型巴科斯-瑙尔范式（ABNF）来表达语法，包括 [RFC5234] 附录 B 提供的核心规则以及 [RFC5322] 提供的规则。

3. 隐式 TLS

先前关于在电子邮件协议中使用 TLS 的标准采用了 STARTTLS 机制：[RFC2595]、[RFC3207] 与 [RFC3501]。在使用 STARTTLS 时，客户端建立一个明文应用会话，并根据服务器能力与客户端配置决定是否发出 STARTTLS 命令。如果客户端发出 STARTTLS 命令，则随后进行 TLS 握手以升级该连接。尽管该机制已经部署，但另一种机制——在连接建立之初于独立端口上立即协商 TLS（本文档称之为"隐式 TLS"）——的部署更为成功。为了鼓励更广泛地使用 TLS，并提升 TLS 使用方式的一致性，本规范现建议在 POP、IMAP、SMTP 提交以及 MUA 与 MSP 之间使用的所有其他协议中采用隐式 TLS。

3.1. POP 的隐式 TLS

当为 "pop3s" 服务（默认端口 995）建立 TCP 连接时，立即开始 TLS 握手。客户端必须实现 [RFC7817] 中描述的证书验证机制。一旦建立 TLS 会话，POP3 [RFC1939] 协议消息将作为 TLS 应用数据在该 TCP 连接的剩余时间内进行交换。在服务器发送 +OK 问候语之后，无论 TLS 握手期间是否提供了客户证书，服务器与客户端都必须进入授权（AUTHORIZATION）状态。

有关客户证书认证的更多信息，见第 5.5 节与第 4.2 节。有关端口注册信息，见第 7.1 节。

3.2. IMAP 的隐式 TLS

当为 "imaps" 服务（默认端口 993）建立 TCP 连接时，立即开始 TLS 握手。客户端必须实现 [RFC7817] 中描述的证书验证机制。一旦建立 TLS 会话，IMAP [RFC3501] 协议消息将作为 TLS 应用数据在该 TCP 连接的剩余时间内进行交换。如果 TLS 握手期间提供了服务器认为可接受的客户证书，则服务器可以发出 PREAUTH 问候语，在这种情况下，服务器与客户端双方都进入已认证（AUTHENTICATED）状态。如果服务器发出 OK 问候语，则服务器与客户端双方都进入未认证（NOT AUTHENTICATED）状态。

有关客户证书认证的更多信息，见第 5.5 节与第 4.2 节。有关端口注册信息，见第 7.2 节。

3.3. SMTP 提交的隐式 TLS

当为 "submissions" 服务（默认端口 465）建立 TCP 连接时，立即开始 TLS 握手。客户端必须实现 [RFC7817] 中描述的证书验证机制。一旦建立 TLS 会话，邮件提交协议数据 [RFC6409] 将作为 TLS 应用数据在该 TCP 连接的剩余时间内进行交换。（注意："submissions" 服务名称定义于本文档第 7.3 节，并遵循通常的约定，即建立在隐式 TLS 之上的服务名称，由该服务在未使用 TLS 时的名称后附加一个 "s" 构成。）

端口 587 上的 STARTTLS 机制由于端口 465 的情况（见第 7.3 节讨论）而相对广泛部署。这与 IMAP 和 POP 服务不同，在后者中，隐式 TLS 在服务器上的部署比 STARTTLS 更为广泛。出于一致性考虑，也基于附录 A 中讨论的其他原因，希望随着时间的推移将 MUA 软件使用的核心协议迁移到隐式 TLS。然而，为了最大化提交过程对加密的使用，在数年的过渡期内同时支持两种机制是可取的。因此，在此过渡期内，客户端与服务器都应同时实现端口 587 上的 STARTTLS 与端口 465 上的隐式 TLS。注意，如果实现正确，且客户端与服务器都配置为在邮件提交之前要求成功协商 TLS，则端口 587 上的 STARTTLS 与端口 465 上的隐式 TLS 在安全属性上没有显著差异。

注意，"submissions" 端口提供对 [RFC6409] 所定义的邮件提交代理（MSA）的访问，因此该文档中对 MSA 的要求与建议——包括实现 SMTP AUTH [RFC4954] 的要求，以及电子邮件提交运维 [RFC5068] 的要求——同样适用于 submissions 端口。

有关客户证书认证的更多信息，见第 5.5 节与第 4.2 节。有关端口注册信息，见第 7.3 节。

3.4. POP、IMAP 与 SMTP 提交的隐式 TLS 连接关闭

当客户端或服务器希望关闭连接时，应在 TCP 连接终止之前发起 TLS 关闭告警（close alert）的交换。客户端在发送 TLS 关闭告警之后，可以在不等待服务器 TLS 响应的情况下，优雅地关闭 TCP 连接（例如，对 TCP 套接字调用 close() 函数，或以其他方式发出 TCP CLOSE（[RFC793] 第 3.5 节））。

4. 邮件访问服务器与邮件提交服务器对 TLS 的使用

以下要求与建议适用于邮件访问服务器与邮件提交服务器，或者在指明时，适用于 MSP：

其他考量与细节见下文。

4.1. 弃用明文服务及 TLS 版本低于 1.1 的服务

鉴于其用户群体的需求与约束，弃用明文邮件访问服务器与邮件提交服务器的具体手段可能因各 MSP 而异。例如，某 MSP 可以实施渐进式过渡，即在一段时间内，越来越多地被禁止向这些服务器的明文实例进行认证，从而促使用户迁移到隐式 TLS。对明文服务器的访问最终应要么（a）被禁用，要么（b）严格限于无法升级的遗留系统使用。

在用户通过明文向服务器认证的能力被撤销之后，拒绝此类访问的服务器不得（MUST NOT）在明文信道上提供任何关于该用户认证凭据是否有效的指示。使用无效凭据或有效凭据尝试作为该用户进行认证，都必须（MUST）导致相同的拒绝访问指示。

此外，如果旧的口令有可能已被泄露，那么此前使用以明文发送的口令进行认证的用户，在迁移到 TLS 时应该（SHOULD）被要求更改这些口令。（对于任何大量通过公共 Internet 在未加密情况下访问邮件的用户群体，都应假定其中至少部分口令已被泄露。）

将用户从 SSL 或 TLS 1.0 迁移到更高版本 TLS 的手段，可类似于上文所述的方式进行。有多种方式可以实现这一点。一种方式是服务器拒绝来自任何发送 ClientHello.version 字段对应于 SSL 或 TLS 1.0 任一版本的客户端的 ClientHello 消息。另一种方式是服务器接受来自某些其不希望支持的客户端版本的 ClientHello 消息，但随后拒绝允许用户认证。后一种方法可能向用户更好地表明失败原因，但（取决于所使用的协议与认证方法）也可能在已知无法提供充分保密性的信道上暴露用户的口令。

建议（RECOMMENDED）从一开始就要求新用户使用 TLS 1.1 或更高版本。然而，MSP 可能发现有必要做出例外，以兼容仅支持较早 TLS 版本或仅支持明文的某些遗留系统。

4.2. 邮件服务器对客户证书认证的使用

邮件提交服务器与邮件访问服务器可以在隐式 TLS 端口上实现客户证书认证。除非服务器配置为接受某些客户证书足以用于认证，并且服务器有能力确定与此种证书匹配的邮件服务器授权标识，否则此类服务器不得（MUST NOT）在 TLS 握手期间请求客户证书。如何进行这一判定目前属于实现相关事项。

如果服务器接受该客户的证书足以用于授权，则必须（MUST）启用简单认证与安全层（SASL）EXTERNAL 机制 [RFC4422]。IMAPS 服务器可以发出 PREAUTH 问候语，而非启用 SASL EXTERNAL。

4.3. 在 "Received" 头字段中记录 TLS 密码套件

ESMTPS 传输类型 [RFC3848] 提供的追踪信息能够指示在传输邮件时是否使用了 TLS。然而，仅使用 TLS 本身并不能保证保密性或安全性。TLS 密码套件提供了关于该连接所提供的安全级别的额外信息。本节定义了一种新的 SMTP "tls" Received 头字段额外已注册（additional-registered）子句，用于记录为该连接协商得到的 TLS 密码套件。当提交服务器为通过 TLS 收到的消息生成 Received 头字段时，应该（SHOULD）包含此子句。该子句中所包含的值应该（SHOULD）是已注册的密码套件名称（例如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256），即"TLS 密码套件注册表"中的名称。若实现不知道该密码套件的名称（这种情况应尽快纠正），则可以使用四位十六进制密码套件标识符。此外，在已知且适用的情况下，可以（MAY）在密码套件名称之后包含与该密码套件关联的 Diffie-Hellman 组名。该字段的 ABNF 如下：

   tls-cipher-clause  =  CFWS "tls" FWS tls-cipher
                         [ CFWS tls-dh-group-clause ]

   tls-cipher         =  tls-cipher-name / tls-cipher-hex

   tls-cipher-name    =  ALPHA *(ALPHA / DIGIT / "_")
   ; as registered in the IANA "TLS Cipher Suite Registry"
   ; <https://www.iana.org/assignments/tls-parameters>

   tls-cipher-hex     =  "0x" 4HEXDIG

   tls-dh-group-clause = "group" FWS dh-group
   ; not to be used except immediately after tls-cipher

   dh-group           = ALPHA *(ALPHA / DIGIT / "_" / "-")
   ; as registered in the IANA "TLS Supported Groups Registry"
   ; <https://www.iana.org/assignments/tls-parameters>

4.4. TLS 服务器证书要求

MSP 必须为所有服务器维护有效的服务器证书。实现这一点所需的建议与要求见 [RFC7817]。

如果某协议服务器为多个邮件域提供服务，则可以为每个域使用独立的 IP 地址，和/或使用通告多个域的服务器证书。这通常是有必要的，除非且直到可以接受施加如下约束：服务器与所有客户端都支持 TLS 的服务器名称指示（SNI）扩展 [RFC6066]。支持 SNI 的邮件服务器需要支持 SRV 之后的主机名，以便与尚未实现 [RFC6186] 的 MUA 互操作。关于此问题的更多讨论见 [RFC7817] 第 5.1 节。

4.5. 邮件协议服务器的推荐 DNS 记录

本节不仅讨论了推荐的 DNS 记录，还讨论了 DNS 记录对服务器配置与 TLS 服务器证书的影响。

4.5.1. MX 记录

建议（RECOMMENDED）MSP 为入站邮件的处理通告 MX 记录（而非完全依赖 A 或 AAAA 记录），并且这些 MX 记录应使用 DNSSEC [RFC4033] 进行签名。此处提及此点仅为完整起见，因为入站邮件的处理超出了本文档的范围。

4.5.2. SRV 记录

MSP 应该（SHOULD）按照 [RFC6186] 中的说明通告 SRV 记录，以帮助 MUA 确定服务器的正确配置。

MSP 应该（SHOULD）优先通告支持隐式 TLS 的服务器，而非支持明文和/或 STARTTLS 操作的服务器。

4.5.3. DNSSEC

MSP 作为帮助客户端与其服务器通信的手段而通告的所有 DNS 记录，在父 DNS 区域支持进行签名时，应该（SHOULD）使用 DNSSEC 进行签名。

4.5.4. TLSA 记录

MSP 应该（SHOULD）通告 TLSA 记录，为 TLS 服务器证书中使用的公钥提供额外的信任锚。但是，除非 TLSA 记录使用 DNSSEC 进行了签名，否则不得（MUST NOT）通告 TLSA 记录。

4.6. 对面向 Internet 的服务器的变更

当 MSP 变更其面向 Internet 的邮件访问服务器与邮件提交服务器（包括基于 SMTP 的垃圾邮件/病毒过滤器）时，通常有必要支持与先前使用的版本相同或更新的 TLS 版本。

5. 邮件用户代理对 TLS 的使用

以下要求与建议适用于 MUA：

其他考量与细节见下文。

5.1. 在建立配置时使用 SRV 记录

本文档通过更改偏好规则并新增 SRV 服务标签 _submissions._tcp（指代使用隐式 TLS 的邮件提交）来更新 [RFC6186]。

用户可配置的 MUA 应该（SHOULD）支持使用 [RFC6186] 进行账户设置。然而，当使用通过该方法获得的配置信息时，MUA 应该（SHOULD）忽略不满足最低保密要求的通告服务，除非用户显式要求降低保密级别。这将产生如下效果：即使那些通告配置具有比其它通告配置更高的优先级，MUA 也会默认忽略不支持 TLS 的通告配置。

使用按照 [RFC6186] 的配置信息时，MUA 不应（SHOULD NOT）自动建立不要求所有服务器使用 TLS 的新配置，除非不存在使用 TLS 的通告配置。如果选择了这样的配置，在尝试向服务器认证或使用该服务器进行邮件提交之前，MUA 应该（SHOULD）警告用户，发往该服务器的流量将不被加密，因此很可能被未授权方截获。具体措辞由实现确定，但鉴于对电子邮件流量的大规模监控十分普遍，其应充分传达风险之意。

类似地，除非已与该服务器建立了满足最低保密级别的 TLS 会话，否则 MUA 不得（MUST NOT）通过向服务器提交用户的认证凭据来"测试"某个特定的邮件账户配置。如果最低保密要求未得到满足，MUA 必须在测试新配置之前明确警告用户的口令可能会暴露给攻击者。

当基于 SRV 记录为连接 IMAP、POP 或 SMTP 提交服务器建立新配置时，MUA 应该（SHOULD）验证以下任一条件成立：（a）SRV 记录使用 DNSSEC 进行了签名；或（b）SRV 记录的目标完全限定域名（FQDN）与发起 SRV 查询的原始服务器 FQDN 相匹配。如果目标 FQDN 不在所查询的域内，MUA 应该（SHOULD）在与该主机建立任何连接之前，与用户确认该 SRV 目标 FQDN 适合使用。（见 [RFC6186] 第 6 节。）

MUA 不得（MUST NOT）在每次连接尝试时都查询 SRV 记录以确定使用哪些服务器，除非那些 SRV 记录由 DNSSEC 签名且签名有效。但是，MUA 可以（MAY）不时查询 SRV 记录，以确定某 MSP 的服务器配置是否已变更，并在似乎发生此种情况时提醒用户。这也可以作为一种手段，在用户的 MSP 支持时，鼓励用户将其配置升级为要求 TLS。

5.2. 最低保密级别

MUA 应该（SHOULD）默认要求每个账户所访问服务的最低保密级别。对于支持访问多个邮件账户的 MUA，此要求应该（SHOULD）可按账户进行配置。

所有新账户的默认最低预期保密级别必须（MUST）要求成功验证服务器证书，并且应该（SHOULD）要求协商 TLS 1.1 或更高版本。（本规范的未来修订可能会提高这些要求或施加额外要求，以应对协议或加密算法中新发现的弱点。）

MUA 可以（MAY）允许用户在初始账户配置期间或随后编辑账户配置时禁用此最低保密要求，但必须（MUST）警告用户，这样的配置将无法保证口令或消息的隐私。

被配置为要求某邮件账户最低保密级别的 MUA，不得（MUST NOT）尝试执行除能力发现，或针对未使用隐式 TLS 的服务器的 STARTTLS 之外的任何操作，除非该连接提供了最低保密级别。

如果某账户被配置为施加最低保密要求，而该连接未满足所有这些要求，MUA 不应（SHOULD NOT）允许用户通过该连接轻松访问或发送邮件，或使用口令向任何服务认证。"轻松访问"的一个例子是：显示一个对话框告知用户该连接未满足账户的安全要求，但仍允许用户"点击通过（click through）"以发送邮件或访问该服务。经验表明，面对此类选项的用户常常会在不理解其所承担风险的情况下"点击通过"。而且，频繁发现需要"点击通过"才能使用不安全连接的用户，可能会养成习惯，在每次具体情形中考虑风险是否合理之前就这样做。

未被配置为要求某邮件账户最低保密级别的 MUA，仍应（SHOULD）尝试使用可用的最安全方式（例如，通过隐式 TLS 或 STARTTLS）连接到与该账户关联的服务。

5.3. 证书验证

MUA 必须（MUST）按照 [RFC7817] 与 PKIX [RFC5280] 验证 TLS 服务器证书。

MUA 也可以（MAY）支持基于 DNS 的命名实体认证（DANE）[RFC6698] 作为验证服务器证书以满足最低保密要求的一种手段。

MUA 可以（MAY）支持使用证书固定，但不得（MUST NOT）将服务器真实性依赖于证书固定的连接视为提供了最低保密级别。（见第 5.4 节。）

5.4. 证书固定

在账户设置期间，MUA 将识别提供账户服务（如邮件访问与邮件提交）的服务器（第 5.1 节描述了实现此目的的一种方式）。这些服务器的证书使用 [RFC7817] 与 PKIX [RFC5280] 中描述的规则进行验证。若证书因过期、缺乏适当的信任链或缺乏标识符匹配而无法验证，MUA 可以（MAY）提供在该证书与所保存的服务器主机名之间建立持久绑定，以供访问该账户服务器时使用。这被称为"证书固定（certificate pinning）"。

（注意：此处使用的"证书固定"一词，含义与 [RFC7469] 中描述的 HTTP 公钥固定略有不同。同一术语的双重使用令人困惑，但不幸的是两种用法都已牢固确立。）

证书固定仅适用于邮件账户设置期间，并且不得（MUST NOT）作为对现有邮件账户证书验证失败的响应选项提供。允许证书固定的 MUA，不得（MUST NOT）允许为一个账户固定的证书去验证其他账户的连接。允许证书固定的 MUA，也必须（MUST）允许用户撤销（undo）该固定，即撤销对先前已固定证书的信任。

固定的证书在账户设置时易遭受中间人攻击，并且通常缺乏自动撤销或安全刷新该证书的机制。还要注意，账户设置时的中间人攻击会暴露用户的口令给攻击者（若使用了口令）。因此，使用固定证书不满足最低保密级别的要求，MUA 不得（MUST NOT）向用户指示提供了此类保密性。关于证书固定的更多建议见 [RFC6125]。

5.5. 客户证书认证

MUA 可以（MAY）在隐式 TLS 端口上实现客户证书认证。除非服务器请求客户证书，且该 MUA 已被授权将该客户证书用于该账户，否则 MUA 不得（MUST NOT）在 TLS 握手期间提供客户证书。由最终用户显式配置某客户证书供给定账户使用，即足以满足此要求。但是，为某个账户安装的客户证书，不得（MUST NOT）自动授权在其他账户中使用该证书。这并非旨在禁止特定站点的授权机制，例如（a）由站点管理员控制的、授权在某给定账户使用客户证书的的机制，或（b）域名匹配机制。

注意：要求服务器请求证书，只是对 TLS 协议规则（例如 [RFC5246] 第 7.4.6 节）的重述。要求客户端不发送未知服务器是否可接受的证书，在多方面是务实的：当前 TLS 协议未提供任何方式让客户端知道它应使用的多个潜在证书中的哪一个；此外，当客户端发送证书时，它可能在向服务器以及任何能够访问传输介质的各方不必要且无益地披露其身份（或其用户的身份）。

支持客户证书认证与隐式 TLS 的客户端，必须（MUST）实现 SASL EXTERNAL 机制 [RFC4422]，使用适当的认证命令（POP3 [RFC5034] 的 AUTH、SMTP 提交 [RFC4954] 的 AUTH，或 IMAP [RFC3501] 的 AUTHENTICATE）。

6. 与防病毒/反垃圾邮件软件及服务相关的考量

有多种方式可将 AVAS 服务（例如"防病毒与反垃圾邮件"）连接到邮件服务器。某些机制，例如事实上的 "milter" 协议，超出了本规范的范围。然而，某些服务使用 SMTP 中继代理，在应用层拦截邮件以执行扫描并代理或转发到另一个邮件传输代理（MTA）。以这种方式部署 AVAS 服务可能引发许多问题 [RFC2979]，包括对本规范的直接干扰，以及其他形式的保密性或安全性降低。如果某 AVAS 产品或其包含的所有 IMAP、POP 与 SMTP 相关软件（包括代理）均符合本规范，则该产品被视为与本规范兼容。

注意，端到端电子邮件加密会阻止 AVAS 软件与服务使用邮件内容作为垃圾邮件或病毒评估的一部分。此外，尽管最低保密级别可以防止中间人能在 MUA 与提交服务器之间插入垃圾邮件或病毒内容，但它不能防止其他形式的客户端或账户泄露。因此，对提交的电子邮件使用 AVAS 服务仍然是必要的。

7. IANA 考量

7.1. POP3S 端口注册更新

IANA 已使用以下模板 [RFC6335] 更新了 TCP 熟知端口 995 的注册：

     Service Name: pop3s
     Transport Protocol: TCP
     Assignee: IESG <iesg@ietf.org>
     Contact: IETF Chair <chair@ietf.org>
     Description: POP3 over TLS protocol
     Reference: RFC 8314
     Port Number: 995

7.2. IMAPS 端口注册更新

IANA 已使用以下模板 [RFC6335] 更新了 TCP 熟知端口 993 的注册：

     Service Name: imaps
     Transport Protocol: TCP
     Assignee: IESG <iesg@ietf.org>
     Contact: IETF Chair <chair@ietf.org>
     Description: IMAP over TLS protocol
     Reference: RFC 8314
     Port Number: 993

未请求对 pop3s 或 imaps 现有的 UDP 端口分配进行任何变更。

7.3. Submissions 端口注册

IANA 已使用以下模板 [RFC6335] 在现有分配之外，为 TCP 端口 465 分配了一个替代用途：

     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

这是对 [RFC6335] 中规则的一次性程序性例外。这需要 IESG 的明确批准，且不构成先例。注意：由于此替代用途分配的目的是与广泛存在的既有实践保持一致，且已知没有将 UDP 端口 465 用于基于 TLS 的邮件提交的情况，因此 IANA 未为 UDP 端口 465 分配替代用途。

历史上，端口 465 曾短暂注册为 "smtps" 端口。这一注册毫无意义，因为 SMTP 传输的 MX 基础设施无法指定端口，因此始终使用端口 25。结果，该注册被撤销，随后被重新分配给另一项服务。事后看来，"smtps" 注册本应被重命名或保留，而非撤销。不幸的是，某些广泛部署的邮件软件将 "smtps" 解释为 "submissions" [RFC6409]，并在最终用户于账户设置期间请求安全时，默认将该端口用于电子邮件提交。如果为 submissions 服务分配新端口，则要么（a）邮件软件将继续未注册地使用端口 465（使端口注册表相对于事实实践不准确，并浪费一个熟知端口），要么（b）事实端口与注册端口之间的混淆将导致有害的互操作性问题，从而阻碍在邮件提交中使用 TLS。本文档作者认为，这两种结果都不如注册表中记录一个端口用于两种目的这一"疣（wart）"可取。尽管端口 587 上的 STARTTLS 已经部署，但它并未取代端口 465 上已部署的隐式 TLS 提交的使用。

7.4. "Received" 字段的额外已注册子句

根据 [RFC5321] 的规定，IANA 已为本文档第 4.3 节所定义的 Received 字段新增了两个额外已注册子句：

这些额外子句的描述与语法见本文档第 4.3 节。

8. 安全考量

整篇文档讨论的都是安全考量。一般而言，其目标是改进邮件保密性，并缓解电子邮件系统外部威胁（例如网络层面的窃听或拦截）；其并非旨在缓解已攻陷服务提供商系统的主动攻击者。

实现者应当知晓，在 TLS 1.2 中与客户证书一同使用会向任何能够读取传输介质中数据包的各方暴露用户的身份，因此可能损害用户的隐私。除了避免出示客户证书（除非有显式授权这样做）之外，TLS 1.2 或更早版本似乎没有简单的修复方法。TLS 1.3 [TLS-1.3] 似乎在一定程度上降低了这一隐私风险。

9. 参考文献

9.1. 规范性参考文献

9.2. 资料性参考文献

附录 A. 设计考量

本节不具规范性。

本文档的第一版独立于 [Email-TLS] 的 2013 年 10 月版本（"Recommendations for use of TLS by Electronic Mail Access Protocols"）撰写。后续版本合并了两个文档的思想。

本文档的一位作者同时也是 RFC 2595 的作者，该文档成为 POP 与 IMAP 使用 TLS 的标准；另一位作者或许是最早提出该想法的人。事后看来，两位作者现在都认为那种方法是一个错误。此时，作者们认为，尽管任何使 TLS 更易部署的做法都是好的，但理想的最终状态是这些协议始终使用 TLS，除了在遗留客户端仍在使用期间为其提供支持外，不再需要单独的明文操作端口。TLS 的分端口（separate-port）模型本质上更易于实现、调试与部署。它还支持一种"通用 TLS 负载均衡器"，接受任意 foo-over-TLS 协议的安全客户端连接，并将其转发给可能支持也可能不支持 TLS 的服务器。此类负载均衡器会引发许多问题，因为它们违反了端到端原则，并且除非协议被设计为转发该信息（如本规范就密码套件所做的那样），否则服务器丧失了记录关于客户端的安全相关信息的能力。然而，它们能够在原本不会发生 TLS 部署的地方促成 TLS 部署，这是一个足够重要的目标，足以压倒任何问题。

尽管 STARTTLS 看起来只比分端口 TLS 略复杂，我们再次得到了"复杂性是安全之敌"的教训，其表现形式为 STARTTLS 命令注入漏洞（计算机应急响应组（CERT）漏洞 ID #555316 [CERT-555316]）。尽管 STARTTLS 本身并无固有的错误，但它在多个实现者相互独立地犯下同一常见实现错误这一事实表明，它是一种不如隐式 TLS 安全的架构。

RFC 2595 的第 7 节批评了 TLS 的分端口方法。第一点批评是正确的。HTTP 社区已提出解决该问题的提案，而 RFC 6186 中描述的 SRV 记录使用方式解决了电子邮件领域中的该批评。第二点批评也是正确的，但并不十分重要，因为在电子邮件中实际部署 TLS 之外的其他安全层少到几乎可以忽略不计。（此外，由于现代 TLS 版本已不再支持"导出（export）"密码套件，它已不如过去那么正确。）第三点批评是不正确的，因为它遗漏了"一旦成功协商 TLS，便对随后到该服务器的所有连接使用 TLS"这一可取选项。第四点批评可能是正确的，但以当前的端口消耗速度来看尚不是问题。根本性的错误在于：将一个大体有效的批评所支撑的、被认定更优的设计，置于现实世界的可部署性之上。但是，实际部署安全与保密设施是如此重要，以至于它应当压倒对设计纯正性的考量。

端口 465 目前被用于两个目的：被大量客户端与服务提供商用于 submissions，以及被某一家厂商用于 "urd" 协议。如 IANA 考量一节所讨论，实际记录这一现状是有争议的。然而，没有好的替代方案。当端口 465 已广泛用于 submissions 时，为其注册新端口只会造成互操作性问题。注册一个仅在被 SRV 记录（RFC 6186）通告时才使用的端口不会造成互操作性问题，但将要求所有客户端部署、服务器部署与软件做出重大变更，这违背了促进 TLS 更广泛使用的目标。鼓励在端口 587 上使用 STARTTLS 不会造成互操作性问题，但它不太可能对当前未文档化的端口 465 使用产生任何影响，并使本文档中的指导不够一致。剩下的选项是记录世界的现状并支持未来在提交中使用端口 465，因为这增加了 TLS 电子邮件提交的一致性与部署便利。

致谢

感谢 Ned Freed 对本文档初始概念进行的讨论。感谢 Alexey Melnikov 提供 [POP3-over-TLS]，它是 POP3 隐式 TLS 文本的基础。感谢 Russ Housley、Alexey Melnikov 与 Dan Newman 提供的评审反馈。感谢 Paul Hoffman 在关于这一想法的初步讨论中提供有益的反馈。

作者地址

Keith Moore
Windrock, Inc.
PO Box 1934
Knoxville, TN 37901
United States of America
Email: moore@network-heretics.com

Chris Newman
Oracle
440 E. Huntington Dr., Suite 400
Arcadia, CA 91006
United States of America
Email: chris.newman@oracle.com