Internet Engineering Task Force (IETF) D. Margolis
Request for Comments: 8461 M. Risher
Category: Standards Track Google, Inc.
ISSN: 2070-1721 B. Ramakrishnan
Oath, Inc.
A. Brotman
Comcast, Inc.
J. Jones
Microsoft, Inc.
September 2018
Internet Engineering Task Force (IETF) D. Margolis
Request for Comments: 8461 M. Risher
Category: Standards Track Google, Inc.
ISSN: 2070-1721 B. Ramakrishnan
Oath, Inc.
A. Brotman
Comcast, Inc.
J. Jones
Microsoft, Inc.
September 2018
SMTP MTA Strict Transport Security (MTA-STS)
SMTP MTA严格传输安全（MTA-STS）
Abstract
摘要
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
SMTP MTA严格传输安全性（MTA-STS）是一种机制，使邮件服务提供商（SP）能够声明其接收传输层安全性（TLS）安全SMTP连接的能力，并指定发送SMTP服务器是否应拒绝向不提供具有可信服务器证书的TLS的MX主机发送。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8461.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8461.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 6
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 7
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 10
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 11
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 11
4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 12
4.2. Recipient MTA Certificate Validation . . . . . . . . . . 12
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 12
5.1. Policy Application Control Flow . . . . . . . . . . . . . 13
6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 13
7. Interoperability Considerations . . . . . . . . . . . . . . . 14
7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 14
8. Operational Considerations . . . . . . . . . . . . . . . . . 15
8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 15
8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 15
8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 16
8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 17
9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 17
9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 18
10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 19
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 19
10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 20
10.5. Compromise of the Web PKI System . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. MTA-STS Example Record and Policy . . . . . . . . . 25
Appendix B. Message Delivery Pseudocode . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
3. Policy Discovery . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MTA-STS TXT Records . . . . . . . . . . . . . . . . . . . 6
3.2. MTA-STS Policies . . . . . . . . . . . . . . . . . . . . 7
3.3. HTTPS Policy Fetching . . . . . . . . . . . . . . . . . . 10
3.4. Policy Selection for Smart Hosts and Subdomains . . . . . 11
4. Policy Validation . . . . . . . . . . . . . . . . . . . . . . 11
4.1. MX Host Validation . . . . . . . . . . . . . . . . . . . 12
4.2. Recipient MTA Certificate Validation . . . . . . . . . . 12
5. Policy Application . . . . . . . . . . . . . . . . . . . . . 12
5.1. Policy Application Control Flow . . . . . . . . . . . . . 13
6. Reporting Failures . . . . . . . . . . . . . . . . . . . . . 13
7. Interoperability Considerations . . . . . . . . . . . . . . . 14
7.1. SNI Support . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Minimum TLS Version Support . . . . . . . . . . . . . . . 14
8. Operational Considerations . . . . . . . . . . . . . . . . . 15
8.1. Policy Updates . . . . . . . . . . . . . . . . . . . . . 15
8.2. Policy Delegation . . . . . . . . . . . . . . . . . . . . 15
8.3. Removing MTA-STS . . . . . . . . . . . . . . . . . . . . 16
8.4. Preserving MX Candidate Traversal . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Well-Known URIs Registry . . . . . . . . . . . . . . . . 17
9.2. MTA-STS TXT Record Fields . . . . . . . . . . . . . . . . 17
9.3. MTA-STS Policy Fields . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10.1. Obtaining a Signed Certificate . . . . . . . . . . . . . 18
10.2. Preventing Policy Discovery . . . . . . . . . . . . . . 19
10.3. Denial of Service . . . . . . . . . . . . . . . . . . . 19
10.4. Weak Policy Constraints . . . . . . . . . . . . . . . . 20
10.5. Compromise of the Web PKI System . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. MTA-STS Example Record and Policy . . . . . . . . . 25
Appendix B. Message Delivery Pseudocode . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to negotiate the use of a TLS channel for encrypted mail transmission.
SMTP[RFC3207]的STARTTLS扩展允许SMTP客户端和主机协商使用TLS通道进行加密邮件传输。
While this opportunistic encryption protocol by itself provides a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform downgrade or interception attacks.
虽然这种机会主义加密协议本身为被动中间人流量拦截提供了很高的屏障，但任何可以删除部分SMTP会话（如“250 STARTTLS”响应）或重定向整个SMTP会话（可能通过覆盖传递域的已解析MX记录）的攻击者可以执行降级或拦截攻击。
This document defines a mechanism for recipient domains to publish policies, via a combination of DNS and HTTPS, specifying:
本文档定义了收件人域通过DNS和HTTPS组合发布策略的机制，指定：
o whether MTAs sending mail to this domain can expect PKIX-authenticated TLS support
o 向此域发送邮件的MTA是否可以获得PKIX验证的TLS支持
o what a conforming client should do with messages when TLS cannot be successfully negotiated
o 当TLS无法成功协商时，一致性客户端应如何处理消息
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
We also define the following terms for further use in this document:
我们还定义了以下术语，以便在本文件中进一步使用：
o MTA-STS Policy: A commitment by the Policy Domain to support TLS authenticated with PKIX [RFC5280] for the specified MX hosts.
o MTA-STS策略：策略域承诺为指定的MX主机支持通过PKIX[RFC5280]验证的TLS。
o Policy Domain: The domain for which an MTA-STS Policy is defined. This is the next-hop domain; when sending mail to "alice@example.com", this would ordinarily be "example.com", but this may be overridden by explicit routing rules (as described in Section 3.4, "Policy Selection for Smart Hosts and Subdomains").
o 策略域：为其定义MTA-STS策略的域。这是下一跳域；将邮件发送到“”时alice@example.com，这通常是“example.com”，但这可能会被显式路由规则覆盖（如第3.4节“智能主机和子域的策略选择”所述）。
o Policy Host: The HTTPS host that serves the MTA-STS Policy for a Policy Domain. Rules for constructing the hostname are described in Section 3.2, "MTA-STS Policies".
o 策略主机：为策略域的MTA-STS策略提供服务的HTTPS主机。第3.2节“MTA-STS策略”中描述了构造主机名的规则。
o Sender or Sending MTA: The SMTP MTA sending an email message.
o 发件人或发送MTA：发送电子邮件的SMTP MTA。
o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying syntax, defined in [RFC5234] and [RFC7405].
o ABNF:Augmented Backus Naur Form，一种正式指定语法的语法，在[RFC5234]和[RFC7405]中定义。
The DNS-Based Authentication of a Named Entities (DANE) TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades. For a thorough discussion of this trade-off, see Section 10, "Security Considerations".
命名实体（DANE）TLSA记录[RFC7672]的基于DNS的身份验证类似，因为DANE还设计用于将未经身份验证的加密或明文传输升级为经身份验证、抗降级的加密传输。丹麦要求DNSSEC[RFC4033]进行认证；相反，本文描述的机制依赖于证书颁发机构（CA），不需要DNSSEC，代价是存在恶意降级的风险。有关这一权衡的详细讨论，请参见第10节“安全考虑”。
In addition, MTA-STS provides an optional testing-only mode, enabling soft deployments to detect policy failures; partial deployments can be achieved in DANE by deploying TLSA records only for some of a domain's MXes, but such a mechanism is not possible for the per-domain policies used by MTA-STS.
此外，MTA-STS提供了可选的仅测试模式，使软部署能够检测策略故障；通过仅为某些域的MXE部署TLSA记录，可以在丹麦实现部分部署，但对于MTA-STS使用的每个域策略，这种机制是不可能的。
The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow MTA-STS Policy validation to override a failing DANE validation.
MTA-STS的主要动机是为域提供一种机制，以确保传输安全，即使部署DNSSEC是不可取的或不切实际的。但是，MTA-STS的设计目的是在两者重叠时不干扰DANE部署；特别是，实施MTA-STS验证的发件人不得允许MTA-STS策略验证覆盖失败的DANE验证。
MTA-STS policies are distributed via HTTPS from a "well-known" [RFC5785] path served within the Policy Domain, and their presence and current version are indicated by a TXT record at the Policy Domain. These TXT records additionally contain a policy "id" field, allowing Sending MTAs to check that a cached policy is still current without performing an HTTPS request.
MTA-STS策略通过HTTPS从策略域中提供的“已知”[RFC5785]路径分发，策略域中的TXT记录指示它们的存在和当前版本。这些TXT记录还包含一个策略“id”字段，允许发送MTA检查缓存的策略是否仍然是最新的，而无需执行HTTPS请求。
To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record. To see if an updated policy is available for a domain for which the sender has a previously cached policy, the sender need only check the TXT record's version "id" against the cached value.
要发现收件人域是否实现MTA-STS，发件人只需解析单个TXT记录。若要查看已更新的策略是否适用于发送方具有以前缓存的策略的域，发送方只需对照缓存的值检查TXT记录的版本“id”。
The MTA-STS TXT record is a TXT record with the name "_mta-sts" at the Policy Domain. For the domain "example.com", this record would be "_mta-sts.example.com". MTA-STS TXT records MUST be US-ASCII, semicolon-separated key/value pairs containing the following fields:
MTA-STS TXT记录是策略域中名为“\u MTA-STS”的TXT记录。对于域“example.com”，此记录将是“\u mta-sts.example.com”。MTA-STS TXT记录必须是US-ASCII、分号分隔的键/值对，包含以下字段：
o "v" (plaintext, required): Currently, only "STSv1" is supported.
o “v”（纯文本，必填）：目前仅支持“STSv1”。
o "id" (plaintext, required): A short string used to track policy updates. This string MUST uniquely identify a given instance of a policy, such that senders can determine when the policy has been updated by comparing to the "id" of a previously seen policy. There is no implied ordering of "id" fields between revisions.
o “id”（纯文本，必填）：用于跟踪策略更新的短字符串。此字符串必须唯一标识策略的给定实例，以便发件人可以通过与以前看到的策略的“id”进行比较来确定策略何时已更新。修订之间没有“id”字段的隐含顺序。
An example TXT record is as below:
TXT记录示例如下所示：
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
The formal definition of the "_mta-sts" TXT record, defined using ABNF [RFC7405], is as follows:
使用ABNF[RFC7405]定义的“_mta-sts”TXT记录的正式定义如下：
sts-text-record = sts-version 1*(sts-field-delim sts-field) [sts-field-delim]
sts文本记录=sts版本1*（sts字段删除列表字段）[sts字段删除]
sts-field = sts-id / ; Note that sts-id record sts-extension ; is required.
sts字段=sts id/；注意sts id记录sts扩展；是必需的。
sts-field-delim = *WSP ";" *WSP
sts-field-delim = *WSP ";" *WSP
sts-version = %s"v=STSv1"
sts-version = %s"v=STSv1"
sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=...
sts-id = %s"id=" 1*32(ALPHA / DIGIT) ; id=...
sts-extension = sts-ext-name "=" sts-ext-value ; name=value
sts-extension = sts-ext-name "=" sts-ext-value ; name=value
sts-ext-name = (ALPHA / DIGIT)
*31(ALPHA / DIGIT / "_" / "-" / ".")
sts-ext-name = (ALPHA / DIGIT)
*31(ALPHA / DIGIT / "_" / "-" / ".")
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and CTLs
sts-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and CTLs
The TXT record MUST begin with the sts-version field; the order of other fields is not significant. If multiple TXT records for "_mta-sts" are returned by the resolver, records that do not begin with "v=STSv1;" are discarded. If the number of resulting records is not one, or if the resulting record is syntactically invalid, senders MUST assume the recipient domain does not have an available MTA-STS
TXT记录必须以sts版本字段开头；其他字段的顺序不重要。如果解析程序返回多个“\u mta-sts”的TXT记录，则不以“v=STSv1；”开头的记录将被丢弃。如果生成的记录数不是一个，或者生成的记录在语法上无效，则发件人必须假定收件人域没有可用的MTA-STS
Policy and skip the remaining steps of policy discovery. (Note that the absence of a usable TXT record is not by itself sufficient to remove a sender's previously cached policy for the Policy Domain, as discussed in Section 5.1, "Policy Application Control Flow".) If the resulting TXT record contains multiple strings, then the record MUST be treated as if those strings are concatenated without adding spaces.
策略，并跳过策略发现的其余步骤。（请注意，如第5.1节“策略应用程序控制流”所述，缺少可用的TXT记录本身不足以删除策略域的发送方以前缓存的策略。）如果生成的TXT记录包含多个字符串，然后，必须将记录视为在不添加空格的情况下连接这些字符串。
The "_mta-sts" record MAY return a CNAME that points (directly or via other CNAMEs) to a TXT record, in which case senders MUST follow the CNAME pointers. This can be used for policy delegation, as described in Section 8.2.
“_mta-sts”记录可能返回指向（直接或通过其他CNAME）TXT记录的CNAME，在这种情况下，发件人必须遵循CNAME指针。如第8.2节所述，这可用于政策授权。
The policy itself is a set of key/value pairs (similar to header fields in [RFC5322]) served via the HTTPS GET method from the fixed "well-known" [RFC5785] path of ".well-known/mta-sts.txt" served by the Policy Host. The Policy Host DNS name is constructed by prepending "mta-sts" to the Policy Domain.
策略本身是一组键/值对（类似于[RFC5322]中的头字段），通过HTTPS GET方法从策略主机提供的“.well-known/mta sts.txt”的固定“well-known”[RFC5785]路径提供服务。策略主机DNS名称是通过在策略域前面加上“mta sts”来构造的。
Thus, for a Policy Domain of "example.com", the full URL is "https://mta-sts.example.com/.well-known/mta-sts.txt".
因此，对于“example.com”的策略域，完整URL为“https://mta-sts.example.com/.well-known/mta-sts.txt".
When fetching a policy, senders SHOULD validate that the media type is "text/plain" to guard against cases where web servers allow untrusted users to host non-text content (typically, HTML or images) at a user-defined path. All parameters other than charset=utf-8 or charset=us-ascii are ignored. Additional "Content-Type" parameters are also ignored.
获取策略时，发件人应验证媒体类型是否为“文本/普通”，以防止web服务器允许不受信任的用户以用户定义的路径承载非文本内容（通常为HTML或图像）。忽略除charset=utf-8或charset=us ascii以外的所有参数。其他“内容类型”参数也将被忽略。
This resource contains the following CRLF-separated key/value pairs:
此资源包含以下CRLF分隔键/值对：
o "version": Currently, only "STSv1" is supported.
o “版本”：目前只支持“STSv1”。
o "mode": One of "enforce", "testing", or "none", indicating the expected behavior of a Sending MTA in the case of a policy validation failure. See Section 5, "Policy Application", for more details about the three modes.
o “模式”：是“强制”、“测试”或“无”之一，表示在策略验证失败的情况下发送MTA的预期行为。有关这三种模式的更多详细信息，请参见第5节“政策应用”。
o "max_age": Max lifetime of the policy (plaintext non-negative integer seconds, maximum value of 31557600). Well-behaved clients SHOULD cache a policy for up to this value from the last policy fetch time. To mitigate the risks of attacks at policy refresh time, it is expected that this value typically be in the range of weeks or greater.
o “max_age”：策略的最大生存期（纯文本非负整数秒，最大值31557600）。行为良好的客户机应该缓存一个策略，从上次策略获取时间起，最多可缓存此值。为了降低策略刷新时的攻击风险，预计此值通常在数周或更长的范围内。
o "mx": Allowed MX patterns. One or more patterns matching allowed MX hosts for the Policy Domain. As an example,
o “mx”：允许的mx模式。一个或多个模式匹配策略域允许的MX主机。例如,，
mx: mail.example.com <CRLF>
mx: *.example.net
mx: mail.example.com <CRLF>
mx: *.example.net
indicates that mail for this domain might be handled by MX "mail.example.com" or any MX at "example.net". Valid patterns can be either fully specified names ("example.com") or suffixes prefixed by a wildcard ("*.example.net"). If a policy specifies more than one MX, each MX MUST have its own "mx:" key, and each MX key/value pair MUST be on its own line in the policy file. In the case of Internationalized Domain Names [RFC5891], the "mx" value MUST specify the Punycode-encoded A-label [RFC3492] to match against, and not the Unicode-encoded U-label. The full semantics of certificate validation (including the use of wildcard patterns) are described in Section 4.1, "MX Host Validation".
表示此域的邮件可能由MX“mail.example.com”或“example.net”上的任何MX处理。有效模式可以是完全指定的名称（“example.com”）或以通配符（*.example.net）作为前缀的后缀。如果策略指定了多个MX，则每个MX必须有自己的“MX:”密钥，并且每个MX密钥/值对必须位于策略文件中自己的行上。对于国际化域名[RFC5891]，“mx”值必须指定要匹配的Punycode编码的A标签[RFC3492]，而不是Unicode编码的U标签。第4.1节“MX主机验证”描述了证书验证的完整语义（包括通配符模式的使用）。
An example policy is as below:
一个示例策略如下所示：
version: STSv1 mode: enforce mx: mail.example.com mx: *.example.net mx: backupmx.example.com max_age: 604800
版本：STSv1模式：强制mx:mail.example.com mx:*.example.net mx:backupmx.example.com最大年龄：604800
The formal definition of the policy resource, defined using ABNF [RFC7405], is as follows:
使用ABNF[RFC7405]定义的策略资源的正式定义如下：
sts-policy-record = sts-policy-field *WSP *(sts-policy-term sts-policy-field *WSP) [sts-policy-term]
sts策略记录=sts策略字段*WSP*（sts策略术语sts策略字段*WSP）[sts策略术语]
sts-policy-field = sts-policy-version / ; required once
sts-policy-mode / ; required once
sts-policy-max-age / ; required once
sts-policy-mx /
; required at least once, except when
; mode is "none"
sts-policy-extension ; other fields
sts-policy-field = sts-policy-version / ; required once
sts-policy-mode / ; required once
sts-policy-max-age / ; required once
sts-policy-mx /
; required at least once, except when
; mode is "none"
sts-policy-extension ; other fields
sts-policy-field-delim = ":" *WSP
sts-policy-field-delim = ":" *WSP
sts-policy-version = sts-policy-version-field sts-policy-field-delim sts-policy-version-value
sts策略版本=sts策略版本字段sts策略字段删除列表策略版本值
sts-policy-version-field = %s"version"
sts-policy-version-field = %s"version"
sts-policy-version-value = %s"STSv1"
sts-policy-version-value = %s"STSv1"
sts-policy-mode = sts-policy-mode-field sts-policy-field-delim sts-policy-mode-value
sts策略模式=sts策略模式字段sts策略字段删除列表策略模式值
sts-policy-mode-field = %s"mode"
sts-policy-mode-field = %s"mode"
sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
sts-policy-mode-value = %s"testing" / %s"enforce" / %s"none"
sts-policy-mx = sts-policy-mx-field sts-policy-field-delim sts-policy-mx-value
sts策略mx=sts策略mx字段sts策略字段删除列表策略mx值
sts-policy-mx-field = %s"mx"
sts-policy-mx-field = %s"mx"
sts-policy-mx-value = ["*."] Domain
sts-policy-mx-value = ["*."] Domain
sts-policy-max-age = sts-policy-max-age-field sts-policy-field-delim sts-policy-max-age-value
sts策略最大年龄=sts策略最大年龄字段sts策略字段删除列表策略最大年龄值
sts-policy-max-age-field = %s"max_age"
sts-policy-max-age-field = %s"max_age"
sts-policy-max-age-value = 1*10(DIGIT)
sts-policy-max-age-value = 1*10(DIGIT)
sts-policy-extension = sts-policy-ext-name ; additional sts-policy-field-delim ; extension sts-policy-ext-value ; fields
sts策略扩展=sts策略扩展名；额外的sts策略域删除；扩展sts策略扩展值；领域
sts-policy-ext-name = (sts-policy-alphanum)
*31(sta-policy-alphanum / "_" / "-" / ".")
sts-policy-ext-name = (sts-policy-alphanum)
*31(sta-policy-alphanum / "_" / "-" / ".")
sts-policy-term = LF / CRLF
sts-policy-term = LF / CRLF
sts-policy-ext-value = sts-policy-vchar
[*(%x20 / sts-policy-vchar)
sts-policy-vchar]
; chars, including UTF-8 [RFC3629],
; excluding CTLs and no
; leading/trailing spaces
sts-policy-ext-value = sts-policy-vchar
[*(%x20 / sts-policy-vchar)
sts-policy-vchar]
; chars, including UTF-8 [RFC3629],
; excluding CTLs and no
; leading/trailing spaces
sts-policy-alphanum = ALPHA / DIGIT
sts-policy-alphanum = ALPHA / DIGIT
sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
sts-policy-vchar = %x21-7E / UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of [RFC3629]>
UTF8-2 = <Defined in Section 4 of [RFC3629]>
UTF8-3 = <Defined in Section 4 of [RFC3629]>
UTF8-3 = <Defined in Section 4 of [RFC3629]>
UTF8-4 = <Defined in Section 4 of [RFC3629]>
UTF8-4 = <Defined in Section 4 of [RFC3629]>
Domain = <Defined in Section 4.1.2 of [RFC5321]>
Domain = <Defined in Section 4.1.2 of [RFC5321]>
Parsers MUST accept TXT records and policy files that are syntactically valid (i.e., valid key/value pairs separated by semicolons for TXT records), possibly containing additional key/value pairs not specified in this document, in which case unknown fields SHALL be ignored. If any non-repeated field -- i.e., all fields excepting "mx" -- is duplicated, all entries except for the first SHALL be ignored.
解析器必须接受语法有效的TXT记录和策略文件（即，TXT记录的有效键/值对由分号分隔），可能包含本文档中未指定的其他键/值对，在这种情况下，应忽略未知字段。如果任何非重复字段（即除“mx”之外的所有字段）重复，则应忽略除第一个字段以外的所有条目。
Policy bodies are, as described above, retrieved by Sending MTAs via HTTPS [RFC2818]. During the TLS handshake initiated to fetch a new or updated policy from the Policy Host, the Policy Host HTTPS server MUST present an X.509 certificate that is valid for the "mta-sts" DNS-ID [RFC6125] (e.g., "mta-sts.example.com") as described below, chain to a root CA that is trusted by the Sending MTA, and be non-expired. It is expected that Sending MTAs use a set of trusted CAs similar to those in widely deployed web browsers and operating systems. See [RFC5280] for more details about certificate verification.
如上所述，通过HTTPS[RFC2818]发送MTA来检索策略主体。在为从策略主机获取新的或更新的策略而启动的TLS握手期间，策略主机HTTPS服务器必须提供一个X.509证书，该证书对“mta sts”DNS-ID[RFC6125]（例如，“mta sts.example.com”）有效，如下所述，链接到发送mta信任的根CA，并且证书未过期。预计发送MTA将使用一组受信任的CA，类似于广泛部署的web浏览器和操作系统中的CA。有关证书验证的更多详细信息，请参阅[RFC5280]。
The certificate is valid for the Policy Host (i.e., "mta-sts" prepended to the Policy Domain) with respect to the rules described in [RFC6125], with the following application-specific considerations:
根据[RFC6125]中描述的规则，该证书对策略主机（即策略域前面的“mta sts”）有效，并考虑以下特定于应用程序的因素：
o Matching is performed only against the DNS-ID identifiers.
o 仅对DNS-ID标识符执行匹配。
o DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier.
o 服务器证书中的DNS域名可能包含通配符“*”作为标识符中最左侧的完整标签。
The certificate MAY be checked for revocation via the Online Certificate Status Protocol (OCSP) [RFC6960], certificate revocation lists (CRLs), or some other mechanism.
可通过在线证书状态协议（OCSP）[RFC6960]、证书撤销列表（CRL）或某些其他机制检查证书的撤销。
Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK). HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in [RFC7234]) MUST NOT be used.
通过HTTPS获取的策略仅在HTTP响应代码为200（确定）时有效。不得遵循HTTP 3xx重定向，不得使用HTTP缓存（如[RFC7234]中所述）。
Senders may wish to rate-limit the frequency of attempts to fetch the HTTPS endpoint even if a valid TXT record for the recipient domain exists. In the case where the HTTPS GET fails, implementers SHOULD limit further attempts to a period of five minutes or longer per version ID, to avoid overwhelming resource-constrained recipients with cascading failures.
即使存在收件人域的有效TXT记录，发件人也可能希望限制尝试获取HTTPS端点的频率。在HTTPS GET失败的情况下，实现者应将每个版本ID的进一步尝试限制在5分钟或更长的时间内，以避免级联失败导致资源受限的收件人无法承受。
Senders MAY impose a timeout on the HTTPS GET and/or a limit on the maximum size of the response body to avoid long delays or resource exhaustion during attempted policy updates. A suggested timeout is one minute, and a suggested maximum policy size is 64 kilobytes; Policy Hosts SHOULD respond to requests with a complete policy body within that timeout and size limit.
发件人可能会对HTTPS GET施加超时和/或对响应正文的最大大小施加限制，以避免在尝试策略更新期间出现长时间延迟或资源耗尽。建议的超时为一分钟，建议的最大策略大小为64 KB；策略主机应在该超时和大小限制内使用完整的策略主体响应请求。
If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS.
如果找到有效的TXT记录，但无法通过HTTPS获取任何策略（出于任何原因），并且以前没有有效（未过期）的缓存策略，则发件人必须继续传递，就像域未实现MTA-STS一样。
Conversely, if no "live" policy can be discovered via DNS or fetched via HTTPS, but a valid (non-expired) policy exists in the sender's cache, the sender MUST apply that cached policy.
相反，如果无法通过DNS发现或通过HTTPS获取“实时”策略，但发送方缓存中存在有效（未过期）策略，则发送方必须应用该缓存策略。
Finally, to mitigate the risk of persistent interference with policy refresh, as discussed in-depth in Section 10, MTAs SHOULD proactively refresh cached policies before they expire; a suggested refresh frequency is once per day. To enable administrators to discover problems with policy refresh, MTAs SHOULD alert administrators (through the use of logs or similar) when such attempts fail, unless the cached policy mode is "none".
最后，如第10节中深入讨论的，为了降低策略刷新的持续干扰风险，MTA应在缓存策略过期之前主动刷新缓存策略；建议的刷新频率为每天一次。为使管理员能够发现策略刷新问题，MTA应在此类尝试失败时（通过使用日志或类似工具）通知管理员，除非缓存策略模式为“无”。
When sending mail via a "smart host" -- an administratively configured intermediate SMTP relay, which is different from the message recipient's server as determined from DNS -- compliant senders MUST treat the smart host domain as the Policy Domain for the purposes of policy discovery and application. This specification does not provide a means of associating policies with email addresses that employ Address Literals [RFC5321].
当通过“智能主机”（管理配置的中间SMTP中继，与通过DNS确定的邮件收件人服务器不同）发送邮件时，兼容发件人必须将智能主机域视为策略域，以便进行策略发现和应用。本规范不提供将策略与使用地址文字的电子邮件地址关联的方法[RFC5321]。
When sending mail to a mailbox at a subdomain, compliant senders MUST NOT attempt to fetch a policy from the parent zone. Thus, for mail sent to "user@mail.example.com", the policy can be fetched only from "mail.example.com", not "example.com".
向子域中的邮箱发送邮件时，符合要求的发件人不得尝试从父区域获取策略。因此，对于发送到user@mail.example.com，只能从“mail.example.com”获取策略，而不能从“example.com”获取策略。
When sending to an MX at a domain for which the sender has a valid and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST check whether:
当发送到发件人具有有效且未过期MTA-STS策略的域中的MX时，遵守MTA-STS的发送MTA必须检查是否：
1. At least one of the policy's "mx" patterns matches the selected MX host, as described in Section 4.1, "MX Host Validation".
1. 至少有一个策略的“mx”模式与所选mx主机匹配，如第4.1节“mx主机验证”所述。
2. The recipient mail server supports STARTTLS and offers a PKIX-based TLS certificate, during TLS handshake, which is valid for that host, as described in Section 4.2, "Recipient MTA Certificate Validation".
2. 收件人邮件服务器支持STARTTLS，并在TLS握手期间提供基于PKIX的TLS证书，该证书对该主机有效，如第4.2节“收件人MTA证书验证”所述。
When these conditions are not met, a policy is said to fail to validate. This section does not dictate the behavior of Sending MTAs when the above conditions are not met; see Section 5, "Policy Application", for a description of Sending MTA behavior when policy validation fails.
如果不满足这些条件，则称策略无法验证。本节不规定在不满足上述条件时发送MTA的行为；有关策略验证失败时发送MTA行为的说明，请参见第5节“策略应用程序”。
A receiving candidate MX host is valid according to an applied MTA-STS Policy if the MX record name matches one or more of the "mx" fields in the applied policy. Matching is identical to the rules given in [RFC6125], with the restriction that the wildcard character '*' may only be used to match the entire left-most label in the presented identifier. Thus, the mx pattern "*.example.com" matches "mail.example.com" but not "example.com" or "foo.bar.example.com".
如果MX记录名称与应用策略中的一个或多个“MX”字段匹配，则根据应用的MTA-STS策略，接收候选MX主机是有效的。匹配与[RFC6125]中给出的规则相同，但有一个限制，即通配符“*”只能用于匹配所提供标识符中最左侧的整个标签。因此，mx模式“*.example.com”匹配“mail.example.com”，但不匹配“example.com”或“foo.bar.example.com”。
The certificate presented by the receiving MTA MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA. The certificate MUST have a subject alternative name (SAN) [RFC5280] with a DNS-ID [RFC6125] matching the hostname, per the rules given in [RFC6125]. The MX's certificate MAY also be checked for revocation via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism.
接收MTA提供的证书不得过期，并且必须链接到发送MTA信任的根CA。根据[RFC6125]中给出的规则，证书必须具有与主机名匹配的DNS-ID[RFC6125]的使用者备选名称（SAN）[RFC5280]。MX的证书也可以通过OCSP[RFC6960]、CRLs[RFC6818]或其他机制进行撤销检查。
When sending to an MX at a domain for which the sender has a valid, non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies the result of a policy validation failure in one of two ways, depending on the value of the policy "mode" field:
当发送到发件人具有有效且未过期的MTA-STS策略的域中的MX时，遵守MTA-STS的发送MTA将以两种方式之一应用策略验证失败的结果，具体取决于策略“模式”字段的值：
1. "enforce": In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS.
1. “强制”：在此模式下，发送MTA不得将消息传递给MX匹配或证书验证失败或不支持STARTTLS的主机。
2. "testing": In this mode, Sending MTAs that also implement the TLSRPT (TLS Reporting) specification [RFC8460] send a report indicating policy application failures (as long as TLSRPT is also implemented by the recipient domain); in any case, messages may be delivered as though there were no MTA-STS validation failure.
2. “测试”：在此模式下，发送同时实现TLSRPT（TLS报告）规范[RFC8460]的MTA时，会发送一份指示策略应用程序失败的报告（只要接收方域也实现了TLSRPT）；在任何情况下，邮件都可能会被传递，就好像没有MTA-STS验证失败一样。
3. "none": In this mode, Sending MTAs should treat the Policy Domain as though it does not have any active policy; see Section 8.3, "Removing MTA-STS", for use of this mode value.
3. “无”：在此模式下，发送MTA应将策略域视为没有任何活动策略；有关此模式值的使用，请参见第8.3节“删除MTA-STS”。
When a message fails to deliver due to an "enforce" policy, a compliant MTA MUST NOT permanently fail to deliver messages before checking, via DNS, for the presence of an updated policy at the Policy Domain. (In all cases, MTAs SHOULD treat such failures as transient errors and retry delivery later.) This allows implementing domains to update long-lived policies on the fly.
当邮件由于“强制”策略而无法传递时，在通过DNS检查策略域中是否存在更新的策略之前，符合要求的MTA不得永久无法传递邮件。（在所有情况下，MTA都应将此类故障视为暂时性错误，稍后重试传递。）这允许实现域动态更新长期策略。
An example control flow for a compliant sender consists of the following steps:
兼容发送器的示例控制流包括以下步骤：
1. Check for a cached policy whose time-since-fetch has not exceeded its "max_age". If none exists, attempt to fetch a new policy (perhaps asynchronously, so as not to block message delivery). Optionally, Sending MTAs may unconditionally check for a new policy at this step.
1. 检查自获取后的时间未超过其“最长时间”的缓存策略。如果不存在任何策略，请尝试获取新策略（可能是异步的，以便不阻止消息传递）。或者，发送MTA可以在此步骤无条件检查新策略。
2. For each candidate MX, in order of MX priority, attempt to deliver the message. If a policy is present with an "enforce" mode, when attempting to deliver to each candidate MX, ensure STARTTLS support and host identity validity as described in Section 4, "Policy Validation". If a candidate fails validation, continue to the next candidate (if there is one).
2. 对于每个候选MX，按照MX优先级的顺序，尝试传递消息。如果策略采用“强制”模式，则在尝试向每个候选MX交付时，应确保第4节“策略验证”中所述的STARTTLS支持和主机标识有效性。如果某个候选项未通过验证，请继续下一个候选项（如果有）。
3. A message delivery attempt MUST NOT be permanently failed until the sender has first checked for the presence of a new policy (as indicated by the "id" field in the "_mta-sts" TXT record). If a new policy is not found, existing rules for the case of temporary message delivery failures apply (as discussed in [RFC5321], Section 4.5.4.1).
3. 在发件人首先检查是否存在新策略（如“\u mta-sts”TXT记录中的“id”字段所示）之前，邮件传递尝试不得永久失败。如果未找到新策略，则适用临时消息传递失败情况下的现有规则（如[RFC5321]第4.5.4.1节所述）。
MTA-STS is intended to be used along with TLSRPT [RFC8460] in order to ensure that implementing domains can detect cases of both benign and malicious failures and to ensure that failures that indicate an active attack are discoverable. As such, senders that also implement TLSRPT SHOULD treat the following events as reportable failures:
MTA-STS拟与TLSRPT[RFC8460]一起使用，以确保实施域能够检测良性和恶意故障，并确保可发现指示主动攻击的故障。因此，同样实现TLSRPT的发送方应将以下事件视为可报告的故障：
o HTTPS policy fetch failures when a valid TXT record is present.
o 存在有效TXT记录时HTTPS策略获取失败。
o Policy fetch failures of any kind when a valid policy exists in the policy cache, except if that policy's mode is "none".
o 当策略缓存中存在有效策略时，任何类型的策略获取失败，除非该策略的模式为“无”。
o Delivery attempts in which a contacted MX does not support STARTTLS or does not present a certificate that validates according to the applied policy, except if that policy's mode is "none".
o 传递尝试，其中联系的MX不支持STARTTLS或不提供根据应用的策略进行验证的证书，除非该策略的模式为“无”。
To ensure that the server sends the right certificate chain, the SMTP client MUST have support for the TLS Server Name Indication (SNI) extension [RFC6066]. When connecting to an HTTP server to retrieve the MTA-STS Policy, the SNI extension MUST contain the name of the Policy Host (e.g., "mta-sts.example.com"). When connecting to an SMTP server, the SNI extension MUST contain the MX hostname.
为确保服务器发送正确的证书链，SMTP客户端必须支持TLS服务器名称指示（SNI）扩展[RFC6066]。连接到HTTP服务器以检索MTA-STS策略时，SNI扩展必须包含策略主机的名称（例如，“MTA STS.example.com”）。连接到SMTP服务器时，SNI扩展必须包含MX主机名。
HTTP servers used to deliver MTA-STS policies MAY rely on SNI to determine which certificate chain to present to the client. HTTP servers MUST respond with a certificate chain that matches the policy hostname or abort the TLS handshake if unable to do so. Clients that do not send SNI information may not see the expected certificate chain.
用于交付MTA-STS策略的HTTP服务器可能依赖SNI来确定要向客户端呈现的证书链。HTTP服务器必须使用与策略主机名匹配的证书链进行响应，如果无法这样做，则中止TLS握手。不发送SNI信息的客户端可能看不到预期的证书链。
SMTP servers MAY rely on SNI to determine which certificate chain to present to the client. However, servers that have one identity and a single matching certificate do not require SNI support. Servers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server. If the client sends no SNI extension or sends an SNI extension for an unsupported server name, the server MUST simply send a fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that MTA-STS TLS clients may be typically willing to accept multiple server names but can only send one name in the SNI extension. The server's fallback certificate may match a different name that is acceptable to the client, e.g., the original next-hop domain.
SMTP服务器可能依赖SNI来确定向客户端显示哪个证书链。但是，具有一个标识和一个匹配证书的服务器不需要SNI支持。服务器不得强制客户端使用SNI，因为客户端可能正在使用未经验证的机会主义TL，并且可能不希望服务器提供任何特定证书。如果客户端不发送SNI扩展或发送不支持的服务器名称的SNI扩展，则服务器必须只发送其选择的回退证书链。不强制严格匹配请求的SNI主机名的原因是MTA-STS TLS客户端通常愿意接受多个服务器名称，但只能在SNI扩展中发送一个名称。服务器的回退证书可能与客户端可接受的不同名称相匹配，例如，原始下一跳域。
MTAs supporting MTA-STS MUST have support for TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] or higher. The general TLS usage guidance in [RFC7525] SHOULD be followed.
支持MTA-STS的MTA必须支持TLS 1.2[RFC5246]或TLS 1.3[RFC8446]或更高版本。应遵循[RFC7525]中的一般TLS使用指南。
Updating the policy requires that the owner make changes in two places: the "_mta-sts" TXT record in the Policy Domain's DNS zone and at the corresponding HTTPS endpoint. As a result, recipients should expect that a policy will continue to be used by senders until both the HTTPS and TXT endpoints are updated and the TXT record's TTL has passed.
更新策略需要所有者在两个位置进行更改：策略域的DNS区域中的“\u mta-sts”TXT记录和相应的HTTPS端点。因此，收件人应该期望发件人将继续使用策略，直到更新HTTPS和TXT端点并且TXT记录的TTL已通过。
In other words, a sender who is unable to successfully deliver a message while applying a cache of the recipient's now-outdated policy may be unable to discover that a new policy exists until the DNS TTL has passed. Recipients SHOULD therefore ensure that old policies continue to work for message delivery during this period of time, or risk message delays.
换句话说，在应用收件人现已过时策略的缓存时无法成功传递消息的发件人，在DNS TTL通过之前，可能无法发现新策略存在。因此，收件人应确保旧策略在这段时间内继续用于邮件传递，否则可能会导致邮件延迟。
Recipients SHOULD also update the HTTPS policy body before updating the TXT record; this ordering avoids the risk that senders, seeing a new TXT record, mistakenly cache the old policy from HTTPS.
收件人还应在更新TXT记录之前更新HTTPS策略主体；这种排序避免了发件人看到新的TXT记录时错误地从HTTPS缓存旧策略的风险。
Domain owners commonly delegate SMTP hosting to a different organization, such as an ISP or a web host. In such a case, they may wish to also delegate the MTA-STS Policy to the same organization, which can be accomplished with two changes.
域所有者通常将SMTP托管委托给不同的组织，如ISP或web主机。在这种情况下，他们可能还希望将MTA-STS策略委托给同一组织，这可以通过两个更改来完成。
First, the Policy Domain must point the "_mta-sts" record, via CNAME, to the "_mta-sts" record maintained by the provider. This allows the provider to control update signaling.
首先，策略域必须通过CNAME将“\u mta-sts”记录指向提供程序维护的“\u mta-sts”记录。这允许提供者控制更新信令。
Second, the Policy Domain must point the "well-known" policy location to the provider. This can be done either by setting the "mta-sts" record to an IP address or CNAME specified by the provider and by giving the provider a TLS certificate that is valid for that host or by setting up a "reverse proxy" (also known as a "gateway") server for the Policy Domain's Policy Host, configured to serve proxied responses from the Policy Host of the provider.
其次，策略域必须将“已知”策略位置指向提供者。这可以通过将“mta sts”记录设置为提供程序指定的IP地址或CNAME，并向提供程序提供对该主机有效的TLS证书，或为策略域的策略主机设置“反向代理”（也称为“网关”）服务器来实现，配置为提供来自提供程序的策略主机的代理响应。
For example, given a user domain "user.example" hosted by a mail provider "provider.example", the following configuration would allow policy delegation:
例如，给定由邮件提供商“provider.example”托管的用户域“user.example”，以下配置将允许策略委派：
DNS:
域名系统：
_mta-sts.user.example. IN CNAME _mta-sts.provider.example.
_mta-sts.user.example。在CNAME\u mta-sts.provider.example中。
Policy:
政策：
> GET /.well-known/mta-sts.txt Host: mta-sts.user.example
< HTTP/1.1 200 OK # Response proxies content from
# https://mta-sts.provider.example
> GET /.well-known/mta-sts.txt Host: mta-sts.user.example
< HTTP/1.1 200 OK # Response proxies content from
# https://mta-sts.provider.example
Note that in all such cases, the policy endpoint ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this example) must still present a certificate valid for the Policy Host ("mta-sts.user.example"), and not for that host at the provider's domain ("mta-sts.provider.example").
请注意，在所有此类情况下，策略终结点（“https://mta-sts.user.example/.well-known/mta-sts.txt在此示例中，必须仍然提供对策略主机有效的证书（“mta sts.user.example”），而不是对提供程序域中的该主机有效的证书（“mta sts.provider.example”）。
Note that while Sending MTAs MUST NOT use HTTP caching when fetching policies via HTTPS, such caching may nonetheless be useful to a reverse proxy configured as described in this section. An HTTPS policy endpoint expecting to be proxied for multiple hosted domains -- as with a large mail hosting provider or similar -- may wish to indicate an HTTP Cache-Control "max-age" response directive (as specified in [RFC7234]) of 60 seconds as a reasonable value to save reverse proxies an unnecessarily high-rate of proxied policy fetching.
请注意，虽然通过HTTPS获取策略时发送MTA不得使用HTTP缓存，但此类缓存对于按照本节所述配置的反向代理可能仍然有用。希望为多个托管域代理的HTTPS策略终结点（与大型邮件托管提供商或类似提供商一样）可能希望将60秒的HTTP缓存控制“max age”响应指令（如[RFC7234]中所指定）指示为合理值，以将反向代理保存为不必要的高代理策略获取率。
In order to facilitate clean opt-out of MTA-STS by implementing Policy Domains, and to distinguish clearly between failures that indicate attacks and those that indicate such opt-outs, MTA-STS implements the "none" mode, which allows validated policies to indicate authoritatively that the Policy Domain wishes to no longer implement MTA-STS and may, in the future, remove the MTA-STS TXT and policy endpoints entirely.
为了通过实施策略域促进MTA-STS的明确选择退出，并明确区分指示攻击的失败和指示此类选择退出的失败，MTA-STS实施“无”模式，该模式允许经验证的策略权威性地指示策略域希望不再实施MTA-STS，并且可能，将来，请完全删除MTA-STS TXT和策略终结点。
A suggested workflow to implement such an opt out is as follows:
实施此类选择退出的建议工作流程如下：
1. Publish a new policy with "mode" equal to "none" and a small "max_age" (e.g., one day).
1. 发布“模式”等于“无”且“最长期限”较小（例如，一天）的新策略。
2. Publish a new TXT record to trigger fetching of the new policy.
2. 发布新的TXT记录以触发新策略的获取。
3. When all previously served policies have expired -- normally this is the time the previously published policy was last served plus that policy's "max_age", but note that policies older than the previously published policy may have been served with a greater "max_age" than the previously published policy, allowing overlapping policy caches -- safely remove the TXT record and HTTPS endpoint.
3. 当所有以前发布的策略都已过期时——通常这是以前发布的策略最后一次被送达的时间加上该策略的“最长期限”，但请注意，比以前发布的策略早的策略可能比以前发布的策略送达的“最长期限”更大，允许重叠策略缓存——安全地删除TXT记录和HTTPS端点。
Implementers of send-time MTA-STS validation in mail transfer agents should take note of the risks of modifying the logic of traversing MX candidate lists. Because an MTA-STS Policy can be used to prefilter invalid MX candidates from the MX candidate list, it is tempting to implement a "two-pass" model, where MX candidates are first filtered for possible validity according to the MTA-STS Policy, and then the remaining candidates are attempted in order as without an MTA-STS Policy. This may lead to incorrect implementations, such as message loops; instead, it is recommended that implementers traverse the MX candidate list as usual, and treat invalid candidates as though they were unreachable (i.e., as though there were some transient error when trying to deliver to that candidate).
邮件传输代理中发送时间MTA-STS验证的实现者应注意修改遍历MX候选列表逻辑的风险。由于MTA-STS策略可用于从MX候选列表中预筛选无效的MX候选，因此很容易实现“两次通过”模型，其中首先根据MTA-STS策略筛选MX候选，以确定其可能的有效性，然后按照没有MTA-STS策略的顺序尝试剩余候选。这可能导致不正确的实现，例如消息循环；相反，建议实现人员像往常一样遍历MX候选列表，并将无效候选视为无法访问（即，在尝试交付给该候选时，似乎存在一些暂时性错误）。
One consequence of validating MX hosts in order of ordinary candidate traversal is that in the event a higher-priority MX is MTA-STS valid and a lower-priority MX is not, senders may never encounter the lower-priority MX, leading to a risk that policy misconfigurations that apply only to "backup" MXes may only be discovered in the case of primary MX failure.
按照普通候选遍历顺序验证MX主机的一个结果是，如果较高优先级的MX是MTA-STS有效的，而较低优先级的MX是无效的，发送方可能永远不会遇到较低优先级的MX，从而导致仅适用于“备份”的策略配置错误的风险只有在主MX故障的情况下才能发现MXE。
A new "well-known" URI as described in Section 3 has been registered in the "Well-Known URIs" registry as described below:
第3节所述的新“已知”URI已在“已知URI”注册表中注册，如下所述：
URI Suffix: mta-sts.txt
URI后缀：mta-sts.txt
Change Controller: IETF
更改控制器：IETF
IANA has created a new registry titled "MTA-STS TXT Record Fields". The initial entries in the registry are:
IANA创建了一个名为“MTA-STS TXT记录字段”的新注册表。注册表中的初始条目为：
+------------+--------------------+-------------------------+
| Field Name | Description | Reference |
+------------+--------------------+-------------------------+
| v | Record version | Section 3.1 of RFC 8461 |
| id | Policy instance ID | Section 3.1 of RFC 8461 |
+------------+--------------------+-------------------------+
+------------+--------------------+-------------------------+
| Field Name | Description | Reference |
+------------+--------------------+-------------------------+
| v | Record version | Section 3.1 of RFC 8461 |
| id | Policy instance ID | Section 3.1 of RFC 8461 |
+------------+--------------------+-------------------------+
New fields are added to this registry using IANA's "Expert Review" policy [RFC8126].
使用IANA的“专家评审”策略[RFC8126]将新字段添加到此注册表。
IANA has created a new registry titled "MTA-STS Policy Fields". The initial entries in the registry are:
IANA创建了一个名为“MTA-STS策略字段”的新注册表。注册表中的初始条目为：
+------------+----------------------+-------------------------+
| Field Name | Description | Reference |
+------------+----------------------+-------------------------+
| version | Policy version | Section 3.2 of RFC 8461 |
| mode | Enforcement behavior | Section 3.2 of RFC 8461 |
| max_age | Policy lifetime | Section 3.2 of RFC 8461 |
| mx | MX identities | Section 3.2 of RFC 8461 |
+------------+----------------------+-------------------------+
+------------+----------------------+-------------------------+
| Field Name | Description | Reference |
+------------+----------------------+-------------------------+
| version | Policy version | Section 3.2 of RFC 8461 |
| mode | Enforcement behavior | Section 3.2 of RFC 8461 |
| max_age | Policy lifetime | Section 3.2 of RFC 8461 |
| mx | MX identities | Section 3.2 of RFC 8461 |
+------------+----------------------+-------------------------+
New fields are added to this registry using IANA's "Expert Review" policy.
使用IANA的“专家评审”策略将新字段添加到此注册表。
SMTP MTA-STS attempts to protect against an active attacker trying to intercept or tamper with mail between hosts that support STARTTLS. There are two classes of attacks considered:
SMTP MTA-STS试图防止活动攻击者试图拦截或篡改支持STARTTLS的主机之间的邮件。考虑了两类攻击：
o Foiling TLS negotiation (for example, by deleting the "250 STARTTLS" response from a server or altering TLS session negotiation). This would result in the SMTP session occurring over plaintext, despite both parties supporting TLS.
o 阻止TLS协商（例如，从服务器删除“250 STARTTLS”响应或更改TLS会话协商）。这将导致SMTP会话在明文上发生，尽管双方都支持TLS。
o Impersonating the destination mail server, whereby the sender might deliver the message to an impostor, who could then monitor and/or modify messages despite opportunistic TLS. This impersonation could be accomplished by spoofing the DNS MX record for the recipient domain or by redirecting client connections intended for the legitimate recipient server (for example, by altering BGP routing tables).
o 模拟目标邮件服务器，通过该服务器，发件人可以将邮件传递给冒名顶替者，冒名顶替者可以监视和/或修改邮件，尽管存在机会TLS。此模拟可以通过欺骗收件人域的DNS MX记录或重定向用于合法收件人服务器的客户端连接（例如，通过更改BGP路由表）来完成。
MTA-STS can thwart such attacks only if the sender is able to previously obtain and cache a policy for the recipient domain, and only if the attacker is unable to obtain a valid certificate that complies with that policy. Below, we consider specific attacks on this model.
MTA-STS只有在发送方之前能够获取并缓存收件人域的策略，并且只有在攻击者无法获取符合该策略的有效证书时，才能阻止此类攻击。下面，我们考虑对这个模型的特定攻击。
SMTP MTA-STS relies on certificate validation via PKIX-based TLS identity checking [RFC6125]. Attackers who are able to obtain a valid certificate for the targeted recipient mail service (e.g., by compromising a CA) are thus able to circumvent STS authentication.
SMTP MTA-STS依赖于通过基于PKIX的TLS身份检查进行的证书验证[RFC6125]。因此，能够获得目标收件人邮件服务的有效证书（例如，通过泄露CA）的攻击者能够绕过STS身份验证。
Since MTA-STS uses DNS TXT records for policy discovery, an attacker who is able to block DNS responses can suppress the discovery of an MTA-STS Policy, making the Policy Domain appear not to have an MTA-STS Policy. The sender policy cache is designed to resist this attack by decreasing the frequency of policy discovery and thus reducing the window of vulnerability; it is nonetheless a risk that attackers who can predict or induce policy discovery -- for example, by inducing a sending domain to send mail to a never-before-contacted recipient while carrying out a man-in-the-middle attack -- may be able to foil policy discovery and effectively downgrade the security of the message delivery.
由于MTA-STS使用DNS TXT记录进行策略发现，因此能够阻止DNS响应的攻击者可以阻止MTA-STS策略的发现，从而使策略域看起来没有MTA-STS策略。发送方策略缓存通过降低策略发现的频率从而减少漏洞窗口来抵御这种攻击；尽管如此，能够预测或诱导策略发现的攻击者（例如，在执行中间人攻击时诱导发送域向从未联系过的收件人发送邮件）可能会挫败策略发现并有效降低消息传递的安全性，这是一种风险。
Since this attack depends upon intercepting initial policy discovery, implementers SHOULD prefer policy "max_age" values to be as long as is practical.
由于此攻击依赖于拦截初始策略发现，所以实现者应该希望策略“max_age”值尽可能长。
Because this attack is also possible upon refresh of a cached policy, implementers SHOULD NOT wait until a cached policy has expired before checking for an update; if senders attempt to refresh the cache regularly (for example, by fetching the current live policy in a background task that runs daily or weekly, regardless of the state of the "_mta-sts" TXT record, and updating their cache's "max age" accordingly), an attacker would have to foil policy discovery consistently over the lifetime of a cached policy to prevent a successful refresh.
因为在刷新缓存策略时也可能发生此攻击，所以实现者不应该等到缓存策略过期后再检查更新；如果发件人尝试定期刷新缓存（例如，通过在每天或每周运行的后台任务中获取当前live策略，而不管“_mta-sts”TXT记录的状态如何，并相应地更新其缓存的“最大使用期限”），攻击者必须在缓存策略的生命周期内一致地阻止策略发现，以防止成功刷新。
Additionally, MTAs SHOULD alert administrators to repeated policy refresh failures long before cached policies expire (through warning logs or similar applicable mechanisms), allowing administrators to detect such a persistent attack on policy refresh. (However, they should not implement such alerts if the cached policy has a "none" mode, to allow clean MTA-STS removal, as described in Section 8.3.)
此外，MTA应在缓存的策略过期很久之前（通过警告日志或类似的适用机制）向管理员发出重复策略刷新失败的警报，使管理员能够检测到对策略刷新的此类持续攻击。（但是，如果缓存策略具有“无”模式以允许清除MTA-STS，则不应实施此类警报，如第8.3节所述。）
Resistance to downgrade attacks of this nature -- due to the ability to authoritatively determine "lack of a record" even for non-participating recipients -- is a feature of DANE, due to its use of DNSSEC for policy discovery.
由于DANE使用DNSSEC进行策略发现，因此它的一个特点是，即使对于未参与的收件人，也能够权威性地确定“缺少记录”，因此能够抵抗这种性质的降级攻击。
We additionally consider the Denial-of-Service risk posed by an attacker who can modify the DNS records for a recipient domain. Absent MTA-STS, such an attacker can cause a Sending MTA to cache invalid MX records, but only for however long the sending resolver caches those records. With MTA-STS, the attacker can additionally advertise a new, long "max_age" MTA-STS Policy with "mx" constraints
我们还考虑攻击者的拒绝服务风险，该攻击者可以修改接收方域的DNS记录。在缺少MTA-STS的情况下，此类攻击者可导致发送MTA缓存无效的MX记录，但仅限于发送解析程序缓存这些记录的时间。有了MTA-STS，攻击者还可以通过“mx”约束宣传新的长“最大年龄”MTA-STS策略
that validate the malicious MX record, causing senders to cache the policy and refuse to deliver messages once the victim has resecured the MX records.
验证恶意MX记录，导致发件人缓存策略，并在受害者重新修复MX记录后拒绝传递消息。
This attack is mitigated in part by the ability of a victim domain to (at any time) publish a new policy updating the cached, malicious policy, though this does require the victim domain to both obtain a valid CA-signed certificate and to understand and properly configure MTA-STS.
受害者域能够（在任何时候）发布更新缓存恶意策略的新策略，这在一定程度上缓解了此攻击，尽管这确实需要受害者域获得有效的CA签名证书，并理解和正确配置MTA-STS。
Similarly, we consider the possibility of domains that deliberately allow untrusted users to serve untrusted content on user-specified subdomains. In some cases (e.g., the service "tumblr.com"), this takes the form of providing HTTPS hosting of user-registered subdomains; in other cases (e.g. dynamic DNS providers), this takes the form of allowing untrusted users to register custom DNS records at the provider's domain.
类似地，我们考虑允许用户不指定的用户在用户指定的子域上服务不可信内容的域的可能性。在某些情况下（例如，服务“tumblr.com”），其形式是提供用户注册子域的HTTPS托管；在其他情况下（例如，动态DNS提供商），其形式是允许不受信任的用户在提供商的域中注册自定义DNS记录。
In these cases, there is a risk that untrusted users would be able to serve custom content at the "mta-sts" host, including serving an illegitimate MTA-STS Policy. We believe this attack is rendered more difficult by the need for the attacker to also serve the "_mta-sts" TXT record on the same domain -- something not, to our knowledge, widely provided to untrusted users. This attack is additionally mitigated by the aforementioned ability for a victim domain to update an invalid policy at any future date.
在这些情况下，不受信任的用户有可能在“mta sts”主机上提供自定义内容，包括提供非法的mta-sts策略。我们认为，由于攻击者还需要在同一域上提供“\u mta-sts”TXT记录，因此这种攻击变得更加困难——据我们所知，这并不是广泛提供给不受信任的用户的。受害者域在未来任何日期更新无效策略的上述能力还可以进一步缓解此攻击。
Even if an attacker cannot modify a served policy, the potential exists for configurations that allow attackers on the same domain to receive mail for that domain. For example, an easy configuration option when authoring an MTA-STS Policy for "example.com" is to set the "mx" equal to "*.example.com"; in this case, recipient domains must consider the risk that any user possessing a valid hostname and CA-signed certificate (for example, "dhcp-123.example.com") will, from the perspective of MTA-STS Policy validation, be a valid MX host for that domain.
即使攻击者无法修改已服务的策略，也可能存在允许同一域上的攻击者接收该域邮件的配置。例如，在为“example.com”编写MTA-STS策略时，一个简单的配置选项是将“mx”设置为“*.example.com”；在这种情况下，收件人域必须考虑任何拥有有效主机名和CA签名证书的用户（例如，“DHCP 123..Simult.com”）的风险，从MTA-SSTS策略验证的角度来看，将是该域的有效MX主机。
A number of risks apply to the PKI system that is used for certificate authentication, both of the "mta-sts" HTTPS host's certificate and the SMTP servers' certificates. These risks are broadly applicable within the Web PKI ecosystem and are not specific to MTA-STS; nonetheless, they deserve some consideration in this context.
用于证书身份验证的PKI系统存在许多风险，“mta sts”HTTPS主机证书和SMTP服务器证书。这些风险广泛适用于Web PKI生态系统，并非MTA-STS特有的风险；然而，在这方面，它们值得一些考虑。
Broadly speaking, attackers may compromise the system by obtaining certificates under fraudulent circumstances (i.e., by impersonating the legitimate owner of the victim domain), by compromising a CA or Delegate Authority's private keys, by obtaining a legitimate certificate issued to the victim domain, and similar.
从广义上讲，攻击者可能会通过以下方式危害系统：在欺诈情况下获取证书（即，通过冒充受害者域的合法所有者），通过危害CA或授权机构的私钥，通过获取颁发给受害者域的合法证书，以及类似的方式。
One approach commonly employed by web browsers to help mitigate against some of these attacks is to allow for revocation of compromised or fraudulent certificates via OCSP [RFC6960] or CRLs [RFC6818]. Such mechanisms themselves represent trade-offs and are not universally implemented; we nonetheless recommend implementers of MTA-STS to implement revocation mechanisms that are most applicable to their implementations.
web浏览器常用的一种方法是允许通过OCSP[RFC6960]或CRLs[RFC6818]撤销受损或欺诈的证书，以帮助抵御其中一些攻击。这种机制本身是一种权衡，并没有得到普遍实施；尽管如此，我们还是建议MTA-STS的实现者实现最适用于其实现的撤销机制。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<https://www.rfc-editor.org/info/rfc2818>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，DOI 10.17487/RFC3207，2002年2月<https://www.rfc-editor.org/info/rfc3207>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，DOI 10.17487/RFC3492，2003年3月<https://www.rfc-editor.org/info/rfc3492>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<https://www.rfc-editor.org/info/rfc5321>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<https://www.rfc-editor.org/info/rfc5785>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<https://www.rfc-editor.org/info/rfc6125>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405]Kyzivat，P.，“ABNF中的区分大小写字符串支持”，RFC 7405，DOI 10.17487/RFC7405，2014年12月<https://www.rfc-editor.org/info/rfc7405>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
[RFC8460] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., and M. Risher, "SMTP TLS Reporting", RFC 8460, DOI 10.17487/RFC8460, September 2018, <https://www.rfc-editor.org/info/rfc8460>.
[RFC8460]Margolis，D.，Brotman，A.，Ramakrishnan，B.，Jones，J.，和M.Risher，“SMTP TLS报告”，RFC 8460，DOI 10.17487/RFC8460，2018年9月<https://www.rfc-editor.org/info/rfc8460>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<https://www.rfc-editor.org/info/rfc4033>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<https://www.rfc-editor.org/info/rfc5891>.
[RFC6818] Yee, P., "Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January 2013, <https://www.rfc-editor.org/info/rfc6818>.
[RFC6818]Yee，P.，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的更新”，RFC 6818，DOI 10.17487/RFC6818，2013年1月<https://www.rfc-editor.org/info/rfc6818>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<https://www.rfc-editor.org/info/rfc6960>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<https://www.rfc-editor.org/info/rfc7234>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-editor.org/info/rfc7672>.
[RFC7672]Dukhovni，V.和W.Hardaker，“通过基于机会DNS的命名实体身份验证（DANE）传输层安全性（TLS）实现SMTP安全”，RFC 7672，DOI 10.17487/RFC7672，2015年10月<https://www.rfc-editor.org/info/rfc7672>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
The owner of "example.com" wishes to begin using MTA-STS with a policy that will solicit reports from senders without affecting how the messages are processed, in order to verify the identity of MXes that handle mail for "example.com", confirm that TLS is correctly used, and ensure that certificates presented by the recipient MX validate.
“example.com”的所有者希望开始使用MTA-STS，其策略将在不影响邮件处理方式的情况下向发件人征求报告，以便验证处理“example.com”邮件的MXE的身份，确认TLS使用正确，并确保收件人MX提供的证书有效。
MTA-STS Policy indicator TXT RR:
MTA-STS策略指示器TXT RR:
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"
MTA-STS Policy file served as the response body at "https://mta-sts.example.com/.well-known/mta-sts.txt":
MTA-STS策略文件用作“的响应主体”https://mta-sts.example.com/.well-known/mta-sts.txt":
version: STSv1 mode: testing mx: mx1.example.com mx: mx2.example.com mx: mx.backup-example.com max_age: 1296000
版本：STSv1模式：测试mx:mx1.example.com mx:mx2.example.com mx:mx.backup-example.com最大年龄：1296000
Below is pseudocode demonstrating the logic of a compliant Sending MTA.
下面是演示兼容发送MTA逻辑的伪代码。
While this pseudocode implementation suggests synchronous policy retrieval in the delivery path, that may be undesirable in a working implementation, and we expect some implementers to instead prefer a background fetch that does not block delivery when no cached policy is present.
虽然此伪代码实现建议在传递路径中进行同步策略检索，但这在工作实现中可能是不可取的，并且我们希望一些实现者更喜欢在没有缓存策略时不阻止传递的后台获取。
func isEnforce(policy) {
// Return true if the policy mode is "enforce".
}
func isEnforce(policy) {
// Return true if the policy mode is "enforce".
}
func isNonExpired(policy) {
// Return true if the policy is not expired.
}
func isNonExpired(policy) {
// Return true if the policy is not expired.
}
func tryStartTls(connection) {
// Attempt to open an SMTP STARTTLS connection with the MX.
}
func tryStartTls(connection) {
// Attempt to open an SMTP STARTTLS connection with the MX.
}
func certMatches(connection, host) {
func证书匹配（连接、主机）{
// Assume a handy function to return if the server
// certificate presented in "connection" is valid for "host".
}
// Assume a handy function to return if the server
// certificate presented in "connection" is valid for "host".
}
func policyMatches(candidate, policy) {
for mx in policy.mx {
// Literal match.
if mx == candidate {
return true
}
// Wildcard matches only the leftmost label.
// Wildcards must always be followed by a '.'.
if mx[0] == '*' {
parts = SplitN(candidate, '.', 2) // Split on the first '.'.
if len(parts) > 1 && parts[1] == mx[2:] {
return true
}
}
}
return false
}
func policyMatches(candidate, policy) {
for mx in policy.mx {
// Literal match.
if mx == candidate {
return true
}
// Wildcard matches only the leftmost label.
// Wildcards must always be followed by a '.'.
if mx[0] == '*' {
parts = SplitN(candidate, '.', 2) // Split on the first '.'.
if len(parts) > 1 && parts[1] == mx[2:] {
return true
}
}
}
return false
}
func tryDeliverMail(connection, message) {
// Attempt to deliver "message" via "connection".
}
func tryDeliverMail(connection, message) {
// Attempt to deliver "message" via "connection".
}
func tryGetNewPolicy(domain) {
// Check for an MTA-STS TXT record for "domain" in DNS, and return
// the indicated policy.
}
func tryGetNewPolicy(domain) {
// Check for an MTA-STS TXT record for "domain" in DNS, and return
// the indicated policy.
}
func cachePolicy(domain, policy) {
// Store "policy" as the cached policy for "domain".
}
func cachePolicy(domain, policy) {
// Store "policy" as the cached policy for "domain".
}
func tryGetCachedPolicy(domain) {
// Return a cached policy for "domain".
}
func tryGetCachedPolicy(domain) {
// Return a cached policy for "domain".
}
func reportError(error) {
// Report an error via TLSRPT.
}
func reportError(error) {
// Report an error via TLSRPT.
}
func tryMxAccordingTo(message, mx, policy) {
connection := connect(mx)
if !connection {
return false // Can't connect to the MX, so it's not an MTA-STS
// error.
func tryMxAccordingTo(message, mx, policy) {
connection := connect(mx)
if !connection {
return false // Can't connect to the MX, so it's not an MTA-STS
// error.
}
secure := true
if !policyMatches(mx, policy) {
secure = false
reportError(E_HOST_MISMATCH)
} else if !tryStartTls(connection) {
secure = false
reportError(E_NO_VALID_TLS)
} else if !certMatches(connection, policy) {
secure = false
reportError(E_CERT_MISMATCH)
}
if secure || !isEnforce(policy) {
return tryDeliverMail(connection, message)
}
return false
}
}
secure := true
if !policyMatches(mx, policy) {
secure = false
reportError(E_HOST_MISMATCH)
} else if !tryStartTls(connection) {
secure = false
reportError(E_NO_VALID_TLS)
} else if !certMatches(connection, policy) {
secure = false
reportError(E_CERT_MISMATCH)
}
if secure || !isEnforce(policy) {
return tryDeliverMail(connection, message)
}
return false
}
func tryWithPolicy(message, domain, policy) {
mxes := getMxForDomain(domain)
for mx in mxes {
if tryMxAccordingTo(message, mx, policy) {
return true
}
}
return false
}
func tryWithPolicy(message, domain, policy) {
mxes := getMxForDomain(domain)
for mx in mxes {
if tryMxAccordingTo(message, mx, policy) {
return true
}
}
return false
}
func handleMessage(message) {
domain := ... // domain part after '@' from recipient
policy := tryGetNewPolicy(domain)
if policy {
cachePolicy(domain, policy)
} else {
policy = tryGetCachedPolicy(domain)
}
if policy {
return tryWithPolicy(message, domain, policy)
}
// Try to deliver the message normally (i.e., without MTA-STS).
}
func handleMessage(message) {
domain := ... // domain part after '@' from recipient
policy := tryGetNewPolicy(domain)
if policy {
cachePolicy(domain, policy)
} else {
policy = tryGetCachedPolicy(domain)
}
if policy {
return tryWithPolicy(message, domain, policy)
}
// Try to deliver the message normally (i.e., without MTA-STS).
}
Contributors
贡献者
Wei Chuang Google, Inc. weihaw@google.com
伟创谷歌有限公司。weihaw@google.com
Viktor Dukhovni ietf-dane@dukhovni.de
维克多·杜霍夫尼ietf-dane@dukhovni.de
Markus Laber 1&1 Mail & Media Development & Technology GmbH markus.laber@1und1.de
Markus Laber 1&1 Mail&Media Development&Technology GmbH Markus。laber@1und1.de
Nicolas Lidzborski Google, Inc. nlidz@google.com
尼古拉斯·利兹博斯基谷歌公司。nlidz@google.com
Brandon Long Google, Inc. blong@google.com
布兰登·朗谷歌公司。blong@google.com
Franck Martin LinkedIn, Inc. fmartin@linkedin.com
弗兰克·马丁·LinkedIn公司。fmartin@linkedin.com
Klaus Umbach 1&1 Mail & Media Development & Technology GmbH klaus.umbach@1und1.de
Klaus Umbach 1&1邮件与媒体开发与技术有限公司Klaus。umbach@1und1.de
Authors' Addresses
作者地址
Daniel Margolis Google, Inc.
丹尼尔·马戈利斯谷歌公司。
Email: dmargolis@google.com
Email: dmargolis@google.com
Mark Risher Google, Inc.
马克·瑞舍谷歌公司。
Email: risher@google.com
Email: risher@google.com
Binu Ramakrishnan Oath, Inc.
比努罗摩克里希南誓言公司。
Email: prbinu@yahoo.com
Email: prbinu@yahoo.com
Alexander Brotman Comcast, Inc.
亚历山大·布罗特曼康卡斯特公司。
Email: alex_brotman@comcast.com
Email: alex_brotman@comcast.com
Janet Jones Microsoft, Inc.
珍妮特·琼斯微软公司。
Email: janet.jones@microsoft.com
Email: janet.jones@microsoft.com