Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7672 Two Sigma
Category: Standards Track W. Hardaker
ISSN: 2070-1721 Parsons
October 2015
Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7672 Two Sigma
Category: Standards Track W. Hardaker
ISSN: 2070-1721 Parsons
October 2015
SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
通过基于机会DNS的命名实体身份验证（DANE）传输层安全（TLS）实现SMTP安全
Abstract
摘要
This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).
此备忘录描述了一种用于邮件传输代理（MTA）之间SMTP传输安全的抗降级协议，该协议基于基于命名实体的DNS身份验证（DANE）TLSA DNS记录。采用此协议可以将Internet电子邮件主干网增量转换为使用加密和认证传输层安全性（TLS）的主干网。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7672.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7672.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Background .................................................6
1.3. SMTP Channel Security ......................................6
1.3.1. STARTTLS Downgrade Attack ...........................7
1.3.2. Insecure Server Name without DNSSEC .................7
1.3.3. Sender Policy Does Not Scale ........................8
1.3.4. Too Many Certification Authorities ..................9
2. Identifying Applicable TLSA Records .............................9
2.1. DNS Considerations .........................................9
2.1.1. DNS Errors, "Bogus" Responses, and
"Indeterminate" Responses ...........................9
2.1.2. DNS Error Handling .................................11
2.1.3. Stub Resolver Considerations .......................12
2.2. TLS Discovery .............................................13
2.2.1. MX Resolution ......................................14
2.2.2. Non-MX Destinations ................................16
2.2.3. TLSA Record Lookup .................................18
3. DANE Authentication ............................................20
3.1. TLSA Certificate Usages ...................................20
3.1.1. Certificate Usage DANE-EE(3) .......................21
3.1.2. Certificate Usage DANE-TA(2) .......................22
3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23
3.2. Certificate Matching ......................................24
3.2.1. DANE-EE(3) Name Checks .............................24
3.2.2. DANE-TA(2) Name Checks .............................24
3.2.3. Reference Identifier Matching ......................25
4. Server Key Management ..........................................26
5. Digest Algorithm Agility .......................................27
6. Mandatory TLS Security .........................................27
7. Note on DANE for Message User Agents ...........................28
8. Interoperability Considerations ................................28
8.1. SNI Support ...............................................28
8.2. Anonymous TLS Cipher Suites ...............................29
9. Operational Considerations .....................................29
9.1. Client Operational Considerations .........................29
9.2. Publisher Operational Considerations ......................30
10. Security Considerations .......................................30
11. References ....................................................31
11.1. Normative References .....................................31
11.2. Informative References ...................................33
Acknowledgements ..................................................34
Authors' Addresses ................................................34
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Background .................................................6
1.3. SMTP Channel Security ......................................6
1.3.1. STARTTLS Downgrade Attack ...........................7
1.3.2. Insecure Server Name without DNSSEC .................7
1.3.3. Sender Policy Does Not Scale ........................8
1.3.4. Too Many Certification Authorities ..................9
2. Identifying Applicable TLSA Records .............................9
2.1. DNS Considerations .........................................9
2.1.1. DNS Errors, "Bogus" Responses, and
"Indeterminate" Responses ...........................9
2.1.2. DNS Error Handling .................................11
2.1.3. Stub Resolver Considerations .......................12
2.2. TLS Discovery .............................................13
2.2.1. MX Resolution ......................................14
2.2.2. Non-MX Destinations ................................16
2.2.3. TLSA Record Lookup .................................18
3. DANE Authentication ............................................20
3.1. TLSA Certificate Usages ...................................20
3.1.1. Certificate Usage DANE-EE(3) .......................21
3.1.2. Certificate Usage DANE-TA(2) .......................22
3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23
3.2. Certificate Matching ......................................24
3.2.1. DANE-EE(3) Name Checks .............................24
3.2.2. DANE-TA(2) Name Checks .............................24
3.2.3. Reference Identifier Matching ......................25
4. Server Key Management ..........................................26
5. Digest Algorithm Agility .......................................27
6. Mandatory TLS Security .........................................27
7. Note on DANE for Message User Agents ...........................28
8. Interoperability Considerations ................................28
8.1. SNI Support ...............................................28
8.2. Anonymous TLS Cipher Suites ...............................29
9. Operational Considerations .....................................29
9.1. Client Operational Considerations .........................29
9.2. Publisher Operational Considerations ......................30
10. Security Considerations .......................................30
11. References ....................................................31
11.1. Normative References .....................................31
11.2. Informative References ...................................33
Acknowledgements ..................................................34
Authors' Addresses ................................................34
This memo specifies a new connection security model for Message Transfer Agents (MTAs). This model is motivated by key features of inter-domain SMTP delivery, principally, the fact that the destination server is selected indirectly via DNS Mail Exchange (MX) records and that neither email addresses nor MX hostnames signal a requirement for either secure or cleartext transport. Therefore, aside from a few manually configured exceptions, SMTP transport security is, by necessity, opportunistic (for a definition of "Opportunistic Security", see [RFC7435]).
此备忘录为邮件传输代理（MTA）指定了新的连接安全模型。此模型的动机是域间SMTP传递的关键功能，主要是通过DNS邮件交换（MX）记录间接选择目标服务器，并且电子邮件地址和MX主机名都不表示需要安全或明文传输。因此，除了一些手动配置的例外情况外，SMTP传输安全性必然是机会主义的（有关“机会主义安全性”的定义，请参阅[RFC7435]）。
This specification uses the presence of DANE TLSA records to securely signal TLS support and to publish the means by which SMTP clients can successfully authenticate legitimate SMTP servers. This becomes "opportunistic DANE TLS" and is resistant to downgrade and man-in-the-middle (MITM) attacks. It enables an incremental transition of the email backbone to authenticated TLS delivery, with increased global protection as adoption increases.
本规范使用DANE TLSA记录的存在来安全地表示TLS支持，并发布SMTP客户端可以成功验证合法SMTP服务器的方法。这将成为“机会主义丹麦TLS”，并抵抗降级和中间人（MITM）攻击。它支持电子邮件主干向经过身份验证的TLS传递的增量过渡，随着采用率的增加，全局保护也会增加。
With opportunistic DANE TLS, traffic from SMTP clients to domains that publish "usable" DANE TLSA records in accordance with this memo is authenticated and encrypted. Traffic from legacy clients or to domains that do not publish TLSA records will continue to be sent in the same manner as before, via manually configured security, (pre-DANE) opportunistic TLS, or just cleartext SMTP.
对于机会主义的DANE TLS，从SMTP客户端到根据本备忘录发布“可用”DANE TLSA记录的域的通信是经过身份验证和加密的。从旧客户端或到未发布TLSA记录的域的流量将继续以与以前相同的方式发送，通过手动配置的安全性、（丹麦之前）机会主义TLS，或仅通过明文SMTP。
Problems with the existing use of TLS in MTA-to-MTA SMTP that motivate this specification are described in Section 1.3. The specification itself follows, in Sections 2 and 3, which describe, respectively, how to locate and use DANE TLSA records with SMTP. In Section 6, we discuss the application of DANE TLS to destinations for which channel integrity and confidentiality are mandatory. In Section 7, we briefly comment on the potential applicability of this specification to Message User Agents.
第1.3节描述了MTA到MTA SMTP中TLS的现有使用问题，这些问题激发了本规范。规范本身在第2节和第3节中分别描述了如何在SMTP中定位和使用DANE TLSA记录。在第6节中，我们将讨论DANE TLS在强制要求信道完整性和保密性的目的地的应用。在第7节中，我们简要评论了该规范对消息用户代理的潜在适用性。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The following terms or concepts are used throughout this document:
本文件中使用了以下术语或概念：
Man-in-the-middle (MITM) attack: Active modification of network traffic by an adversary able to thereby compromise the confidentiality or integrity of the data.
中间人（MITM）攻击：对手主动修改网络流量，从而破坏数据的机密性或完整性。
Downgrade attack: (From [RFC4949].) A type of MITM attack in which the attacker can cause two parties, at the time they negotiate a security association, to agree on a lower level of protection than the highest level that could have been supported by both of them.
降级攻击：（来自[RFC4949]）一种MITM攻击类型，攻击者可在双方协商安全关联时，使双方同意低于双方可能支持的最高级别的保护级别。
Downgrade-resistant: A protocol is "downgrade-resistant" if it employs effective countermeasures against downgrade attacks.
抗降级：如果协议对降级攻击采取有效的对策，那么它就是“抗降级”的。
"Secure", "bogus", "insecure", "indeterminate": DNSSEC validation results, as defined in Section 4.3 of [RFC4035].
“安全”、“伪造”、“不安全”、“不确定”：DNSSEC验证结果，定义见[RFC4035]第4.3节。
Validating security-aware stub resolver and non-validating security-aware stub resolver: Capabilities of the stub resolver in use, as defined in [RFC4033]; note that this specification requires the use of a security-aware stub resolver.
验证安全感知存根解析器和非验证安全感知存根解析器：使用中存根解析器的功能，如[RFC4033]中所定义；请注意，此规范要求使用具有安全意识的存根解析器。
(Pre-DANE) opportunistic TLS: Best-effort use of TLS that is generally vulnerable to DNS forgery and STARTTLS downgrade attacks. When a TLS-encrypted communication channel is not available, message transmission takes place in the clear. MX record indirection generally precludes authentication even when TLS is available.
（丹麦之前）机会主义TLS：尽最大努力使用TLS，通常容易受到DNS伪造和STARTTLS降级攻击。当TLS加密通信信道不可用时，消息传输在clear中进行。MX记录间接寻址通常会排除身份验证，即使TLS可用。
Opportunistic DANE TLS: Best-effort use of TLS that is resistant to downgrade attacks for destinations with DNSSEC-validated TLSA records. When opportunistic DANE TLS is determined to be unavailable, clients should fall back to pre-DANE opportunistic TLS. Opportunistic DANE TLS requires support for DNSSEC, DANE, and STARTTLS on the client side, and STARTTLS plus a DNSSEC published TLSA record on the server side.
机会主义DANE TLS：尽最大努力使用TLS，对具有DNSSEC验证的TLSA记录的目的地抵御降级攻击。当确定丹麦机会主义TLS不可用时，客户应退回到丹麦之前的机会主义TLS。机会主义的DANE TLS要求在客户端支持DNSSEC、DANE和STARTTLS，在服务器端支持STARTTLS和DNSSEC发布的TLSA记录。
Reference identifier: (Special case of [RFC6125] definition.) One of the domain names associated by the SMTP client with the destination SMTP server for performing name checks on the server certificate. When name checks are applicable, at least one of the reference identifiers MUST match an [RFC6125] DNS-ID (or, if none are present, the [RFC6125] CN-ID) of the server certificate (see Section 3.2.3).
引用标识符：（RFC6125定义的特例。）SMTP客户端与目标SMTP服务器关联的域名之一，用于对服务器证书执行名称检查。当名称检查适用时，至少一个参考标识符必须与服务器证书的[RFC6125]DNS-ID（或者，如果不存在，则与[RFC6125]CN-ID）匹配（参见第3.2.3节）。
MX hostname: The RRDATA of an MX record consists of a 16 bit preference followed by a Mail Exchange domain name (see [RFC1035], Section 3.3.9). We will use the term "MX hostname" to refer to the latter, that is, the DNS domain name found after the preference value in an MX record. Thus, an "MX hostname" is specifically a reference to a DNS domain name rather than any host that bears that name.
MX主机名：MX记录的RRDATA由16位首选项和邮件交换域名组成（请参见[RFC1035]，第3.3.9节）。我们将使用术语“MX主机名”来指代后者，即在MX记录中的首选项值之后找到的DNS域名。因此，“MX主机名”具体指的是DNS域名，而不是具有该名称的任何主机。
Delayed delivery: Email delivery is a multi-hop store-and-forward process. When an MTA is unable to forward a message that may become deliverable later, the message is queued and delivery is retried periodically. Some MTAs may be configured with a fallback next-hop destination that handles messages that the MTA would otherwise queue and retry. When a fallback next-hop destination is configured, messages that would otherwise have to be delayed may be sent to the fallback next-hop destination instead. The fallback destination may itself be subject to opportunistic or mandatory DANE TLS (Section 6) as though it were the original message destination.
延迟交付：电子邮件交付是一个多跳存储转发过程。当MTA无法转发可能稍后可交付的邮件时，邮件将排队并定期重试交付。某些MTA可能配置了回退下一跳目标，用于处理MTA将排队并重试的邮件。当配置了回退下一跳目的地时，否则必须延迟的消息可以改为发送到回退下一跳目的地。回退目的地本身可能受制于机会主义或强制性DANE TLS（第6节），就好像它是原始消息目的地一样。
Original next-hop destination: The logical destination for mail delivery. By default, this is the domain portion of the recipient address, but MTAs may be configured to forward mail for some or all recipients via designated relays. The original next-hop destination is, respectively, either the recipient domain or the associated configured relay.
原始下一跳目的地：邮件传递的逻辑目的地。默认情况下，这是收件人地址的域部分，但MTA可以配置为通过指定的中继转发部分或所有收件人的邮件。原始下一跳目的地分别是收件人域或相关配置的中继。
MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
MTA：消息传输代理（[RFC5598]，第4.3.2节）。
MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
MSA：消息提交代理（[RFC5598]，第4.3.1节）。
MUA: Message User Agent ([RFC5598], Section 4.2.1).
MUA：消息用户代理（[RFC5598]，第4.2.1节）。
RR: A DNS resource record as defined in [RFC1034], Section 3.6.
RR:[RFC1034]第3.6节中定义的DNS资源记录。
RRset: An RRset ([RFC2181], Section 5) is a group of DNS resource records that share the same label, class, and type.
RRset:RRset（[RFC2181]，第5节）是一组共享相同标签、类和类型的DNS资源记录。
The Domain Name System Security Extensions (DNSSEC) add data origin authentication, data integrity, and data nonexistence proofs to the Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034], and [RFC4035].
域名系统安全扩展（DNSSEC）向域名系统（DNS）添加数据源身份验证、数据完整性和数据不存在证明。DNSSEC在[RFC4033]、[RFC4034]和[RFC4035]中定义。
As described in the introduction of [RFC6698], TLS authentication via the existing public Certification Authority (CA) PKI suffers from an overabundance of trusted parties capable of issuing certificates for any domain of their choice. DANE leverages the DNSSEC infrastructure to publish public keys and certificates for use with the Transport Layer Security (TLS) [RFC5246] protocol via the "TLSA" DNS record type. With DNSSEC, each domain can only vouch for the keys of its delegated sub-domains.
如[RFC6698]介绍中所述，通过现有公共证书颁发机构（CA）PKI进行TLS认证的受信任方过多，无法为其选择的任何域颁发证书。DANE利用DNSSEC基础设施发布公钥和证书，以便通过“TLSA”DNS记录类型与传输层安全（TLS）[RFC5246]协议一起使用。使用DNSSEC，每个域只能为其委托子域的密钥提供担保。
The TLS protocol enables secure TCP communication. In the context of this memo, channel security is assumed to be provided by TLS. Used without authentication, TLS provides only privacy protection against eavesdropping attacks. Otherwise, TLS also provides data origin authentication to guard against MITM attacks.
TLS协议支持安全的TCP通信。在本备忘录中，信道安全性假定由TLS提供。TLS在没有身份验证的情况下使用，仅提供隐私保护以防窃听攻击。否则，TLS还提供数据源身份验证以防止MITM攻击。
With HTTPS, TLS employs X.509 certificates [RFC5280] issued by one of the many CAs bundled with popular web browsers to allow users to authenticate their "secure" websites. Before we specify a new DANE TLS security model for SMTP, we will explain why a new security model is needed. In the process, we will explain why the familiar HTTPS security model is inadequate to protect inter-domain SMTP traffic.
通过HTTPS，TLS使用了许多与流行web浏览器捆绑在一起的CA之一颁发的X.509证书[RFC5280]，允许用户对其“安全”网站进行身份验证。在为SMTP指定新的DANE TLS安全模型之前，我们将解释为什么需要新的安全模型。在此过程中，我们将解释为什么熟悉的HTTPS安全模型不足以保护域间SMTP通信。
The subsections below outline four key problems with applying traditional Web PKI [RFC7435] to SMTP; these problems are addressed by this specification. Since an SMTP channel security policy is not explicitly specified in either the recipient address or the MX record, a new signaling mechanism is required to indicate when channel security is possible and should be used. The publication of TLSA records allows server operators to securely signal to SMTP clients that TLS is available and should be used. DANE TLSA makes it possible to simultaneously discover which destination domains support secure delivery via TLS and how to verify the authenticity of the associated SMTP services, providing a path forward to ubiquitous SMTP channel security.
以下小节概述了将传统Web PKI[RFC7435]应用于SMTP的四个关键问题；本规范解决了这些问题。由于SMTP通道安全策略未在收件人地址或MX记录中明确指定，因此需要一种新的信令机制来指示何时可以使用通道安全。TLSA记录的发布允许服务器操作员安全地向SMTP客户端发出TLS可用且应使用的信号。DANE TLSA使我们能够同时发现哪些目标域支持通过TLS进行安全传递，以及如何验证相关SMTP服务的真实性，从而提供一条通向无处不在的SMTP通道安全的路径。
SMTP [RFC5321] is a single-hop protocol in a multi-hop store-and-forward email delivery process. An SMTP envelope recipient address does not correspond to a specific transport-layer endpoint address; rather, at each relay hop, the transport-layer endpoint is the next-hop relay, while the envelope recipient address typically remains the same. Unlike HTTP and its corresponding secured version, HTTPS, where the use of TLS is signaled via the URI scheme, email recipient addresses do not directly signal transport security policy. Indeed, no such signaling could work well with SMTP, since TLS encryption of SMTP protects email traffic on a hop-by-hop basis while email addresses could only express end-to-end policy.
SMTP[RFC5321]是多跳存储转发电子邮件传递过程中的单跳协议。SMTP信封收件人地址与特定传输层端点地址不对应；相反，在每个中继跳，传输层端点是下一跳中继，而信封收件人地址通常保持不变。与HTTP及其相应的安全版本HTTPS不同，HTTPS通过URI方案通知TLS的使用，电子邮件收件人地址不直接通知传输安全策略。事实上，没有这样的信令可以很好地与SMTP配合使用，因为SMTP的TLS加密在逐跳的基础上保护电子邮件流量，而电子邮件地址只能表示端到端策略。
With no mechanism available to signal transport security policy, SMTP relays employ a best-effort "opportunistic" security model for TLS. A single SMTP server TCP listening endpoint can serve both TLS and non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS command [RFC3207]. The server signals TLS support to the client over a cleartext SMTP connection, and, if the client also supports TLS, it may negotiate a TLS-encrypted channel to use for email transmission. The server's indication of TLS support can be easily suppressed by an MITM attacker. Thus, pre-DANE SMTP TLS security can be subverted by simply downgrading a connection to cleartext. No TLS security feature can prevent this. The attacker can simply disable TLS.
由于没有可用于信号传输安全策略的机制，SMTP中继为TLS采用了尽力而为的“机会主义”安全模型。单个SMTP服务器TCP侦听端点可以同时服务于TLS和非TLS客户端；TLS的使用通过SMTP STARTTLS命令[RFC3207]协商。服务器通过明文SMTP连接向客户机发送TLS支持信号，如果客户机也支持TLS，它可以协商TLS加密通道以用于电子邮件传输。服务器对TLS支持的指示很容易被MITM攻击者压制。因此，丹麦以前的SMTP TLS安全性可以通过简单地降级到明文的连接而被破坏。没有任何TLS安全功能可以防止这种情况。攻击者只需禁用TLS即可。
With SMTP, DNS MX records abstract the next-hop transport endpoint and allow administrators to specify a set of target servers to which SMTP traffic should be directed for a given domain.
使用SMTP，DNS MX记录下一跳传输端点，并允许管理员指定一组目标服务器，SMTP通信应定向到给定域。
A TLS client is vulnerable to MITM attacks unless it verifies that the server's certificate binds the public key to a name that matches one of the client's reference identifiers. A natural choice of reference identifier is the server's domain name. However, with SMTP, server names are not directly encoded in the recipient address; instead, they are obtained indirectly via MX records. Without DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning attacks. Active attackers can forge DNS replies with fake MX records and can redirect email to servers with names of their choice. Therefore, secure verification of SMTP TLS certificates matching the server name is not possible without DNSSEC.
TLS客户端容易受到MITM攻击，除非它验证服务器的证书是否将公钥绑定到与客户端引用标识符之一匹配的名称。引用标识符的自然选择是服务器的域名。但是，使用SMTP时，服务器名称不会直接编码到收件人地址中；相反，它们是通过MX记录间接获得的。如果没有DNSSEC，MX查找容易受到MITM和DNS缓存中毒攻击。主动攻击者可以伪造带有虚假MX记录的DNS回复，并可以将电子邮件重定向到具有其选择名称的服务器。因此，如果没有DNSSEC，则无法安全验证与服务器名称匹配的SMTP TLS证书。
One might try to harden TLS for SMTP against DNS attacks by using the envelope recipient domain as a reference identifier and by requiring each SMTP server to possess a trusted certificate for the envelope recipient domain rather than the MX hostname. Unfortunately, this is impractical, as email for many domains is handled by third parties that are not in a position to obtain certificates for all the domains they serve. Deployment of the Server Name Indication (SNI) extension to TLS (see Section 3 of [RFC6066]) is no panacea, since SNI key management is operationally challenging except when the email service provider is also the domain's registrar and its certificate issuer; this is rarely the case for email.
可以尝试通过使用信封收件人域作为参考标识符，并通过要求每个SMTP服务器拥有信封收件人域的受信任证书而不是MX主机名，来加强SMTP的TLS以抵御DNS攻击。不幸的是，这是不切实际的，因为许多域的电子邮件是由第三方处理的，这些第三方无法获得它们所服务的所有域的证书。将服务器名称指示（SNI）扩展部署到TLS（见[RFC6066]第3节）并非万灵药，因为SNI密钥管理在操作上具有挑战性，除非电子邮件服务提供商也是域的注册商及其证书颁发者；电子邮件很少出现这种情况。
Since the recipient domain name cannot be used as the SMTP server reference identifier, and neither can the MX hostname without DNSSEC, large-scale deployment of authenticated TLS for SMTP requires that the DNS be secure.
由于收件人域名不能用作SMTP服务器引用标识符，没有DNSSEC的MX主机名也不能用作SMTP服务器引用标识符，因此，大规模部署经过身份验证的SMTP TLS要求DNS是安全的。
Since SMTP security depends critically on DNSSEC, it is important to point out that SMTP with DANE is consequently the most conservative possible trust model. It trusts only what must be trusted and no more. Adding any other trusted actors to the mix can only reduce SMTP security. A sender may choose to further harden DNSSEC for selected high-value receiving domains by configuring explicit trust anchors for those domains instead of relying on the chain of trust from the root domain. However, detailed discussion of DNSSEC security practices is out of scope for this document.
由于SMTP安全性严重依赖于DNSSEC，因此有必要指出，使用DANE的SMTP是最保守的可能信任模型。它只信任必须信任的东西，不再信任。向混合中添加任何其他受信任的参与者只能降低SMTP安全性。发送方可以通过为选定的高价值接收域配置显式信任锚，而不是依赖根域的信任链，来选择进一步强化这些域的DNSSEC。然而，DNSSEC安全实践的详细讨论超出了本文件的范围。
Sending systems are in some cases explicitly configured to use TLS for mail sent to selected peer domains, but this requires configuring sending MTAs with appropriate subject names or certificate content digests from their peer domains. Due to the resulting administrative burden, such statically configured SMTP secure channels are used rarely (generally only between domains that make bilateral arrangements with their business partners). Internet email, on the other hand, requires regularly contacting new domains for which security configurations cannot be established in advance.
在某些情况下，发送系统被显式配置为对发送到选定对等域的邮件使用TLS，但这需要将发送MTA配置为具有来自其对等域的适当主题名称或证书内容摘要。由于由此产生的管理负担，此类静态配置的SMTP安全通道很少使用（通常仅在与其业务伙伴进行双边安排的域之间使用）。另一方面，Internet电子邮件要求定期联系无法提前建立安全配置的新域。
The abstraction of the SMTP transport endpoint via DNS MX records, often across organizational boundaries, limits the use of public CA PKI with SMTP to a small set of sender-configured peer domains. With little opportunity to use TLS authentication, sending MTAs are rarely configured with a comprehensive list of trusted CAs. SMTP services that support STARTTLS often deploy X.509 certificates that are self-signed or issued by a private CA.
通过DNS MX记录抽象SMTP传输端点（通常跨越组织边界）将公共CA PKI与SMTP的使用限制在一小部分发送方配置的对等域。由于几乎没有机会使用TLS身份验证，发送MTA很少配置一个完整的可信CA列表。支持STARTTLS的SMTP服务通常部署由私人CA自签名或颁发的X.509证书。
Even if it were generally possible to determine a secure server name, the SMTP client would still need to verify that the server's certificate chain is issued by a trusted CA (a trust anchor). MTAs are not interactive applications where a human operator can make a decision (wisely or otherwise) to selectively disable TLS security policy when certificate chain verification fails. With no user to "click OK", the MTA's list of public CA trust anchors would need to be comprehensive in order to avoid bouncing mail addressed to sites that employ unknown CAs.
即使通常可以确定安全服务器名称，SMTP客户端仍需要验证服务器的证书链是否由受信任的CA（信任锚）颁发。MTA不是交互式应用程序，在这种应用程序中，操作员可以在证书链验证失败时（明智地或以其他方式）做出有选择地禁用TLS安全策略的决定。由于没有用户可以“单击确定”，MTA的公共CA信任锚列表需要全面，以避免退回发送到使用未知CA的站点的邮件。
On the other hand, each trusted CA can issue certificates for any domain. If even one of the configured CAs is compromised or operated by an adversary, it can subvert TLS security for all destinations. Any set of CAs is simultaneously both overly inclusive and not inclusive enough.
另一方面，每个受信任的CA都可以为任何域颁发证书。即使配置的CA中有一个被对手破坏或操作，它也会破坏所有目的地的TLS安全。任何一组CA同时具有过度包容性和不够包容性。
An SMTP client that implements opportunistic DANE TLS per this specification depends critically on the integrity of DNSSEC lookups, as discussed in Section 1.3.2. This section lists the DNS resolver requirements needed to avoid downgrade attacks when using opportunistic DANE TLS.
如第1.3.2节所述，根据本规范实施投机性DANE TLS的SMTP客户端在很大程度上取决于DNSSEC查找的完整性。本节列出了在使用机会主义DANE TLS时避免降级攻击所需的DNS解析程序要求。
A DNS lookup may signal an error or return a definitive answer. A security-aware resolver MUST be used for this specification. Security-aware resolvers will indicate the security status of a DNS RRset with one of four possible values defined in Section 4.3 of [RFC4035]: "secure", "insecure", "bogus", and "indeterminate". In [RFC4035], the meaning of the "indeterminate" security status is:
DNS查找可能会发出错误信号或返回最终答案。此规范必须使用具有安全意识的解析器。安全感知解析器将使用[RFC4035]第4.3节中定义的四个可能值之一指示DNS RRset的安全状态：“安全”、“不安全”、“伪造”和“不确定”。在[RFC4035]中，“不确定”安全状态的含义是：
An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.
由于解析程序无法获得必要的DNSSEC RRs，因此解析程序无法确定是否应对其进行签名的RRset。当安全感知解析器无法联系相关区域的安全感知名称服务器时，可能会发生这种情况。
Note that the "indeterminate" security status has a conflicting definition in Section 5 of [RFC4033]:
请注意，[RFC4033]第5节中的“不确定”安全状态定义有冲突：
There is no trust anchor that would indicate that a specific portion of the tree is secure.
没有表示树的特定部分是安全的信任锚。
In this document, the term "indeterminate" will be used exclusively in the [RFC4035] sense. Therefore, obtaining "indeterminate" lookup results is a (transient) failure condition, namely, the inability to locate the relevant DNS records. DNS records that would be classified "indeterminate" in the sense of [RFC4035] are simply classified as "insecure".
在本文件中，“不确定”一词仅用于[RFC4035]意义。因此，获取“不确定”查找结果是一种（暂时）故障情况，即无法定位相关DNS记录。在[RFC4035]意义上被分类为“不确定”的DNS记录被简单分类为“不安全”。
We do not need to distinguish between zones that lack a suitable ancestor trust anchor, and delegations (ultimately) from a trust anchor that designate a child zone as being "insecure". All "insecure" RRsets MUST be handled identically: in either case, non-validated data for the query domain is all that is and can be available, and authentication using the data is impossible. As the DNS root zone has been signed, we expect that validating resolvers used by Internet-facing MTAs will be configured with trust anchor data for the root zone and that therefore domains with no ancestor trust anchor will not be possible in most deployments.
我们不需要区分缺乏合适祖先信任锚的区域，以及（最终）将委托与指定子区域为“不安全”的信任锚的委托。所有“不安全”的RRSET必须以相同的方式处理：在任何一种情况下，查询域的未验证数据都是可用的，并且可以使用，并且不可能使用该数据进行身份验证。由于DNS根区域已签名，我们希望面向Internet的MTA使用的验证解析程序将配置根区域的信任锚点数据，因此在大多数部署中不可能使用没有祖先信任锚点的域。
As noted in Section 4.3 of [RFC4035], a security-aware DNS resolver MUST be able to determine whether a given non-error DNS response is "secure", "insecure", "bogus", or "indeterminate". It is expected that most security-aware stub resolvers will not signal an "indeterminate" security status (in the sense of [RFC4035]) to the application and will instead signal a "bogus" or error result. If a resolver does signal an [RFC4035] "indeterminate" security status, this MUST be treated by the SMTP client as though a "bogus" or error result had been returned.
如[RFC4035]第4.3节所述，具有安全意识的DNS解析器必须能够确定给定的无错误DNS响应是“安全”、“不安全”、“虚假”还是“不确定”。预计大多数具有安全意识的存根解析器不会向应用程序发送“不确定”安全状态信号（在[RFC4035]的意义上），而是发送“虚假”或错误结果信号。如果解析程序发出[RFC4035]“不确定”安全状态的信号，SMTP客户端必须将其视为返回了“虚假”或错误结果。
An MTA using a non-validating security-aware stub resolver MAY use the stub resolver's ability, if available, to signal DNSSEC validation status based on information the stub resolver has learned from an upstream validating recursive resolver. Security-oblivious stub resolvers [RFC4033] MUST NOT be used. In accordance with Section 4.9.3 of [RFC4035]:
使用非验证安全感知存根解析程序的MTA可以使用存根解析程序的功能（如果可用），根据存根解析程序从上游验证递归解析程序了解到的信息，向DNSSEC验证状态发送信号。不得使用不考虑安全性的存根解析器[RFC4033]。根据[RFC4035]第4.9.3节：
... a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel.
... 安全感知存根解析器不得依赖于据称代表其执行的签名验证，除非安全感知存根解析器通过安全通道从可信的安全感知递归名称服务器获得相关数据。
To avoid much repetition in the text below, we will pause to explain the handling of "bogus" or "indeterminate" DNSSEC query responses. These are not necessarily the result of a malicious actor; they can, for example, occur when network packets are corrupted or lost in transit. Therefore, "bogus" or "indeterminate" replies are equated in this memo with lookup failure.
为了避免在下面的文本中重复太多，我们将停下来解释对“虚假”或“不确定”DNSSEC查询响应的处理。这些不一定是恶意行为者的结果；例如，当网络数据包在传输过程中损坏或丢失时，就会发生这种情况。因此，本备忘录中的“虚假”或“不确定”回复等同于查找失败。
There is an important non-failure condition we need to highlight in addition to the obvious case of the DNS client obtaining a non-empty "secure" or "insecure" RRset of the requested type. Namely, it is not an error when either "secure" or "insecure" nonexistence is determined for the requested data. When a DNSSEC response with a validation status that is either "secure" or "insecure" reports either no records of the requested type or nonexistence of the query domain, the response is not a DNS error condition. The DNS client has not been left without an answer; it has learned that records of the requested type do not exist.
除了DNS客户端获得请求类型的非空“安全”或“不安全”RRset的明显情况外，我们还需要强调一个重要的非故障条件。也就是说，当确定请求的数据不存在“安全”或“不安全”时，这不是错误。当验证状态为“安全”或“不安全”的DNSSEC响应报告没有请求类型的记录或查询域不存在时，该响应不是DNS错误条件。DNS客户机没有得到答复；据了解，请求类型的记录不存在。
Security-aware stub resolvers will, of course, also signal DNS lookup errors in other cases, for example, when processing a "SERVFAIL" [RFC2136] response code (RCODE) [RFC1035], which will not have an associated DNSSEC status. All lookup errors are treated the same way by this specification, regardless of whether they are from a "bogus" or "indeterminate" DNSSEC status or from a more generic DNS error: the information that was requested cannot be obtained by the security-aware resolver at this time. Thus, a lookup error is either a failure to obtain the relevant RRset if it exists or a failure to determine that no such RRset exists when it does not.
当然，在其他情况下，具有安全意识的存根解析器也会发出DNS查找错误信号，例如，在处理“SERVFAIL”[RFC2136]响应代码（RCODE）[RFC1035]时，该代码将不具有关联的DNSSEC状态。本规范以相同的方式处理所有查找错误，无论它们是来自“虚假”或“不确定”DNSSEC状态，还是来自更一般的DNS错误：安全感知解析程序此时无法获取请求的信息。因此，查找错误要么是无法获取相关RRset（如果存在），要么是无法确定不存在此类RRset（如果不存在）。
In contrast to a "bogus" response or an "indeterminate" response, an "insecure" DNSSEC response is not an error; rather, as explained above, it indicates that the target DNS zone is either delegated as an "insecure" child of a "secure" parent zone or not a descendant of any of the configured DNSSEC trust anchors in use by the SMTP client. "Insecure" results will leave the SMTP client with degraded channel security but do not stand in the way of message delivery. See Section 2.2 for further details.
与“虚假”响应或“不确定”响应相比，“不安全”DNSSEC响应不是错误；相反，如上所述，它指示目标DNS区域被委托为“安全”父区域的“不安全”子区域，或者不是SMTP客户端使用的任何已配置DNSSEC信任锚的后代。“不安全”结果将使SMTP客户端的通道安全性降低，但不会妨碍邮件传递。详见第2.2节。
When a DNS lookup failure (an error, "bogus", or "indeterminate", as defined above) prevents an SMTP client from determining which SMTP server or servers it should connect to, message delivery MUST be delayed. This naturally includes, for example, the case when a "bogus" or "indeterminate" response is encountered during MX resolution. When multiple MX hostnames are obtained from a successful MX lookup but a later DNS lookup failure prevents network address resolution for a given MX hostname, delivery may proceed via any remaining MX hosts.
当DNS查找失败（错误，“虚假”或“不确定”，如上所述）阻止SMTP客户端确定其应连接到哪个或多个SMTP服务器时，邮件传递必须延迟。例如，这自然包括在MX解析过程中遇到“虚假”或“不确定”响应的情况。如果从成功的MX查找中获得多个MX主机名，但随后的DNS查找失败阻止了对给定MX主机名的网络地址解析，则可以通过任何剩余的MX主机继续传递。
When a particular SMTP server is securely identified as the delivery destination, a set of DNS lookups (Section 2.2) MUST be performed to locate any related TLSA records. If any DNS queries used to locate TLSA records fail (due to "bogus" or "indeterminate" records, timeouts, malformed replies, SERVFAIL responses, etc.), then the SMTP
当特定SMTP服务器被安全地标识为传递目标时，必须执行一组DNS查找（第2.2节）以定位任何相关的TLSA记录。如果用于定位TLSA记录的任何DNS查询失败（由于“虚假”或“不确定”记录、超时、错误回复、SERVFAIL响应等），则SMTP
client MUST treat that server as unreachable and MUST NOT deliver the message via that server. If no servers are reachable, delivery is delayed.
客户端必须将该服务器视为无法访问，并且不得通过该服务器传递消息。如果无法访问任何服务器，则延迟交付。
In the text that follows, we will only describe what happens when all relevant DNS queries succeed. If any DNS failure occurs, the SMTP client MUST behave as described in this section, by "skipping" the SMTP server or destination that is problematic. Queries for candidate TLSA records are explicitly part of "all relevant DNS queries", and SMTP clients MUST NOT continue to connect to an SMTP server or destination whose TLSA record lookup fails.
在下面的文本中，我们将仅描述当所有相关DNS查询成功时发生的情况。如果发生任何DNS故障，SMTP客户端必须按照本节所述的方式“跳过”有问题的SMTP服务器或目标。查询候选TLSA记录是“所有相关DNS查询”的一部分，SMTP客户端不得继续连接到TLSA记录查找失败的SMTP服务器或目标。
A note about DNAME aliases: a query for a domain name whose ancestor domain is a DNAME alias returns the DNAME RR for the ancestor domain along with a CNAME that maps the query domain to the corresponding sub-domain of the target domain of the DNAME alias [RFC6672]. Therefore, whenever we speak of CNAME aliases, we implicitly allow for the possibility that the alias in question is the result of an ancestor domain DNAME record. Consequently, no explicit support for DNAME records is needed in SMTP software; it is sufficient to process the resulting CNAME aliases. DNAME records only require special processing in the validating stub resolver library that checks the integrity of the combined DNAME + CNAME reply. When DNSSEC validation is handled by a local caching resolver rather than the MTA itself, even that part of the DNAME support logic is outside the MTA.
关于DNAME别名的注意事项：对其祖先域为DNAME别名的域名的查询将返回祖先域的DNAME RR以及将查询域映射到DNAME别名的目标域的相应子域的CNAME[RFC6672]。因此，每当我们谈到CNAME别名时，我们都会隐式地考虑到所讨论的别名可能是祖先域DNAME记录的结果。因此，SMTP软件中不需要明确支持DNAME记录；处理生成的CNAME别名就足够了。DNAME记录只需要在验证存根解析器库中进行特殊处理，以检查组合DNAME+CNAME回复的完整性。当DNSSEC验证由本地缓存解析程序而不是MTA本身处理时，即使是DNAME支持逻辑的这一部分也在MTA之外。
When a stub resolver returns a response containing a CNAME alias that does not also contain the corresponding query results for the target of the alias, the SMTP client will need to repeat the query at the target of the alias and should do so recursively up to some configured or implementation-dependent recursion limit. If at any stage of CNAME expansion an error is detected, the lookup of the original requested records MUST be considered to have failed.
当存根解析程序返回一个包含CNAME别名的响应时，该别名不包含别名目标的相应查询结果，SMTP客户端将需要在别名目标处重复查询，并应递归执行，直至达到某个配置的或依赖于实现的递归限制。如果在CNAME扩展的任何阶段检测到错误，则必须将原始请求记录的查找视为失败。
Whether a chain of CNAME records was returned in a single stub resolver response or via explicit recursion by the SMTP client, if at any stage of recursive expansion an "insecure" CNAME record is encountered, then it and all subsequent results (in particular, the final result) MUST be considered "insecure", regardless of whether or not any earlier CNAME records leading to the "insecure" record were "secure".
无论CNAME记录链是在单个存根解析程序响应中返回的，还是通过SMTP客户端的显式递归返回的，如果在递归扩展的任何阶段遇到“不安全”的CNAME记录，则必须将其和所有后续结果（尤其是最终结果）视为“不安全”，无论导致“不安全”记录的任何早期CNAME记录是否“安全”。
Note that a security-aware non-validating stub resolver may return to the SMTP client an "insecure" reply received from a validating recursive resolver that contains a CNAME record along with additional answers recursively obtained starting at the target of the CNAME. In
请注意，具有安全意识的非验证存根解析程序可能会向SMTP客户端返回从验证递归解析程序接收到的“不安全”回复，该解析程序包含CNAME记录以及从CNAME目标开始递归获取的其他答案。在里面
this case, the only possible conclusion is that some record in the set of records returned is "insecure", and it is, in fact, possible that the initial CNAME record and a subset of the subsequent records are "secure".
在这种情况下，唯一可能的结论是返回的记录集中的某些记录是“不安全的”，事实上，初始CNAME记录和后续记录的子集可能是“安全的”。
If the SMTP client needs to determine the security status of the DNS zone containing the initial CNAME record, it will need to issue a separate query of type "CNAME" that returns only the initial CNAME record. Specifically, as discussed in Section 2.2.2, when "insecure" A or AAAA records are found for an SMTP server via a CNAME alias, the SMTP client will need to perform an additional CNAME query in order to determine whether or not the DNS zone in which the alias is published is DNSSEC signed.
如果SMTP客户端需要确定包含初始CNAME记录的DNS区域的安全状态，则需要发出单独的“CNAME”类型查询，该查询只返回初始CNAME记录。具体而言，如第2.2.2节所述，当通过CNAME别名发现SMTP服务器的“不安全”A或AAAA记录时，SMTP客户端需要执行额外的CNAME查询，以确定发布别名的DNS区域是否为DNSSEC签名。
As noted previously (in Section 1.3.1), opportunistic TLS with SMTP servers that advertise TLS support via STARTTLS is subject to an MITM downgrade attack. Also, some SMTP servers that are not, in fact, TLS capable erroneously advertise STARTTLS by default, and clients need to be prepared to retry cleartext delivery after STARTTLS fails. In contrast, DNSSEC-validated TLSA records MUST NOT be published for servers that do not support TLS. Clients can safely interpret their presence as a commitment by the server operator to implement TLS and STARTTLS.
如前所述（第1.3.1节），通过STARTTLS公布TLS支持的SMTP服务器的机会主义TLS会受到MITM降级攻击。此外，一些事实上不支持TLS的SMTP服务器在默认情况下会错误地播发STARTTLS，客户端需要准备在STARTTLS失败后重试明文传递。相反，不得为不支持TLS的服务器发布DNSSEC验证的TLSA记录。客户端可以安全地将它们的存在解释为服务器运营商对实现TLS和STARTTLS的承诺。
This memo defines four actions to be taken after the search for a TLSA record returns "secure" usable results, "secure" unusable results, "insecure" or no results, or an error signal. The term "usable" in this context is in the sense of Section 4.1 of [RFC6698]. Specifically, if the DNS lookup for a TLSA record returns:
此备忘录定义了在搜索TLSA记录返回“安全”可用结果、“安全”不可用结果、“不安全”或无结果或错误信号后要采取的四项操作。本上下文中的术语“可用”符合[RFC6698]第4.1节的含义。具体而言，如果TLSA记录的DNS查找返回：
A "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document. Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
至少有一条可用记录的“安全”TLSA RRset：与MTA的任何连接都必须采用TLS加密，并且必须使用本文档其余部分讨论的技术对SMTP服务器进行身份验证。未能建立经过身份验证的TLS连接必须导致退回到下一个SMTP服务器或延迟传递。
A "secure" non-empty TLSA RRset where all the records are unusable: Any connection to the MTA MUST be made via TLS, but authentication is not required. Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
“安全”非空TLSA RRset，其中所有记录都不可用：必须通过TLS建立与MTA的任何连接，但不需要身份验证。未能建立加密的TLS连接必须导致退回到下一个SMTP服务器或延迟传递。
An "insecure" TLSA RRset or DNSSEC-authenticated denial of existence of the TLSA records: A connection to the MTA SHOULD be made using (pre-DANE) opportunistic TLS; this includes using cleartext delivery when the remote SMTP server does not appear to support TLS. The MTA MAY retry in cleartext when delivery via TLS fails during the handshake or even during data transfer.
“不安全”TLSA RRset或DNSSEC认证的TLSA记录不存在：应使用（丹麦之前）机会主义TLS连接到MTA；这包括在远程SMTP服务器似乎不支持TLS时使用明文传递。在握手过程中，甚至在数据传输过程中，通过TLS传递失败时，MTA可能会在明文中重试。
Any lookup error: Lookup errors, including "bogus" and "indeterminate" as explained in Section 2.1.1, MUST result in falling back to the next SMTP server or delayed delivery.
任何查找错误：查找错误，包括第2.1.1节中解释的“虚假”和“不确定”，必须导致退回到下一个SMTP服务器或延迟传递。
An SMTP client MAY be configured to mandate DANE-verified delivery for some destinations. With mandatory DANE TLS (Section 6), delivery proceeds only when "secure" TLSA records are used to establish an encrypted and authenticated TLS channel with the SMTP server.
SMTP客户端可能被配置为强制某些目的地的DANE验证传递。对于强制性的DANE TLS（第6节），只有在使用“安全”TLSA记录与SMTP服务器建立加密和认证的TLS通道时，才能进行交付。
When the original next-hop destination is an address literal rather than a DNS domain, DANE TLS does not apply. Delivery proceeds using any relevant security policy configured by the MTA administrator. Similarly, when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if an MTA chooses to connect to the network address in the nonconformant MX record, DANE TLSA does not apply for such a connection.
当原始下一跳目的地是地址文字而不是DNS域时，DANE TLS不适用。使用MTA管理员配置的任何相关安全策略进行交付。类似地，当MX RRset错误地列出网络地址而不是MX主机名时，如果MTA选择连接到不符合MX记录中的网络地址，则DANE TLSA不适用于此类连接。
In the subsections that follow, we explain how to locate the SMTP servers and the associated TLSA records for a given next-hop destination domain. We also explain which name or names are to be used in identity checks of the SMTP server certificate.
在接下来的小节中，我们将解释如何为给定的下一跳目标域定位SMTP服务器和关联的TLSA记录。我们还解释了在SMTP服务器证书的身份检查中使用的名称。
In this section, we consider next-hop domains that are subject to MX resolution and have MX records. The TLSA records and the associated base domain are derived separately for each MX hostname that is used to attempt message delivery. DANE TLS can authenticate message delivery to the intended next-hop domain only when the MX records are obtained securely via a DNSSEC-validated lookup.
在这一节中，我们考虑下一跳域的MX分辨率和MX记录。TLSA记录和关联的基本域分别为用于尝试消息传递的每个MX主机名派生。只有通过DNSSEC验证的查找安全地获取MX记录时，DANE TLS才能对发送到预期下一跳域的消息进行身份验证。
MX records MUST be sorted by preference; an MX hostname with a worse (numerically higher) MX preference that has TLSA records MUST NOT preempt an MX hostname with a better (numerically lower) preference that has no TLSA records. In other words, prevention of delivery loops by obeying MX preferences MUST take precedence over channel security considerations. Even with two equal-preference MX records, an MTA is not obligated to choose the MX hostname that offers more
MX记录必须按首选项排序；具有较差（数值较高）MX首选项且具有TLSA记录的MX主机名不得抢占具有较好（数值较低）首选项且没有TLSA记录的MX主机名。换句话说，通过遵守MX首选项来防止传递循环必须优先于通道安全考虑。即使有两个相同的首选项MX记录，MTA也没有义务选择提供更多首选项的MX主机名
security. Domains that want secure inbound mail delivery need to ensure that all their SMTP servers and MX records are configured accordingly.
安全需要安全入站邮件传递的域需要确保其所有SMTP服务器和MX记录都已相应配置。
In the language of [RFC5321], Section 5.1, the original next-hop domain is the "initial name". If the MX lookup of the initial name results in a CNAME alias, the MTA replaces the initial name with the resulting name and performs a new lookup with the new name. MTAs typically support recursion in CNAME expansion, so this replacement is performed repeatedly (up to the MTA's recursion limit) until the ultimate non-CNAME domain is found.
在[RFC5321]第5.1节的语言中，原始下一跳域是“初始名称”。如果初始名称的MX查找产生CNAME别名，MTA将用结果名称替换初始名称，并用新名称执行新查找。MTA通常支持CNAME扩展中的递归，因此重复执行此替换（直到MTA的递归限制），直到找到最终的非CNAME域。
If the MX RRset (or any CNAME leading to it) is "insecure" (see Section 2.1.1) and DANE TLS for the given destination is mandatory (Section 6), delivery MUST be delayed. If the MX RRset is "insecure" and DANE TLS is not mandatory, the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).
如果MX RRset（或任何通向它的CNAME）是“不安全的”（见第2.1.1节），并且指定目的地的DANE TLS是强制性的（第6节），则必须延迟交付。如果MX RRset是“不安全的”，并且DANE TLS不是强制性的，SMTP客户端可以自由使用前DANE机会主义TLS（甚至可能是明文）。
Since the protocol in this memo is an Opportunistic Security protocol [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in Section 2.2.2 below), even with MX hosts obtained via an "insecure" MX RRset. For example, when a hosting provider has a signed DNS zone and publishes TLSA records for its SMTP servers, hosted domains that are not signed may still benefit from the provider's TLSA records. Deliveries via the provider's SMTP servers will not be subject to active attacks when sending SMTP clients elect to use the provider's TLSA records (active attacks that tamper with the "insecure" MX RRset are of course still possible in this case).
由于本备忘录中的协议是一种机会主义安全协议[RFC7435]，因此SMTP客户端可以选择使用DANE TLS（如下文第2.2.2节所述），即使使用通过“不安全”MX RRset获得的MX主机也是如此。例如，当托管提供程序具有签名DNS区域并为其SMTP服务器发布TLSA记录时，未签名的托管域仍可能受益于提供程序的TLSA记录。当发送SMTP客户端选择使用提供商的TLSA记录时，通过提供商的SMTP服务器进行的传递不会受到主动攻击（在这种情况下，篡改“不安全”MX RRset的主动攻击当然仍然是可能的）。
When the MX records are not (DNSSEC) signed, an active attacker can redirect SMTP clients to MX hosts of his choice. Such redirection is tamper-evident when SMTP servers found via "insecure" MX records are recorded as the next-hop relay in the MTA delivery logs in their original (rather than CNAME-expanded) form. Sending MTAs SHOULD log unexpanded MX hostnames when these result from "insecure" MX lookups. Any successful authentication via an insecurely determined MX host MUST NOT be misrepresented in the mail logs as secure delivery to the intended next-hop domain.
当MX记录没有（DNSSEC）签名时，活动攻击者可以将SMTP客户端重定向到他选择的MX主机。当通过“不安全”MX记录找到的SMTP服务器以原始（而不是CNAME扩展）形式记录为MTA传递日志中的下一跳中继时，这种重定向是篡改明显的。当MX主机名是“不安全”的MX查找结果时，发送MTA应记录未扩展的MX主机名。通过不安全确定的MX主机进行的任何成功身份验证都不得在邮件日志中错误地表示为安全传递到预期的下一跳域。
In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure", then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2. When, for a given MX hostname, no TLSA records are found or only "insecure" TLSA records are found, DANE TLSA is not applicable with the SMTP server in question, and delivery proceeds to that host as with pre-DANE opportunistic TLS. To avoid downgrade attacks, any errors during TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP server in question to be treated as unreachable.
在没有DNS查找错误的情况下（第2.1.1节），如果MX RRset不是“不安全的”，则它是“安全的”，SMTP客户端必须按照第2.2.2节中的说明处理每个MX主机名。对于给定的MX主机名，如果找不到TLSA记录或只找到“不安全”的TLSA记录，则DANE TLSA不适用于所述SMTP服务器，并与前DANE机会主义TLS一样将传递到该主机。为避免降级攻击，如第2.1.2节所述，TLSA查找过程中的任何错误都必须导致相关SMTP服务器被视为无法访问。
This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution, that represents a hostname from a "secure" MX RRset, or that lacks MX records. Such domains include:
本节描述了用于定位输入域的TLSA记录和相关TLSA基本域的算法，该输入域不受MX解析的约束，表示“安全”MX RRset中的主机名，或者缺少MX记录。这些领域包括：
o Any host that is configured by the sending MTA administrator as the next-hop relay for some or all domains and that is not subject to MX resolution.
o 由发送MTA管理员配置为某些或所有域的下一跳中继且不受MX解析约束的任何主机。
o A domain that has MX records. When a domain has MX records, we treat each MX host listed in those MX records as though it were a non-MX destination -- that is, in the same way as we would treat an administrator-configured relay that handles mail for that domain. (Unlike administrator-specified relays, MTAs are not required to support CNAME expansion of next-hop names found via MX lookups.)
o 具有MX记录的域。当一个域有MX记录时，我们将这些MX记录中列出的每个MX主机视为非MX目的地——也就是说，与处理该域邮件的管理员配置的中继相同。（与管理员指定的中继不同，MTA不需要支持通过MX查找找到的下一跳名称的CNAME扩展。）
o A next-hop destination domain subject to MX resolution that has no MX records. In this case, the domain's name is implicitly also its sole SMTP server name.
o 受MX解析约束的下一跳目标域，没有MX记录。在本例中，域名隐式地也是其唯一的SMTP服务器名。
Note that DNS queries with type TLSA are mishandled by load-balancing nameservers that serve the MX hostnames of some large email providers. The DNS zones served by these nameservers are not signed and contain no TLSA records. These nameservers SHOULD provide "insecure" negative replies that indicate the nonexistence of the TLSA records, but instead they fail by not responding at all or by responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g., SERVFAIL or NOTIMP [RFC2136].
请注意，为某些大型电子邮件提供商的MX主机名提供服务的负载平衡名称服务器错误地处理了TLSA类型的DNS查询。这些名称服务器服务的DNS区域没有签名，并且不包含TLSA记录。这些名称服务器应提供“不安全”的否定回复，表明TLSA记录不存在，但它们完全不响应或使用NXDOMAIN以外的DNS RCODE[RFC1035]响应而失败，例如SERVFAIL或NOTIMP[RFC2136]。
To avoid problems delivering mail to domains whose SMTP servers are served by these problematic nameservers, the SMTP client MUST perform any A and/or AAAA queries for the destination before attempting to locate the associated TLSA records. This lookup is needed in any case to determine (1) whether or not the destination domain is reachable and (2) the DNSSEC validation status of the chain of CNAME queries required to reach the ultimate address records.
为避免将邮件发送到SMTP服务器由这些有问题的名称服务器提供服务的域时出现问题，SMTP客户端必须在尝试查找关联的TLSA记录之前对目标执行任何A和/或AAAA查询。在任何情况下都需要此查找来确定（1）目标域是否可访问，以及（2）访问最终地址记录所需的CNAME查询链的DNSSEC验证状态。
If no address records are found, the destination is unreachable. If address records are found but the DNSSEC validation status of the first query response is "insecure" (see Section 2.1.3), the SMTP client SHOULD NOT proceed to search for any associated TLSA records. In the case of these problematic domains, TLSA queries would lead to DNS lookup errors and would cause messages to be consistently delayed and ultimately returned to the sender. We don't expect to find any
如果未找到地址记录，则无法访问目标。如果找到地址记录，但第一个查询响应的DNSSEC验证状态为“不安全”（参见第2.1.3节），SMTP客户端不应继续搜索任何相关的TLSA记录。对于这些有问题的域，TLSA查询将导致DNS查找错误，并将导致消息持续延迟，最终返回给发送方。我们不指望能找到什么
"secure" TLSA records associated with a TLSA base domain that lies in an unsigned DNS zone. Therefore, skipping TLSA lookups in this case will also reduce latency, with no detrimental impact on security.
与位于未签名DNS区域中的TLSA基本域关联的“安全”TLSA记录。因此，在这种情况下跳过TLSA查找也将减少延迟，而不会对安全性造成有害影响。
If the A and/or AAAA lookup of the initial name yields a CNAME, we replace it with the resulting name as if it were the initial name and perform a lookup again using the new name. This replacement is performed recursively (up to the MTA's recursion limit).
如果初始名称的A和/或AAAA查找产生CNAME，我们将其替换为结果名称，就像它是初始名称一样，并使用新名称再次执行查找。此替换以递归方式执行（直到MTA的递归限制）。
We consider the following cases for handling a DNS response for an A or AAAA DNS lookup:
我们考虑以下情况来处理A或AAAA DNS查找的DNS响应：
Not found: When the DNS queries for A and/or AAAA records yield neither a list of addresses nor a CNAME (or CNAME expansion is not supported), the destination is unreachable.
找不到：当对A和/或AAAA记录的DNS查询既不产生地址列表也不产生CNAME（或不支持CNAME扩展）时，无法访问目标。
Non-CNAME: The answer is not a CNAME alias. If the address RRset is "secure", TLSA lookups are performed as described in Section 2.2.3 with the initial name as the candidate TLSA base domain. If no "secure" TLSA records are found, DANE TLS is not applicable and mail delivery proceeds with pre-DANE opportunistic TLS (which, being best-effort, degrades to cleartext delivery when STARTTLS is not available or the TLS handshake fails).
非CNAME：答案不是CNAME别名。如果地址RRset是“安全”的，则按照第2.2.3节所述执行TLSA查找，初始名称为候选TLSA基域。如果未找到“安全”的TLSA记录，则丹麦TLS不适用，邮件交付将使用前丹麦投机取巧的TLS（在STARTTLS不可用或TLS握手失败时，尽最大努力将降级为明文交付）。
Insecure CNAME: The input domain is a CNAME alias, but the ultimate network address RRset is "insecure" (see Section 2.1.1). If the initial CNAME response is also "insecure", DANE TLS does not apply. Otherwise, this case is treated just like the non-CNAME case above, where a search is performed for a TLSA record with the original input domain as the candidate TLSA base domain.
不安全的CNAME：输入域是CNAME别名，但最终网络地址RRset是“不安全的”（参见第2.1.1节）。如果初始CNAME响应也“不安全”，则DANE TLS不适用。否则，这种情况就像上面的非CNAME情况一样处理，其中对原始输入域作为候选TLSA基域的TLSA记录执行搜索。
Secure CNAME: The input domain is a CNAME alias, and the ultimate network address RRset is "secure" (see Section 2.1.1). Two candidate TLSA base domains are tried: the fully CNAME-expanded initial name and, failing that, the initial name itself.
安全CNAME：输入域是CNAME别名，最终网络地址RRset是“安全的”（参见第2.1.1节）。尝试了两个候选TLSA基域：完全CNAME扩展的初始名称，如果扩展失败，则初始名称本身。
In summary, if it is possible to securely obtain the full, CNAME-expanded, DNSSEC-validated address records for the input domain, then that name is the preferred TLSA base domain. Otherwise, the unexpanded input domain is the candidate TLSA base domain. When no "secure" TLSA records are found at either the CNAME-expanded or unexpanded domain, then DANE TLS does not apply for mail delivery via the input domain in question. And, as always, errors, "bogus" results, or "indeterminate" results for any query in the process MUST result in delaying or abandoning delivery.
总之，如果可以安全地获取输入域的完整、CNAME扩展、DNSSEC验证的地址记录，则该名称是首选TLSA基域。否则，未扩展的输入域是候选TLSA基域。如果在CNAME扩展域或未扩展域中均未找到“安全”TLSA记录，则DANE TLS不会通过相关输入域申请邮件传递。而且，一如既往，流程中任何查询的错误、“虚假”结果或“不确定”结果都必须导致延迟或放弃交付。
When the SMTP server's hostname is not a CNAME or DNAME alias, the list of associated candidate TLSA base domains (see below) consists of just the server hostname.
当SMTP服务器的主机名不是CNAME或DNAME别名时，关联的候选TLSA基本域列表（见下文）仅包含服务器主机名。
When the hostname is an alias with a "secure" (at every stage) full expansion, the list of candidate TLSA base domains (see below) is a pair of domains: the fully expanded server hostname first, and the unexpanded server hostname second.
当主机名是具有“安全”（在每个阶段）完全扩展的别名时，候选TLSA基本域列表（见下文）是一对域：首先是完全扩展的服务器主机名，其次是未扩展的服务器主机名。
Each candidate TLSA base domain (alias-expanded or original) is in turn prefixed with service labels of the form "_<port>._tcp". The resulting domain name is used to issue a DNSSEC query with the query type set to TLSA ([RFC6698], Section 7.1).
每个候选TLSA基本域（扩展别名或原始别名）的前缀依次为格式为“\u<port>\u tcp”的服务标签。生成的域名用于发出DNSSEC查询，查询类型设置为TLSA（[RFC6698]，第7.1节）。
The first of these candidate domains to yield a "secure" TLSA RRset becomes the actual TLSA base domain.
产生“安全”TLSA RRset的第一个候选域成为实际的TLSA基域。
For SMTP, the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator, in which case the SMTP client MUST use the appropriate number in the "_<port>" prefix in place of "_25". If, for example, the candidate base domain is "mx.example.com" and the SMTP connection is to port 25, the TLSA RRset is obtained via a DNSSEC query of the form:
对于SMTP，目标TCP端口通常为25，但这可能与MTA管理员指定的自定义路由不同，在这种情况下，SMTP客户端必须在“\u<port>”前缀中使用适当的数字来代替“\u 25”。例如，如果候选基本域为“mx.example.com”，SMTP连接为端口25，则通过DNSSEC查询获得TLSA RRset，其形式如下：
_25._tcp.mx.example.com. IN TLSA ?
_25._tcp.mx.example.com。在TLSA？
The query response may be a CNAME or the actual TLSA RRset. If the response is a CNAME, the SMTP client (through the use of its security-aware stub resolver) restarts the TLSA query at the target domain, following CNAMEs as appropriate, and keeps track of whether or not the entire chain is "secure". If any "insecure" records are encountered or the TLSA records don't exist, the next candidate TLSA base domain is tried instead.
查询响应可以是CNAME或实际TLSA RRset。如果响应是CNAME，SMTP客户端（通过使用其安全感知的存根解析器）在目标域上重新启动TLSA查询，并根据需要跟踪CNAMEs，并跟踪整个链是否“安全”。如果遇到任何“不安全”记录或TLSA记录不存在，则尝试下一个候选TLSA基域。
If the ultimate response is a "secure" TLSA RRset, then the candidate TLSA base domain will be the actual TLSA base domain, and the TLSA RRset will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records, then the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).
如果最终响应是“安全”TLSA RRset，则候选TLSA基本域将是实际的TLSA基本域，并且TLSA RRset将构成目标的TLSA记录。如果候选TLSA基本域中没有一个产生“安全”的TLSA记录，则SMTP客户端可以自由使用丹麦以前的机会主义TLS（甚至可能是明文）。
TLSA record publishers may leverage CNAMEs to reference a single authoritative TLSA RRset specifying a common CA or a common end-entity certificate to be used with multiple TLS services. Such CNAME expansion does not change the SMTP client's notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is a CNAME, the base
TLSA记录发布者可以利用CNAMEs引用一个权威TLSA RRset，指定一个公共CA或一个公共终端实体证书，用于多个TLS服务。此类CNAME扩展不会改变SMTP客户端对TLSA基本域的概念；因此，当_25._tcp.mx.example.com是CNAME时
domain remains mx.example.com, and this is still the reference identifier used together with the next-hop domain in peer certificate name checks.
域仍然是mx.example.com，这仍然是在对等证书名称检查中与下一跳域一起使用的参考标识符。
Note that shared end-entity certificate associations expose the publishing domain to substitution attacks, where an MITM attacker can reroute traffic to a different server that shares the same end-entity certificate. Such shared end-entity TLSA records SHOULD be avoided unless the servers in question are functionally equivalent or employ mutually incompatible protocols (an active attacker gains nothing by diverting client traffic from one such server to another).
请注意，共享终端实体证书关联使发布域遭受替换攻击，其中MITM攻击者可以将流量重新路由到共享同一终端实体证书的其他服务器。应避免此类共享终端实体TLSA记录，除非相关服务器功能等效或采用互不兼容的协议（主动攻击者通过将客户端流量从一台此类服务器转移到另一台此类服务器而一无所获）。
A better example, employing a shared trust anchor rather than shared end-entity certificates, is illustrated by the DNSSEC-validated records below:
下面的DNSSEC验证记录说明了使用共享信任锚而非共享终端实体证书的更好示例：
example.com. IN MX 0 mx1.example.com. example.com. IN MX 0 mx2.example.com. _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com. _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com. tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
example.com。在MX 0 mx1.example.com中。example.com。在MX 0 mx2.example.com中_25._tcp.mx1.example.com。在CNAME tlsa201._dane.example.com中_25._tcp.mx2.example.com。在CNAME tlsa201._dane.example.com中。tlsa201._dane.example.com。在TLSA 2 0 1 e3b0c44298fc1c149a中。。。
The SMTP servers mx1.example.com and mx2.example.com will be expected to have certificates issued under a common trust anchor, but each MX hostname's TLSA base domain remains unchanged despite the above CNAME records. Correspondingly, each SMTP server will be associated with a pair of reference identifiers consisting of its hostname plus the next-hop domain "example.com".
SMTP服务器mx1.example.com和mx2.example.com预计将具有在公共信任锚下颁发的证书，但尽管有上述CNAME记录，每个MX主机名的TLSA基本域仍保持不变。相应地，每个SMTP服务器将与一对引用标识符相关联，该标识符由其主机名和下一跳域“example.com”组成。
If, during TLSA resolution (including possible CNAME indirection), at least one "secure" TLSA record is found (even if not usable because it is unsupported by the implementation or support is administratively disabled), then the corresponding host has signaled its commitment to implement TLS. The SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS. This is required to avoid MITM STARTTLS downgrade attacks.
如果在TLSA解析期间（包括可能的CNAME间接寻址），发现至少一条“安全”TLSA记录（即使由于实现不支持而不可用，或者支持被管理性禁用），则相应的主机已发出信号表示其承诺实现TLS。除非通过STARTTLS协商TLS会话，否则SMTP客户端不得通过相应的主机传递邮件。这是避免MITM STARTTLS降级攻击所必需的。
As noted previously (in Section 2.2.2), when no "secure" TLSA records are found at the fully CNAME-expanded name, the original unexpanded name MUST be tried instead. This supports customers of hosting providers where the provider's zone cannot be validated with DNSSEC but the customer has shared appropriate key material with the hosting provider to enable TLS via SNI. Intermediate names that arise during CNAME expansion that are neither the original name nor the final name are never candidate TLSA base domains, even if "secure".
如前所述（第2.2.2节），当在完全CNAME扩展名处未找到“安全”TLSA记录时，必须尝试原始未扩展名。这支持托管提供商的客户，如果提供商的区域无法通过DNSSEC验证，但客户已与托管提供商共享适当的关键材料，以便通过SNI启用TLS。在CNAME扩展过程中出现的中间名称（既不是原始名称也不是最终名称）永远不是候选TLSA基域，即使是“安全的”。
This section describes which TLSA records are applicable to SMTP opportunistic DANE TLS and how to apply such records to authenticate the SMTP server. With opportunistic DANE TLS, both the TLS support implied by the presence of DANE TLSA records and the verification parameters necessary to authenticate the TLS peer are obtained together. In contrast to protocols where channel security policy is set exclusively by the client, authentication via this protocol is expected to be less prone to connection failure caused by incompatible configuration of the client and server.
本节介绍哪些TLSA记录适用于SMTP投机性DANE TLS，以及如何应用这些记录对SMTP服务器进行身份验证。对于机会主义的DANE TLS，可以同时获得DANE TLSA记录所暗示的TLS支持和认证TLS对等方所需的验证参数。与通道安全策略由客户端专门设置的协议相比，通过此协议进行的身份验证预计不太容易因客户端和服务器的配置不兼容而导致连接失败。
The DANE TLSA specification [RFC6698] defines multiple TLSA RR types via combinations of three numeric parameters. The numeric values of these parameters were later given symbolic names in [RFC7218]. The rest of the TLSA record is the "certificate association data field", which specifies the full or digest value of a certificate or public key.
丹麦TLSA规范[RFC6698]通过三个数字参数的组合定义了多个TLSA RR类型。这些参数的数值后来在[RFC7218]中给出了符号名称。TLSA记录的其余部分是“证书关联数据字段”，它指定证书或公钥的完整值或摘要值。
Since opportunistic DANE TLS will be used by non-interactive MTAs, with no user to "click OK" when authentication fails, reliability of peer authentication is paramount. Server operators are advised to publish TLSA records that are least likely to fail authentication due to interoperability or operational problems. Because DANE TLS relies on coordinated changes to DNS and SMTP server settings, the best choice of records to publish will depend on site-specific practices.
由于机会主义DANE TLS将由非交互式MTA使用，当身份验证失败时，用户无需“单击确定”，因此对等身份验证的可靠性至关重要。建议服务器运营商发布由于互操作性或操作问题导致身份验证失败的可能性最小的TLSA记录。由于DANE TLS依赖于对DNS和SMTP服务器设置的协调更改，因此发布记录的最佳选择将取决于特定于站点的做法。
The certificate usage element of a TLSA record plays a critical role in determining how the corresponding certificate association data field is used to authenticate a server's certificate chain. Sections 3.1.1 and 3.1.2 explain the process for certificate usages DANE-EE(3) and DANE-TA(2), respectively. Section 3.1.3 briefly explains why certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with opportunistic DANE TLS.
TLSA记录的certificate usage元素在确定如何使用相应的证书关联数据字段对服务器的证书链进行身份验证方面起着关键作用。第3.1.1节和第3.1.2节分别解释了DANE-EE（3）和DANE-TA（2）的证书使用流程。第3.1.3节简要解释了为什么证书使用PKIX-TA（0）和PKIX-EE（1）不适用于机会主义丹麦TLS。
In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second choice, depending on site needs. See Sections 3.1.1 and 3.1.2 for more details. Other combinations of TLSA parameters either (1) are explicitly unsupported or (2) offer little to recommend them over these two.
总之，我们建议根据现场需要，使用“DANE-EE（3）SPKI（1）SHA2-256（1）”和“DANE-TA（2）Cert（0）SHA2-256（1）”TLSA记录作为第二选择。详见第3.1.1节和第3.1.2节。TLSA参数的其他组合要么（1）明确不受支持，要么（2）与这两个参数相比，没有什么值得推荐的。
Authentication via certificate usage DANE-EE(3) TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.
通过证书使用DANE-EE（3）TLSA记录进行身份验证只需检查服务器的叶证书是否与TLSA记录匹配。特别是，服务器公钥与其名称的绑定完全基于TLSA记录关联。即使证书中的名称与服务器的客户端引用标识不匹配，也必须将服务器视为已验证。
The expiration date of the server certificate MUST be ignored: the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature.
必须忽略服务器证书的过期日期：TLSA记录密钥绑定的有效期由TLSA记录DNSSEC签名的有效间隔决定。
With DANE-EE(3), servers need not employ SNI (they may ignore the client's SNI message) even when the server is known under independent names that would otherwise require separate certificates. It is instead sufficient for the TLSA RRsets for all the domains in question to match the server's default certificate. Of course, with SMTP servers it is simpler still to publish the same MX hostname for all the hosted domains.
对于DANE-EE（3），服务器不需要使用SNI（它们可能会忽略客户端的SNI消息），即使服务器是以独立名称命名的，否则需要单独的证书。相反，所有相关域的TLSA RRSET都足以匹配服务器的默认证书。当然，对于SMTP服务器，为所有托管域发布相同的MX主机名更简单。
For domains where it is practical to make coordinated changes in DNS TLSA records during SMTP server key rotation, it is often best to publish end-entity DANE-EE(3) certificate associations. DANE-EE(3) certificates don't suddenly stop working when leaf or intermediate certificates expire, nor do they fail when the server operator neglects to configure all the required issuer certificates in the server certificate chain.
对于在SMTP服务器密钥轮换期间对DNS TLSA记录进行协调更改是可行的域，通常最好发布最终实体DANE-EE（3）证书关联。DANE-EE（3）证书不会在叶证书或中间证书过期时突然停止工作，也不会在服务器操作员忽略配置服务器证书链中所有必需的颁发者证书时失败。
TLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE implementations are required to support SHA2-256, this record type works for all clients and need not change across certificate renewals with the same key.
在大多数情况下，为SMTP服务器发布的TLSA记录应该是“DANE-EE（3）SPKI（1）SHA2-256（1）”记录。由于所有DANE实现都需要支持SHA2-256，因此此记录类型适用于所有客户端，并且不需要在使用相同密钥的证书续订期间更改。
Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing CA to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a trust anchor (TA) for the certificate chains of all relevant services. The TLSA query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example:
某些域可能希望避免为每个TLS服务发布唯一TLSA RRs的操作复杂性。如果域使用公共颁发CA为多个TLS服务创建证书，则将颁发机构发布为所有相关服务的证书链的信任锚（TA）可能更简单。然后，可以将同一TA发布的每个服务的TLSA查询域（带有端口和协议前缀标签的TLSA基本域）设置为CNAME别名，该别名指向与TA匹配的公共TLSA RRset。例如：
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
example.com. IN MX 0 mx1.example.com.
example.com. IN MX 0 mx2.example.com.
_25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
With usage DANE-TA(2), the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). The server MAY employ SNI to select the appropriate certificate to present to the client.
使用DANE-TA（2）时，服务器证书的名称必须与客户机的一个引用标识符相匹配（请参见[RFC6125]）。服务器可以使用SNI选择适当的证书以呈现给客户端。
SMTP servers that rely on certificate usage DANE-TA(2) TLSA records for TLS authentication MUST include the TA certificate as part of the certificate chain presented in the TLS handshake server certificate message even when it is a self-signed root certificate. Many SMTP servers are not configured with a comprehensive list of trust anchors, nor are they expected to be at any point in the future. Some MTAs will ignore all locally trusted certificates when processing usage DANE-TA(2) TLSA records. Thus, even when the TA happens to be a public CA known to the SMTP client, authentication is likely to fail unless the TA certificate is included in the TLS server certificate message.
依赖证书使用DANE-TA（2）TLSA记录进行TLS身份验证的SMTP服务器必须将TA证书作为证书链的一部分包含在TLS握手服务器证书消息中，即使它是自签名根证书。许多SMTP服务器都没有配置完整的信任锚列表，将来也不需要。某些MTA在处理使用情况DANE-TA（2）TLSA记录时将忽略所有本地受信任的证书。因此，即使TA恰好是SMTP客户端已知的公共CA，身份验证也可能失败，除非TA证书包含在TLS服务器证书消息中。
With some SMTP server software, it is not possible to configure the server to include self-signed (root) CA certificates in the server certificate chain. Such servers either MUST publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE-EE(3) TLSA records.
对于某些SMTP服务器软件，无法将服务器配置为在服务器证书链中包含自签名（根）CA证书。此类服务器必须为中间证书发布DANE-TA（2）记录，或者必须使用DANE-EE（3）TLSA记录。
TLSA records with a matching type of Full(0) are discouraged. While these potentially obviate the need to transmit the TA certificate in the TLS server certificate message, client implementations may not be able to augment the server certificate chain with the data obtained from DNS, especially when the TLSA record supplies a bare key (selector SPKI(1)). Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records
不鼓励匹配类型为Full（0）的TLSA记录。虽然这些可能消除了在TLS服务器证书消息中传输TA证书的需要，但客户端实现可能无法使用从DNS获得的数据来扩充服务器证书链，特别是当TLSA记录提供裸密钥时（选择器SPKI（1））。由于服务器在任何情况下都需要传输TA证书，因此服务器操作员应发布TLSA记录
with a matching type other than Full(0) and avoid potential interoperability issues with large TLSA records containing full certificates or keys.
使用非完整（0）的匹配类型，并避免与包含完整证书或密钥的大型TLSA记录的潜在互操作性问题。
TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0). Such TLSA records are associated with the whole trust anchor certificate, not just with the trust anchor public key. In particular, the SMTP client SHOULD then apply any relevant constraints from the trust anchor certificate, such as, for example, path length constraints.
使用DANE-TA（2）记录的TLSA发布者应使用证书选择器（0）发布记录。这样的TLSA记录与整个信任锚证书相关联，而不仅仅与信任锚公钥相关联。特别是，SMTP客户端应该应用来自信任锚证书的任何相关约束，例如路径长度约束。
While a selector of SPKI(1) may also be employed, the resulting TLSA record will not specify the full trust anchor certificate content, and elements of the trust anchor certificate other than the public key become mutable. This may, for example, allow a subsidiary CA to issue a chain that violates the trust anchor's path length or name constraints.
虽然也可以使用SPKI（1）的选择器，但生成的TLSA记录将不会指定完整的信任锚证书内容，并且除了公钥之外的信任锚证书的元素变得可变。例如，这可能允许子CA发布违反信任锚点的路径长度或名称约束的链。
Note that this section applies to MTA-to-MTA SMTP, which is normally on port 25 -- that is, to servers that are the SMTP servers for one or more destination domains. Other uses of SMTP, such as in MUA-to-MSA submission on ports 587 or 465, are out of scope for this document. Where those other uses also employ TLS opportunistically and/or depend on DNSSEC as a result of DNS-based discovery of service location, the relevant specifications should, as appropriate, arrive at similar conclusions.
请注意，本节适用于MTA到MTA SMTP（通常位于端口25上），也就是说，适用于作为一个或多个目标域的SMTP服务器的服务器。SMTP的其他用途，如端口587或465上的MUA到MSA提交，不在本文档的范围内。如果由于基于DNS的服务位置发现，这些其他用途也有机会使用TLS和/或依赖DNSSEC，则相关规范应酌情得出类似结论。
As noted in Sections 1.3.1 and 1.3.2, sending MTAs cannot, without relying on DNSSEC for "secure" MX records and DANE for STARTTLS support signaling, perform server identity verification or prevent STARTTLS downgrade attacks. The use of PKIX CAs offers no added security, since an attacker capable of compromising DNSSEC is free to replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient non-PKIX certificate usage. Finally, as explained in Section 1.3.4, there is no list of trusted CAs agreed upon by all MTAs and no user to "click OK" when a server's CA is not trusted by a client.
如第1.3.1节和第1.3.2节所述，如果不依赖DNSSEC的“安全”MX记录和DANE的STARTTLS支持信令，发送MTA无法执行服务器身份验证或防止STARTTLS降级攻击。使用PKIX CA不提供额外的安全性，因为能够破坏DNSSEC的攻击者可以自由地将任何PKIX-TA（0）或PKIX-EE（1）TLSA记录替换为包含任何方便的非PKIX证书用法的记录。最后，如第1.3.4节所述，没有所有MTA同意的受信任CA列表，当客户端不信任服务器的CA时，没有用户“单击确定”。
Therefore, TLSA records for the port 25 SMTP service used by client MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1). SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CAs. Lacking a complete set of public CAs, MTA clients would not be able to verify the certificates of SMTP servers whose issuing root CAs are not trusted by the client.
因此，客户端MTA使用的端口25 SMTP服务的TLSA记录不应包括证书使用PKIX-TA（0）或PKIX-EE（1）的TLSA RRs。SMTP客户端MTA不能配置为具有适当完整的受信任公共CA集。由于缺少一套完整的公共CA，MTA客户端将无法验证SMTP服务器的证书，这些服务器的颁发根CA不受客户端信任。
Opportunistic DANE TLS needs to interoperate without bilateral coordination of security settings between client and server systems. Therefore, parameter choices that are fragile in the absence of bilateral coordination are unsupported. Nothing is lost; since the PKIX certificate usages cannot aid SMTP TLS security, they can only impede SMTP TLS interoperability.
机会主义的DANE TLS需要在客户端和服务器系统之间不进行双边安全设置协调的情况下进行互操作。因此，不支持在缺乏双边协调的情况下脆弱的参数选择。什么都没有失去；由于PKIX证书的使用不能帮助SMTP TLS的安全性，它们只能阻碍SMTP TLS的互操作性。
SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other unsupported certificate usage, SMTP clients MAY treat such records as "unusable".
未定义证书使用PKIX-TA（0）或PKIX-EE（1）的TLSA RRs的SMTP客户端处理。与任何其他不受支持的证书使用一样，SMTP客户端可能会将此类记录视为“不可用”。
When at least one usable "secure" TLSA record is found, the SMTP client MUST use TLSA records to authenticate the SMTP server. Messages MUST NOT be delivered via the SMTP server if authentication fails; otherwise, the SMTP client is vulnerable to MITM attacks.
当至少找到一个可用的“安全”TLSA记录时，SMTP客户端必须使用TLSA记录对SMTP服务器进行身份验证。如果身份验证失败，则不得通过SMTP服务器传递邮件；否则，SMTP客户端容易受到MITM攻击。
The SMTP client MUST NOT perform certificate name checks with certificate usage DANE-EE(3) (Section 3.1.1).
SMTP客户端不得使用证书使用DANE-EE（3）（第3.1.1节）执行证书名称检查。
To match a server via a TLSA record with certificate usage DANE-TA(2), the client MUST perform name checks to ensure that it has reached the correct server. In all DANE-TA(2) cases, the SMTP client MUST employ the TLSA base domain as the primary reference identifier for matching the server certificate.
要通过TLSA记录将服务器与证书使用情况DANE-TA（2）相匹配，客户端必须执行名称检查以确保它已到达正确的服务器。在所有DANE-TA（2）情况下，SMTP客户端必须使用TLSA基本域作为匹配服务器证书的主要参考标识符。
TLSA records for MX hostnames: If the TLSA base domain was obtained indirectly via a "secure" MX lookup (including any CNAME-expanded name of an MX hostname), then the original next-hop domain used in the MX lookup MUST be included as a second reference identifier. The CNAME-expanded original next-hop domain MUST be included as a third reference identifier if different from the original next-hop domain. When the client MTA is employing DANE TLS security despite "insecure" MX redirection, the MX hostname is the only reference identifier.
MX主机名的TLSA记录：如果TLSA基本域是通过“安全”MX查找间接获得的（包括MX主机名的任何CNAME扩展名），则MX查找中使用的原始下一跳域必须包含为第二个参考标识符。如果CNAME扩展的原始下一跳域与原始下一跳域不同，则必须将其作为第三个参考标识符包括在内。尽管MX重定向“不安全”，但当客户端MTA使用DANE TLS安全性时，MX主机名是唯一的参考标识符。
TLSA records for non-MX hostnames: If MX records were not used (e.g., if none exist) and the TLSA base domain is the CNAME-expanded original next-hop domain, then the original next-hop domain MUST be included as a second reference identifier.
非MX主机名的TLSA记录：如果未使用MX记录（例如，如果不存在），并且TLSA基本域是CNAME扩展的原始下一跳域，则原始下一跳域必须作为第二个参考标识符包含。
Accepting certificates with the original next-hop domain in addition to the MX hostname allows a domain with multiple MX hostnames to field a single certificate bearing a single domain name (i.e., the email domain) across all the SMTP servers. This also aids interoperability with pre-DANE SMTP clients that are configured to look for the email domain name in server certificates -- for example, with "secure" DNS records as shown below:
除了MX主机名之外，接受具有原始下一跳域的证书允许具有多个MX主机名的域跨所有SMTP服务器输入具有单个域名（即电子邮件域）的单个证书。这也有助于与配置为在服务器证书中查找电子邮件域名的丹麦之前的SMTP客户端的互操作性，例如，与“安全”DNS记录的互操作性，如下所示：
exchange.example.org. IN CNAME mail.example.org.
mail.example.org. IN CNAME example.com.
example.com. IN MX 10 mx10.example.com.
example.com. IN MX 15 mx15.example.com.
example.com. IN MX 20 mx20.example.com.
;
mx10.example.com. IN A 192.0.2.10
_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
;
mx15.example.com. IN CNAME mxbackup.example.com.
mxbackup.example.com. IN A 192.0.2.15
; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
;
mx20.example.com. IN CNAME mxbackup.example.net.
mxbackup.example.net. IN A 198.51.100.20
_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
exchange.example.org. IN CNAME mail.example.org.
mail.example.org. IN CNAME example.com.
example.com. IN MX 10 mx10.example.com.
example.com. IN MX 15 mx15.example.com.
example.com. IN MX 20 mx20.example.com.
;
mx10.example.com. IN A 192.0.2.10
_25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
;
mx15.example.com. IN CNAME mxbackup.example.com.
mxbackup.example.com. IN A 192.0.2.15
; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
_25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
;
mx20.example.com. IN CNAME mxbackup.example.net.
mxbackup.example.net. IN A 198.51.100.20
_25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
Certificate name checks for delivery of mail to exchange.example.org via any of the associated SMTP servers MUST accept at least the names "exchange.example.org" and "example.com", which are, respectively, the original and fully expanded next-hop domain. When the SMTP server is mx10.example.com, name checks MUST accept the TLSA base domain "mx10.example.com". If, despite the fact that MX hostnames are required to not be aliases, the MTA supports delivery via "mx15.example.com" or "mx20.example.com", then name checks MUST accept the respective TLSA base domains "mx15.example.com" and "mxbackup.example.net".
通过任何关联SMTP服务器向exchange.example.org发送邮件的证书名称检查必须至少接受名称“exchange.example.org”和“example.com”，这两个名称分别是原始和完全扩展的下一跳域。当SMTP服务器为mx10.example.com时，名称检查必须接受TLSA基本域“mx10.example.com”。尽管MX主机名必须不是别名，但如果MTA支持通过“mx15.example.com”或“mx20.example.com”交付，则名称检查必须接受相应的TLSA基本域“mx15.example.com”和“mxbackup.example.net”。
When name checks are applicable (certificate usage DANE-TA(2)), if the server certificate contains a Subject Alternative Name extension [RFC5280] with at least one DNS-ID [RFC6125], then only the DNS-IDs are matched against the client's reference identifiers. The CN-ID [RFC6125] is only considered when no DNS-IDs are present. The server certificate is considered matched when one of its presented identifiers [RFC5280] matches any of the client's reference identifiers.
当名称检查适用时（证书使用DANE-TA（2）），如果服务器证书包含具有至少一个DNS-ID[RFC6125]的使用者替代名称扩展[RFC5280]，则只有DNS ID与客户端的参考标识符匹配。CN-ID[RFC6125]仅在不存在DNS ID时才被考虑。当服务器证书的一个标识符[RFC5280]与客户端的任何参考标识符匹配时，服务器证书被视为匹配。
Wildcards are valid in either DNS-IDs or the CN-ID when applicable. The wildcard character must be the entire first label of the DNS-ID or CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and "*smtp.example.com" are not. SMTP clients MUST support wildcards that match the first label of the reference identifier, with the remaining labels matching verbatim. For example, the DNS-ID "*.example.com" matches the reference identifier "mx1.example.com". SMTP clients MAY, subject to local policy, allow wildcards to match multiple reference identifier labels, but servers cannot expect broad support for such a policy. Therefore, any wildcards in server certificates SHOULD match exactly one label in either the TLSA base domain or the next-hop domain.
适用时，通配符在DNS ID或CN-ID中有效。通配符必须是DNS-ID或CN-ID的整个第一个标签。因此，“*.example.com”有效，而“smtp*.example.com”和“*smtp.example.com”无效。SMTP客户端必须支持与引用标识符的第一个标签匹配的通配符，其余标签与逐字匹配。例如，DNS-ID“*.example.com”与参考标识符“mx1.example.com”匹配。根据本地策略，SMTP客户端可能允许通配符匹配多个引用标识符标签，但服务器不能期望此类策略得到广泛支持。因此，服务器证书中的任何通配符都应该与TLSA基本域或下一跳域中的一个标签完全匹配。
Two TLSA records MUST be published before employing a new EE or TA public key or certificate: one matching the currently deployed key and the other matching the new key scheduled to replace it. Once sufficient time has elapsed for all DNS caches to expire the previous TLSA RRset and related signature RRsets, servers may be configured to use the new EE private key and associated public key certificate or may employ certificates signed by the new trust anchor.
在使用新的EE或TA公钥或证书之前，必须发布两个TLSA记录：一个匹配当前部署的密钥，另一个匹配计划替换的新密钥。一旦经过足够的时间使所有DNS缓存使以前的TLSA RRset和相关签名RRset过期，服务器可以配置为使用新的EE私钥和相关公钥证书，或者可以使用由新的信任锚签名的证书。
Once the new public key or certificate is in use, the TLSA RR that matches the retired key can be removed from DNS, leaving only RRs that match keys or certificates in active use.
使用新公钥或证书后，可以从DNS中删除与失效密钥匹配的TLSA RR，只保留与密钥或证书匹配的RRs处于活动使用状态。
As described in Section 3.1.2, when server certificates are validated via a DANE-TA(2) trust anchor and CNAME records are employed to store the TA association data at a single location, the responsibility of updating the TLSA RRset shifts to the operator of the trust anchor. Before a new trust anchor is used to sign any new server certificates, its certificate (digest) is added to the relevant TLSA RRset. After enough time elapses for the original TLSA RRset to age out of DNS caches, the new trust anchor can start issuing new server certificates. Once all certificates issued under the previous trust anchor have expired, its associated RRs can be removed from the TLSA RRset.
如第3.1.2节所述，当通过DANE-TA（2）信任锚验证服务器证书并使用CNAME记录在单个位置存储TA关联数据时，更新TLSA RRset的责任转移到信任锚的操作员。在使用新的信任锚点签署任何新的服务器证书之前，其证书（摘要）将添加到相关的TLSA RRset。在经过足够的时间使原始TLSA RRset从DNS缓存中过期后，新的信任锚可以开始颁发新的服务器证书。在前一个信任锚点下颁发的所有证书过期后，可以从TLSA RRs集中删除其关联的RRs。
In the DANE-TA(2) key management model, server operators do not generally need to update DNS TLSA records after initially creating a CNAME record that references the centrally operated DANE-TA(2) RRset. If a particular server's key is compromised, its TLSA CNAME SHOULD be replaced with a DANE-EE(3) association until the certificate for the compromised key expires, at which point it can return to using a CNAME record. If the central trust anchor is compromised, all
在DANE-TA（2）密钥管理模型中，服务器运营商通常不需要在最初创建引用集中操作的DANE-TA（2）RRset的CNAME记录后更新DNS TLSA记录。如果某个特定服务器的密钥被泄露，其TLSA CNAME应替换为DANE-EE（3）关联，直到泄露密钥的证书过期，此时它可以返回使用CNAME记录。如果中央信任锚受损，则所有
servers need to be issued new keys by a new TA, and an updated DANE-TA(2) TLSA RRset needs to be published containing just the new TA.
服务器需要由新TA颁发新密钥，并且需要发布仅包含新TA的更新DANE-TA（2）TLSA RRset。
SMTP servers cannot expect broad Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) support from SMTP clients. As outlined above, with DANE, compromised server or trust anchor keys can be "revoked" by removing them from the DNS without the need for client-side support for OCSP or CRLs.
SMTP服务器无法从SMTP客户端获得广泛证书吊销列表（CRL）或联机证书状态协议（OCSP）支持。如上所述，使用DANE，可以通过从DNS中删除受损的服务器或信任锚密钥来“撤销”，而无需客户端支持OCSP或CRL。
While [RFC6698] specifies multiple digest algorithms, it does not specify a protocol by which the SMTP client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol would allow the client and server to avoid exposure to deprecated weaker algorithms that are published for compatibility with less capable clients. When stronger algorithms are an option, deprecated algorithms SHOULD be avoided. Such a protocol is specified in [RFC7671]. SMTP clients and servers that implement this specification MUST comply with the requirements outlined in Section 9 of [RFC7671].
虽然[RFC6698]指定了多个摘要算法，但它没有指定SMTP客户端和TLSA记录发布者可以就最强的共享算法达成一致的协议。这样的协议将允许客户端和服务器避免暴露于不推荐的较弱算法中，这些算法是为了与能力较差的客户端兼容而发布的。当选择更强的算法时，应避免使用不推荐的算法。[RFC7671]中规定了此类协议。实现本规范的SMTP客户端和服务器必须符合[RFC7671]第9节中概述的要求。
An MTA implementing this protocol may require a stronger security assurance when sending email to selected destinations. The sending organization may need to send sensitive email and/or may have regulatory obligations to protect its content. This protocol is not in conflict with such a requirement and, in fact, can often simplify authenticated delivery to such destinations.
实现此协议的MTA在向选定目标发送电子邮件时可能需要更强大的安全保证。发送组织可能需要发送敏感电子邮件和/或可能有保护其内容的监管义务。该协议与这样的要求并不冲突，事实上，通常可以简化到这些目的地的经过身份验证的交付。
Specifically, with domains that publish DANE TLSA records for their MX hostnames, a sending MTA can be configured to use the receiving domain's DANE TLSA records to authenticate the corresponding SMTP server. Authentication via DANE TLSA records is easier to manage, as changes in the receiver's expected certificate properties are made on the receiver end and don't require manually communicated configuration changes. With mandatory DANE TLS, when no usable TLSA records are found, message delivery is delayed. Thus, mail is only sent when an authenticated TLS channel is established to the remote SMTP server.
具体而言，对于为其MX主机名发布DANE TLSA记录的域，可以将发送MTA配置为使用接收域的DANE TLSA记录对相应的SMTP服务器进行身份验证。通过DANE TLSA记录进行身份验证更易于管理，因为接收方的预期证书属性的更改是在接收方端进行的，不需要手动进行配置更改。对于强制的DANE TLS，当找不到可用的TLSA记录时，消息传递会延迟。因此，只有在向远程SMTP服务器建立经过身份验证的TLS通道时，才会发送邮件。
Administrators of mail servers that employ mandatory DANE TLS need to carefully monitor their mail logs and queues. If a partner domain unwittingly misconfigures its TLSA records, disables DNSSEC, or misconfigures SMTP server certificate chains, mail will be delayed and may bounce if the issue is not resolved in a timely manner.
使用强制DANE TLS的邮件服务器的管理员需要仔细监视其邮件日志和队列。如果合作伙伴域无意中错误配置其TLSA记录、禁用DNSSEC或错误配置SMTP服务器证书链，则邮件将被延迟，如果问题未及时解决，邮件可能会反弹。
We note that SMTP is also used between Message User Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In [RFC6186], a protocol is specified that enables an MUA to dynamically locate the MSA based on the user's email address. SMTP connection security considerations for MUAs implementing [RFC6186] are largely analogous to connection security requirements for MTAs, and this specification could be applied largely verbatim with DNS MX records replaced by corresponding DNS Service (SRV) records [RFC7673].
我们注意到，SMTP也用于消息用户代理（MUA）和消息提交代理（MSA）[RFC6409]。在[RFC6186]中，指定了一种协议，使MUA能够根据用户的电子邮件地址动态定位MSA。实现[RFC6186]的MUA的SMTP连接安全注意事项在很大程度上类似于MTA的连接安全要求，本规范可以在很大程度上逐字应用，DNS MX记录被相应的DNS服务（SRV）记录所取代[RFC7673]。
However, until MUAs begin to adopt the dynamic configuration mechanisms of [RFC6186], they are adequately served by more traditional static TLS security policies. Specification of DANE TLS for MUA-to-MSA SMTP is left to future documents that focus specifically on SMTP security between MUAs and MSAs.
然而，在MUA开始采用[RFC6186]的动态配置机制之前，更多传统的静态TLS安全策略足以为其提供服务。针对MUA到MSA SMTP的DANE TLS规范将留待将来的文档专门关注MUA和MSA之间的SMTP安全性。
To ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain. This precludes the use of the Secure Socket Layer (SSL) HELLO that is SSL 2.0 compatible by the SMTP client.
为确保服务器发送正确的证书链，SMTP客户端必须发送包含TLSA基本域的TLS SNI扩展。这排除了SMTP客户端使用与SSL 2.0兼容的安全套接字层（SSL）HELLO。
Each SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records. The server MAY rely on SNI to determine which certificate chain to present to the client. Clients that don't send SNI information may not see the expected certificate chain.
每个SMTP服务器必须提供一个证书链（请参阅[RFC5246]，第7.4.2节），该证书链至少与一个TLSA记录匹配。服务器可能依赖SNI来确定向客户机提供哪个证书链。不发送SNI信息的客户端可能看不到预期的证书链。
If the server's TLSA records match the server's default certificate chain, the server need not support SNI. In either case, the server need not include the SNI extension in its TLS HELLO, as simply returning a matching certificate chain is sufficient. 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 domain, the server MUST simply send some fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that DANE TLS clients are 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 acceptable to the client, e.g., the original next-hop domain.
如果服务器的TLSA记录与服务器的默认证书链匹配，则服务器不需要支持SNI。无论哪种情况，服务器都不需要在其TLS HELLO中包含SNI扩展，因为只需返回匹配的证书链就足够了。服务器不得强制客户端使用SNI，因为客户端可能正在使用未经验证的机会主义TL，并且可能不希望服务器提供任何特定证书。如果客户端不发送SNI扩展或为不受支持的域发送SNI扩展，则服务器必须只发送其选择的一些回退证书链。不强制严格匹配请求的SNI主机名的原因是，DANE TLS客户端通常愿意接受多个服务器名称，但只能在SNI扩展中发送一个名称。服务器的回退证书可能与客户端可接受的不同名称相匹配，例如，原始下一跳域。
Since many SMTP servers either do not support or do not enable any anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD offer to negotiate a typical set of non-anonymous cipher suites required for interoperability with such servers. An SMTP client employing pre-DANE opportunistic TLS MAY also include one or more anonymous TLS cipher suites in its TLS HELLO. SMTP servers that need to interoperate with opportunistic TLS clients SHOULD be prepared to interoperate with such clients by either always selecting a mutually supported non-anonymous cipher suite or correctly handling client connections that negotiate anonymous cipher suites.
由于许多SMTP服务器不支持或不启用任何匿名TLS密码套件，SMTP客户端TLS HELLO messages应提供协商与此类服务器互操作性所需的一组典型非匿名密码套件。采用前丹麦投机性TLS的SMTP客户端也可能在其TLS HELLO中包含一个或多个匿名TLS密码套件。需要与投机取巧的TLS客户端进行互操作的SMTP服务器应准备好与此类客户端进行互操作，方法是始终选择相互支持的非匿名密码套件或正确处理协商匿名密码套件的客户端连接。
Note that while SMTP server operators are under no obligation to enable anonymous cipher suites, no security is gained by sending certificates to clients that will ignore them. Indeed, support for anonymous cipher suites in the server makes audit trails more informative. Log entries that record connections that employed an anonymous cipher suite record the fact that the clients did not care to authenticate the server.
请注意，虽然SMTP服务器操作员没有义务启用匿名密码套件，但向将忽略它们的客户端发送证书不会获得安全性。事实上，服务器中对匿名密码套件的支持使审计跟踪信息更加丰富。记录使用匿名密码套件的连接的日志条目记录客户端不关心服务器身份验证的事实。
An operational error on the sending or receiving side that cannot be corrected in a timely manner may, at times, lead to consistent failure to deliver time-sensitive email. The sending MTA administrator may have to choose between allowing email to queue until the error is resolved and disabling opportunistic or mandatory DANE TLS (Section 6) for one or more destinations. The choice to disable DANE TLS security should not be made lightly. Every reasonable effort should be made to determine that problems with mail delivery are the result of an operational error and not an attack. A fallback strategy may be to configure explicit out-of-band TLS security settings if supported by the sending MTA.
发送或接收端的操作错误无法及时纠正，有时可能导致发送时间敏感电子邮件的持续失败。发送MTA的管理员可能必须在允许电子邮件排队直到错误得到解决和禁用一个或多个目的地的机会性或强制性DANE TLS（第6节）之间做出选择。不应轻易选择禁用DANE TLS安全性。应尽一切合理努力确定邮件传递问题是操作错误而不是攻击造成的。如果发送MTA支持，回退策略可能是配置显式带外TLS安全设置。
SMTP clients may deploy opportunistic DANE TLS incrementally by enabling it only for selected sites or may occasionally need to disable opportunistic DANE TLS for peers that fail to interoperate due to misconfiguration or software defects on either end. Some implementations MAY support DANE TLS in an "audit only" mode in which failure to achieve the requisite security level is logged as a warning and delivery proceeds at a reduced security level. Unless local policy specifies "audit only" or specifies that opportunistic DANE TLS is not to be used for a particular destination, an SMTP
SMTP客户端可以通过仅为选定站点启用Opportunity DANE TLS来增量部署Opportunity DANE TLS，或者可能偶尔需要为由于配置错误或两端软件缺陷而无法互操作的对等方禁用Opportunity DANE TLS。一些实现可能以“仅审核”模式支持DANE TLS，在这种模式下，未达到必要的安全级别将被记录为警告，并以降低的安全级别进行交付。除非本地策略指定“仅审核”或指定投机性DANE TLS不用于特定目标，否则SMTP
client MUST NOT deliver mail via a server whose certificate chain fails to match at least one TLSA record when usable TLSA records are found for that server.
当为服务器找到可用的TLSA记录时，客户端不得通过证书链与至少一个TLSA记录不匹配的服务器传递邮件。
Some MTAs enable STARTTLS selectively. For example, they might only support STARTTLS with clients that have previously demonstrated "proper MTA behavior", e.g., by retrying the delivery of deferred messages (greylisting). If such an MTA publishes DANE TLSA records, sending MTAs that implement this specification will not attempt the initial cleartext SMTP transaction needed to establish the "proper MTA behavior", because they cannot establish the required channel security. Server operators MUST NOT implement selective STARTTLS if they also want to support DANE TLSA.
有些MTA选择性地启用STARTTLS。例如，他们可能只支持StartTL，其客户端以前已经证明“正确的MTA行为”，例如，通过重试延迟消息的传递（greylisting）。如果此类MTA发布DANE TLSA记录，则发送实现此规范的MTA将不会尝试建立“正确MTA行为”所需的初始明文SMTP事务，因为它们无法建立所需的通道安全性。如果服务器运营商也想支持DANE TLSA，则不得实施选择性STARTTLS。
TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].
TLSA出版商必须遵守[RFC7671]第8节中的指南。
TLSA Publishers SHOULD follow the TLSA publication size guidance found in Section 10.1 of [RFC7671].
TLSA出版商应遵循[RFC7671]第10.1节中的TLSA出版物大小指南。
TLSA Publishers SHOULD follow the TLSA record TTL and signature lifetime recommendations found in Section 13 of [RFC7671].
TLSA发布者应遵循[RFC7671]第13节中的TLSA记录TTL和签名寿命建议。
This protocol leverages DANE TLSA records to implement MITM-resistant Opportunistic Security [RFC7435] for SMTP. For destination domains that sign their MX records and publish signed TLSA records for their MX hostnames, this protocol allows sending MTAs to securely discover both the availability of TLS and how to authenticate the destination.
该协议利用DANE TLSA记录为SMTP实现抗MITM的机会主义安全[RFC7435]。对于签署其MX记录并发布其MX主机名的已签署TLSA记录的目标域，此协议允许发送MTA以安全地发现TLS的可用性以及如何验证目标。
This protocol does not aim to secure all SMTP traffic, as that is not practical until DNSSEC and DANE adoption are universal. The incremental deployment provided by following this specification is a best possible path for securing SMTP. This protocol coexists and interoperates with the existing insecure Internet email backbone.
该协议并不旨在保护所有SMTP通信，因为在DNSSEC和DANE普及之前，这是不实际的。遵循此规范提供的增量部署是保护SMTP的最佳路径。此协议与现有不安全的Internet电子邮件主干共存并互操作。
The protocol does not preclude existing non-opportunistic SMTP TLS security arrangements, which can continue to be used as before via manual configuration with negotiated out-of-band key and TLS configuration exchanges.
该协议不排除现有的非机会主义SMTP TLS安全安排，该安排可以通过协商带外密钥和TLS配置交换的手动配置继续使用。
Opportunistic SMTP TLS depends critically on DNSSEC for downgrade resistance and secure resolution of the destination name. If DNSSEC is compromised, it is not possible to fall back on the public CA PKI to prevent MITM attacks. A successful breach of DNSSEC enables the attacker to publish TLSA usage 3 certificate associations and thereby
机会主义SMTP TLS在抗降级和安全解析目标名称方面严重依赖DNSSEC。如果DNSSEC遭到破坏，则不可能依靠公共CA PKI来防止MITM攻击。成功违反DNSSEC使攻击者能够发布TLSA用法3证书关联，从而
bypass any security benefit the legitimate domain owner might hope to gain by publishing usage 0 or usage 1 TLSA RRs. Given the lack of public CA PKI support in existing MTA deployments, avoiding certificate usages 0 and 1 simplifies implementation and deployment with no adverse security consequences.
绕过合法域所有者可能希望通过发布使用0或使用1 TLSA RRs获得的任何安全好处。鉴于现有MTA部署中缺少公共CA PKI支持，避免证书使用0和1简化了实施和部署，而不会产生不利的安全后果。
Implementations must strictly follow Sections 2.1.2, 2.1.3, 2.2, 2.2.1, 2.2.2, 2.2.3, 3.2, and 9.1 of this specification; these sections indicate when it is appropriate to initiate a non-authenticated connection or cleartext connection to an SMTP server. Specifically, in order to prevent downgrade attacks on this protocol, implementations must not initiate a connection when this specification indicates that a particular SMTP server must be considered unreachable.
实施必须严格遵守本规范第2.1.2、2.1.3、2.2、2.2.1、2.2.2、2.2.3、3.2和9.1节；这些部分指出何时适合启动到SMTP服务器的未经身份验证的连接或明文连接。具体来说，为了防止对该协议的降级攻击，当该规范指示必须将特定SMTP服务器视为无法访问时，实现不得启动连接。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<http://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，DOI 10.17487/RFC3207，2002年2月<http://www.rfc-editor.org/info/rfc3207>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<http://www.rfc-editor.org/info/rfc5598>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://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, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <http://www.rfc-editor.org/info/rfc6186>.
[RFC6186]Daboo，C.“使用SRV记录查找电子邮件提交/访问服务”，RFC 6186，DOI 10.17487/RFC6186，2011年3月<http://www.rfc-editor.org/info/rfc6186>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.
[RFC6672]Rose，S.和W.Wijngaards，“DNS中的DNAME重定向”，RFC 6672，DOI 10.17487/RFC6672，2012年6月<http://www.rfc-editor.org/info/rfc6672>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.
[RFC7218]Gudmundsson，O.，“添加首字母缩略词以简化有关基于DNS的命名实体身份验证（DANE）的对话”，RFC 7218，DOI 10.17487/RFC7218，2014年4月<http://www.rfc-editor.org/info/rfc7218>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <http://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<http://www.rfc-editor.org/info/rfc7671>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 2136，DOI 10.17487/RFC2136，1997年4月<http://www.rfc-editor.org/info/rfc2136>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，DOI 10.17487/RFC2181，1997年7月<http://www.rfc-editor.org/info/rfc2181>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>.
[RFC6409]Gellens，R.和J.Klensin，“邮件的邮件提交”，STD 72，RFC 6409，DOI 10.17487/RFC6409，2011年11月<http://www.rfc-editor.org/info/rfc6409>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.
[RFC7673]Finch，T.，Miller，M.，和P.Saint Andre，“使用基于DNS的认证命名实体（丹麦）TLSA记录和SRV记录”，RFC 7673，DOI 10.17487/RFC7673，2015年10月<http://www.rfc-editor.org/info/rfc7673>.
Acknowledgements
致谢
The authors would like to extend great thanks to Tony Finch, who started the original version of a DANE SMTP document. His work is greatly appreciated and has been incorporated into this document. The authors would like to additionally thank Phil Pennock for his comments and advice on this document.
作者非常感谢Tony Finch，他创建了丹麦SMTP文档的原始版本。他的工作深受赞赏，并已纳入本文件。作者还要感谢Phil Pennock对本文件的评论和建议。
Acknowledgements from Viktor: Thanks to Paul Hoffman, who motivated me to begin work on this memo and provided feedback on early draft versions of this document. Thanks to Patrick Koetter, Perry Metzger, and Nico Williams for valuable review comments. Thanks also to Wietse Venema, who created Postfix, and whose advice and feedback were essential to the development of the Postfix DANE implementation.
维克多致谢：感谢保罗·霍夫曼，他激励我开始编写这份备忘录，并就这份文件的早期草稿提供了反馈。感谢Patrick Koetter、Perry Metzger和Nico Williams的宝贵评论。还要感谢创建Postfix的Wietse Venema，他的建议和反馈对于Postfix DANE实现的开发至关重要。
Authors' Addresses
作者地址
Viktor Dukhovni Two Sigma
维克多·杜霍夫尼二西格玛
Email: ietf-dane@dukhovni.org
Email: ietf-dane@dukhovni.org
Wes Hardaker Parsons P.O. Box 382 Davis, CA 95617 United States
美国加利福尼亚州戴维斯市韦斯·哈达克·帕森斯邮政信箱382号，邮编95617
Email: ietf@hardakers.net
Email: ietf@hardakers.net