Internet Engineering Task Force (IETF) D. Margolis
Request for Comments: 8460 Google, Inc.
Category: Standards Track A. Brotman
ISSN: 2070-1721 Comcast, Inc.
B. Ramakrishnan
Oath, Inc.
J. Jones
Microsoft, Inc.
M. Risher
Google, Inc.
September 2018
Internet Engineering Task Force (IETF) D. Margolis
Request for Comments: 8460 Google, Inc.
Category: Standards Track A. Brotman
ISSN: 2070-1721 Comcast, Inc.
B. Ramakrishnan
Oath, Inc.
J. Jones
Microsoft, Inc.
M. Risher
Google, Inc.
September 2018
SMTP TLS Reporting
SMTP TLS报告
Abstract
摘要
A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.
有许多协议用于在SMTP邮件传输代理（MTA）之间建立加密通道，包括STARTTLS、基于DNS的命名实体身份验证（DANE）TLSA和MTA严格传输安全（MTA-STS）。由于配置错误或主动攻击，这些协议可能会失败，从而导致无法传递消息或通过未加密或未经验证的通道传递消息。本文档描述了一种报告机制和格式，通过这种机制和格式，发送系统可以与收件人域共享有关潜在故障的统计信息和特定信息。然后，收件人域可以使用此信息检测潜在的攻击和诊断无意的错误配置。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8460.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8460.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 8
3.1.1. Report Using MAILTO . . . . . . . . . . . . . . . . . 8
3.1.2. Report Using HTTPS . . . . . . . . . . . . . . . . . 8
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Report Time Frame . . . . . . . . . . . . . . . . . . . . 9
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 10
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 11
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 12
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 12
4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 15
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 16
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 19
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 19
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 20
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 22
6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 23
6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 24
6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 32
A.1. Report Using MAILTO . . . . . . . . . . . . . . . . . . . 32
A.2. Report Using HTTPS . . . . . . . . . . . . . . . . . . . 32
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 5
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 8
3.1.1. Report Using MAILTO . . . . . . . . . . . . . . . . . 8
3.1.2. Report Using HTTPS . . . . . . . . . . . . . . . . . 8
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Report Time Frame . . . . . . . . . . . . . . . . . . . . 9
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 10
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 10
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 10
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 11
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 11
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 12
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 12
4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 15
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 16
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 17
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 19
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 19
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 20
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Message Headers . . . . . . . . . . . . . . . . . . . . . 20
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. +gzip Media Type Suffix . . . . . . . . . . . . . . . . . 22
6.4. application/tlsrpt+json Media Type . . . . . . . . . . . 23
6.5. application/tlsrpt+gzip Media Type . . . . . . . . . . . 24
6.6. STARTTLS Validation Result Types . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 32
A.1. Report Using MAILTO . . . . . . . . . . . . . . . . . . . 32
A.2. Report Using HTTPS . . . . . . . . . . . . . . . . . . . 32
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 32
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. The protocol design uses an approach that has come to be known as "Opportunistic Security" (OS) [RFC7435]. This method maintains interoperability with clients that do not support STARTTLS, but it means that any attacker could potentially eavesdrop on a session. An attacker could perform a downgrade or interception attack by deleting parts of the SMTP session (such as the "250 STARTTLS" response) or redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain).
SMTP[RFC3207]的STARTTLS扩展允许SMTP客户端和主机通过TLS建立安全的SMTP会话。协议设计使用了一种被称为“机会主义安全”（OS）[RFC7435]的方法。此方法保持与不支持STARTTLS的客户端的互操作性，但这意味着任何攻击者都可能窃听会话。攻击者可以通过删除部分SMTP会话（如“250 STARTTLS”响应）或重定向整个SMTP会话（可能通过覆盖传递域的已解析MX记录）来执行降级或拦截攻击。
Because such "downgrade attacks" are not necessarily apparent to the receiving MTA, this document defines a mechanism for sending domains to report on failures at multiple stages of the MTA-to-MTA conversation.
由于此类“降级攻击”对接收MTA来说不一定明显，因此本文档定义了一种机制，用于向域发送MTA到MTA对话多个阶段的失败报告。
Recipient domains may also use the mechanisms defined by MTA-STS [RFC8461] or DANE [RFC6698] to publish additional encryption and authentication requirements; this document defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains.
收件人域也可以使用MTA-STS[RFC8461]或DANE[RFC6698]定义的机制发布额外的加密和身份验证要求；本文档定义了一种机制，用于发送与MTA-STS或DANE兼容的域，以便与收件人域共享成功和失败统计信息。
Specifically, this document defines a reporting schema that covers failures in routing, DNS resolution, and STARTTLS negotiation; policy validation errors for both DANE [RFC6698] and MTA-STS [RFC8461]; and a standard TXT record that recipient domains can use to indicate where reports in this format should be sent. The report can also serve as a heartbeat to indicate that systems are successfully negotiating TLS during sessions as expected.
具体而言，本文档定义了一个报告模式，涵盖路由、DNS解析和STARTTLS协商中的故障；DANE[RFC6698]和MTA-STS[RFC8461]的策略验证错误；以及一个标准的TXT记录，收件人域可以使用该记录指示应将此格式的报告发送到何处。该报告还可以作为心跳信号，指示系统正在按照预期在会话期间成功协商TLS。
This document is intended as a companion to the specification for SMTP MTA-STS [RFC8461] and adds reporting abilities for those implementing DANE [RFC7672].
本文档旨在作为SMTP MTA-STS[RFC8461]规范的补充，并为实现DANE[RFC7672]的人员添加报告功能。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
We also define the following terms for further use in this document:
我们还定义了以下术语，以便在本文件中进一步使用：
o MTA-STS Policy: A mechanism by which administrators can specify the expected TLS availability, presented identity, and desired actions for a given email recipient domain. MTA-STS is defined in [RFC8461].
o MTA-STS策略：管理员可以通过该机制为给定电子邮件收件人域指定预期的TLS可用性、显示的标识和所需的操作。MTA-STS在[RFC8461]中定义。
o DANE Policy: A mechanism by which administrators can use DNSSEC to commit an MTA to support STARTTLS and to publish criteria to be used to validate its presented certificates. DANE for SMTP is defined in [RFC7672], with the base specification defined in [RFC6698] (and updated by [RFC7671]).
o DANE策略：管理员可以使用DNSSEC提交MTA以支持STARTTLS并发布用于验证其提供的证书的条件的机制。用于SMTP的DANE在[RFC7672]中定义，基本规范在[RFC6698]中定义（并由[RFC7671]更新）。
o TLSRPT (TLS Reporting) Policy: A policy specifying the endpoint to which Sending MTAs should deliver reports.
o TLSRPT（TLS报告）策略：指定发送MTA应向其传递报告的端点的策略。
o Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a DANE policy is defined. For TLSRPT and MTA-STS, this is typically the same as the envelope recipient domain [RFC5321], but when mail is routed to a "smarthost" gateway by local policy, the "smarthost" domain name is used instead. For DANE, the Policy Domain is the "TLSA base domain" of the receiving SMTP server as described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698.
o 策略域：定义TLSRPT、MTA-STS或DANE策略的域。对于TLSRPT和MTA-STS，这通常与信封收件人域[RFC5321]相同，但当邮件通过本地策略路由到“smarthost”网关时，将使用“smarthost”域名。对于DANE，策略域是接收SMTP服务器的“TLSA基本域”，如RFC 7672第2.2.3节和RFC 6698第3节所述。
o Sending MTA: The MTA initiating the relay of an email message.
o 发送MTA：启动电子邮件中继的MTA。
o Aggregate Report URI (rua): A comma-separated list of locations where the report is to be submitted.
o 聚合报告URI（rua）：以逗号分隔的报告提交位置列表。
o ABNF: Augmented Backus-Naur Form, a syntax for formally specifying syntax, defined in [RFC5234] and [RFC7405].
o ABNF:Augmented Backus Naur Form，一种正式指定语法的语法，在[RFC5234]和[RFC7405]中定义。
o This document is intended as a companion to the specification for SMTP MTA-STS [RFC8461].
o 本文档旨在作为SMTP MTA-STS[RFC8461]规范的配套文件。
o SMTP TLSRPT defines a mechanism for sending domains that are compatible with MTA-STS or DANE to share success and failure statistics with recipient domains. DANE is defined in [RFC6698], and MTA-STS is defined in [RFC8461].
o SMTP TLSRPT定义了一种机制，用于发送与MTA-STS或DANE兼容的域，以便与收件人域共享成功和失败统计信息。丹麦定义见[RFC6698]，MTA-STS定义见[RFC8461]。
A domain publishes a record to its DNS indicating that it wishes to receive reports. These SMTP TLSRPT policies are distributed via DNS from the Policy Domain's zone as TXT records (similar to Domain-based Message Authentication, Reporting, and Conformance (DMARC) policies) under the name "_smtp._tls". For example, for the Policy Domain "example.com", the recipient's TLSRPT policy can be retrieved from "_smtp._tls.example.com".
域向其DNS发布一条记录，表明它希望接收报告。这些SMTP TLSRPT策略通过DNS从策略域的区域作为TXT记录（类似于基于域的邮件身份验证、报告和一致性（DMARC）策略）以“\u SMTP.\u tls”的名义分发。例如，对于策略域“example.com”，可以从“\u smtp.\u tls.example.com”检索收件人的TLSRPT策略。
Policies consist of the following directives:
政策由以下指令组成：
o "v": This document defines version 1 of TLSRPT, for which this value MUST be equal to "TLSRPTv1". Other versions may be defined in later documents.
o “v”：本文件定义了TLSRPT的版本1，该值必须等于“TLSRPTv1”。其他版本可在以后的文档中定义。
o "rua": A URI specifying the endpoint to which aggregate information about policy validation results should be sent (see Section 4, "Reporting Schema", for more information). Two URI schemes are supported: "mailto" and "https". As with DMARC [RFC7489], the Policy Domain can specify a comma-separated list of URIs.
o “rua”：一个URI，指定应向其发送有关策略验证结果的聚合信息的端点（有关更多信息，请参阅第4节“报告模式”）。支持两种URI方案：“mailto”和“https”。与DMARC[RFC7489]一样，策略域可以指定以逗号分隔的URI列表。
o In the case of "https", reports should be submitted via POST [RFC7231] to the specified URI. Report submitters MAY ignore certificate validation errors when submitting reports via HTTPS POST.
o 对于“https”，应通过POST[RFC7231]将报告提交到指定的URI。当通过HTTPS POST提交报告时，报告提交者可能会忽略证书验证错误。
o In the case of "mailto", reports should be submitted to the specified email address [RFC6068]. When sending failure reports via SMTP, Sending MTAs MUST deliver reports despite any TLS-related failures and SHOULD NOT include this SMTP session in the next report. This may mean that the reports are delivered unencrypted. Reports sent via SMTP MUST contain a valid DomainKeys Identified Mail (DKIM) [RFC6376] signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient. DKIM signatures MUST NOT use the "l=" attribute to limit the body length used in the signature. This ensures attackers cannot append extraneous or misleading data to a report without breaking the signature. The DKIM TXT record SHOULD contain the appropriate service type declaration, "s=tlsrpt". If not present, the receiving system MAY ignore reports lacking that service type.
o 如果是“mailto”，则应将报告提交至指定的电子邮件地址[RFC6068]。通过SMTP发送失败报告时，发送MTA必须在任何TLS相关失败的情况下发送报告，并且不应在下一个报告中包含此SMTP会话。这可能意味着报告是未加密的。通过SMTP发送的报告必须包含报告域指定的有效域密钥邮件（DKIM）[RFC6376]签名。收件人必须忽略缺少此类签名的报告。DKIM签名不得使用“l=”属性来限制签名中使用的正文长度。这确保攻击者在不破坏签名的情况下，无法将无关或误导性数据附加到报告中。DKIM TXT记录应包含适当的服务类型声明“s=tlsrpt”。如果不存在，接收系统可能会忽略缺少该服务类型的报告。
Sample DKIM record:
DKIM记录样本：
dkim_selector._domainkey.example.com TXT
"v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="
dkim_selector._domainkey.example.com TXT
"v=DKIM1;k=rsa;s=tlsrpt;p=Mlf4qwSZfase4fa=="
The formal definition of the "_smtp._tls" TXT record, defined using [RFC5234] and [RFC7405], is as follows:
使用[RFC5234]和[RFC7405]定义的“_smtp._tls”TXT记录的正式定义如下：
tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) [field-delim]
tlsrpt记录=tlsrpt版本1*（字段delim tlsrpt字段）[字段delim]
field-delim = *WSP ";" *WSP
field-delim = *WSP ";" *WSP
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-extension ; tlsrpt-rua record is ; required.
tlsrpt字段=tlsrpt rua/；注意，tlsrpt扩展；tlsrpt rua记录为：；必修的。
tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C), exclamation
; points (ASCII 0x21), and semicolons
; (ASCII 0x3B) MUST be encoded
tlsrpt-uri = URI
; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C), exclamation
; points (ASCII 0x21), and semicolons
; (ASCII 0x3B) MUST be encoded
tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt扩展名=tlsrpt外部名称“=”tlsrpt外部值
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
DIGIT / "_" / "-" / ".")
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
DIGIT / "_" / "-" / ".")
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control
; chars
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control
; chars
If multiple TXT records for "_smtp._tls" are returned by the resolver, records that do not begin with "v=TLSRPTv1;" are discarded. If the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT. If the resulting TXT record contains multiple strings (as described in Section 3.3 of [RFC7208]), then the record MUST be treated as if those strings are concatenated without adding spaces.
如果解析程序返回多个“\u smtp.\u tls”的TXT记录，则不以“v=TLSRPTv1；”开头的记录将被丢弃。如果生成的记录数不是一个，则发件人必须假定收件人域未实现TLSRPT。如果生成的TXT记录包含多个字符串（如[RFC7208]第3.3节所述），则必须将该记录视为连接这些字符串而不添加空格。
The record supports the ability to declare more than one rua, and if there exists more than one, the reporter MAY attempt to deliver to each of the supported rua destinations. A receiver MAY opt to only attempt delivery to one of the endpoints; however, the report SHOULD NOT be considered successfully delivered until one of the endpoints accepts delivery of the report.
记录支持声明多个rua的功能，如果存在多个rua，报告者可以尝试向每个受支持的rua目的地交付。接收者可以选择仅尝试传送到其中一个端点；但是，在其中一个端点接受报告交付之前，不应认为报告已成功交付。
Parsers MUST accept TXT records that are syntactically valid (i.e., valid key/value pairs separated by semicolons) and implement a superset of this specification, in which case unknown fields SHALL be ignored.
解析器必须接受语法有效的TXT记录（即，用分号分隔的有效键/值对），并实现本规范的超集，在这种情况下，应忽略未知字段。
_smtp._tls.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com"
_smtp._tls.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com"
_smtp._tls.example.com. IN TXT \
"v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt"
_smtp._tls.example.com. IN TXT \
"v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt"
The report is composed as a plaintext file encoded in the Internet JSON (I-JSON) format [RFC7493].
该报告由一个以互联网JSON（I-JSON）格式编码的明文文件[RFC7493]组成。
Aggregate reports contain the following fields:
聚合报告包含以下字段：
o Report metadata:
o 报告元数据：
* The organization responsible for the report
* 负责报告的组织
* Contact information for one or more responsible parties for the contents of the report
* 报告内容的一个或多个责任方的联系信息
* A unique identifier for the report
* 报告的唯一标识符
* The reporting date range for the report
* 报告的报告日期范围
o Policy, consisting of:
o 政策，包括：
* One of the following policy types: (1) the MTA-STS Policy applied (as a string), (2) the DANE TLSA record applied (as a string, with each RR entry of the RRset listed and separated by a semicolon), and (3) the literal string "no-policy-found", if neither a DANE nor MTA-STS Policy could be found.
* 以下策略类型之一：（1）应用MTA-STS策略（作为字符串），（2）应用DANE TLSA记录（作为字符串，列出RRset的每个RR条目并用分号分隔），（3）如果找不到DANE或MTA-STS策略，则为文字字符串“未找到策略”。
* The domain for which the policy is applied
* 应用策略的域
* The MX host
* MX主机
o Aggregate counts, comprising result type, Sending MTA IP, receiving MTA hostname, session count, and an optional additional information field containing a URI for recipients to review further information on a failure type.
o 聚合计数，包括结果类型、发送MTA IP、接收MTA主机名、会话计数，以及一个可选的附加信息字段，该字段包含一个URI，供收件人查看有关故障类型的进一步信息。
Note that the failure types are non-exclusive; an aggregate report may contain overlapping "counts" of failure types when a single send attempt encountered multiple errors. Reporters may report multiple applied policies (for example, an MTA-STS Policy and a DANE TLSA record for the same domain and MX). Because of this, even in the case where only a single policy was applied, the "policies" field of the report body MUST be an array and not a singular value.
请注意，故障类型是非排他性的；当一次发送尝试遇到多个错误时，聚合报告可能包含重叠的故障类型“计数”。报告者可以报告多个应用的策略（例如，同一域和MX的MTA-STS策略和DANE TLSA记录）。因此，即使在仅应用单个策略的情况下，报告主体的“策略”字段也必须是数组，而不是单数值。
In the case of multiple failure types, the "failure-details" array would contain multiple entries. Each entry would have its own set of information pertaining to that failure type.
对于多个故障类型，“故障详细信息”数组将包含多个条目。每个条目都有一组与该故障类型相关的信息。
The report SHOULD cover a full day, from 00:00-24:00 UTC. This should allow for easier correlation of failure events. To avoid unintentionally overloading the system processing the reports, the reports should be delivered after some delay, perhaps several hours.
报告应涵盖协调世界时00:00-24:00之间的一整天。这应允许更容易地关联故障事件。为了避免无意中使处理报告的系统过载，报告应该在延迟一段时间后交付，可能需要几个小时。
As an example, a sending site might want to introduce a random delay of up to four hours:
例如，发送站点可能希望引入多达四小时的随机延迟：
func generate_sleep_delay() {
min_delay = 1
max_delay = 14400
rand = random(min_delay, max_delay)
return rand
}
func generate_sleep_delay() {
min_delay = 1
max_delay = 14400
rand = random(min_delay, max_delay)
return rand
}
func generate_report(policy_domain) {
do_rpt_work(policy_domain)
send_rpt(policy_domain)
}
func generate_report(policy_domain) {
do_rpt_work(policy_domain)
send_rpt(policy_domain)
}
func generate_tlsrpt() {
sleep(generate_sleep_delay())
for policy_domain in list_of_tlsrpt_enabled_domains {
generate_report(policy_domain)
}
}
func generate_tlsrpt() {
sleep(generate_sleep_delay())
for policy_domain in list_of_tlsrpt_enabled_domains {
generate_report(policy_domain)
}
}
o "total-successful-session-count": This indicates that the Sending MTA was able to successfully negotiate a policy-compliant TLS connection and serves to provide a "heartbeat" to receiving domains that signifies reporting is functional and tabulating correctly. This field contains an aggregate count of successful connections for the reporting system.
o “总成功会话计数”：这表示发送MTA能够成功协商符合策略的TLS连接，并向接收域提供“心跳”，表示报告功能正常且制表正确。此字段包含报告系统的成功连接总数。
o "total-failure-session-count": This indicates that the Sending MTA was unable to successfully establish a connection with the receiving platform. Section 4.3, "Result Types", will elaborate on the failed negotiation attempts. This field contains an aggregate count of failed connections.
o “总失败会话计数”：这表示发送MTA无法成功与接收平台建立连接。第4.3节“结果类型”将详细说明失败的谈判尝试。此字段包含失败连接的聚合计数。
The list of result types will start with the minimal set below and is expected to grow over time based on real-world experience. The initial set is outlined in Sections 4.3.1 to 4.3.4:
结果类型列表将从下面的最小集合开始，并根据实际经验随着时间的推移而增长。第4.3.1节至第4.3.4节概述了初始凝固：
o "starttls-not-supported": This indicates that the recipient MX did not support STARTTLS.
o “starttls不受支持”：这表示收件人MX不支持starttls。
o "certificate-host-mismatch": This indicates that the certificate presented did not adhere to the constraints specified in the MTA-STS or DANE policy, e.g., if the MX hostname does not match any identities listed in the subject alternative name (SAN) [RFC5280].
o “证书主机不匹配”：这表示所提供的证书不符合MTA-STS或DANE策略中指定的约束，例如，如果MX主机名与主题替代名称（SAN）[RFC5280]中列出的任何标识不匹配。
o "certificate-expired": This indicates that the certificate has expired.
o “证书已过期”：表示证书已过期。
o "certificate-not-trusted": This is a label that covers multiple certificate-related failures that include, but are not limited to, errors such as untrusted/unknown certification authorities (CAs), certificate name constraints, certificate chain errors, etc. When using this declaration, the reporting MTA SHOULD utilize the "failure-reason-code" to provide more information to the receiving entity.
o “证书不受信任”：这是一个标签，涵盖多个与证书相关的故障，包括但不限于错误，如不受信任/未知的证书颁发机构（CA）、证书名称约束、证书链错误等。使用此声明时，报告MTA应使用“故障原因代码”向接收实体提供更多信息。
o "validation-failure": This indicates a general failure for a reason not matching a category above. When using this declaration, the reporting MTA SHOULD utilize the "failure-reason-code" to provide more information to the receiving entity.
o “验证失败”：这表示由于与上述类别不匹配的原因而导致的一般失败。使用此声明时，报告MTA应利用“故障原因代码”向接收实体提供更多信息。
o "tlsa-invalid": This indicates a validation error in the TLSA record associated with a DANE policy. None of the records in the RRset were found to be valid.
o “tlsa无效”：这表示与DANE策略关联的tlsa记录中存在验证错误。未发现RRset中的任何记录有效。
o "dnssec-invalid": This indicates that no valid records were returned from the recursive resolver.
o “dnssec invalid”：这表示没有从递归解析程序返回有效记录。
o "dane-required": This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report. Mandatory DANE for SMTP is described in Section 6 of [RFC7672]. Such policies may be created by mutual agreement between two organizations that frequently exchange sensitive content via email.
o “dane required”：这表示发送系统配置为需要目标域的所有MX主机的dane TLSA记录，但作为报告主题的MX主机不存在DNSSEC验证的TLSA记录。[RFC7672]第6节描述了SMTP的强制DANE。这类策略可以通过两个经常通过电子邮件交换敏感内容的组织之间的相互协议创建。
o "sts-policy-fetch-error": This indicates a failure to retrieve an MTA-STS policy, for example, because the policy host is unreachable.
o “sts策略获取错误”：这表示检索MTA-sts策略失败，例如，因为无法访问策略主机。
o "sts-policy-invalid": This indicates a validation error for the overall MTA-STS Policy.
o “sts策略无效”：这表示整个MTA-sts策略的验证错误。
o "sts-webpki-invalid": This indicates that the MTA-STS Policy could not be authenticated using PKIX validation.
o “sts webpki无效”：这表示无法使用PKIX验证对MTA-sts策略进行身份验证。
When a negotiation failure cannot be categorized into one of the "Negotiation Failures" stated above, the reporter SHOULD use the "validation-failure" category. As TLS grows and becomes more complex, new mechanisms may not be easily categorized. This allows for a generic feedback category. When this category is used, the reporter SHOULD also use "failure-reason-code" to give some feedback to the receiving entity. This is intended to be a short text field, and the contents of the field should be an error code or error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".
当谈判失败不能归类为上述“谈判失败”时，报告人应使用“验证失败”类别。随着TLS的增长和变得更加复杂，新的机制可能不容易分类。这允许一个通用的反馈类别。当使用此类别时，报告者还应使用“故障原因代码”向接收实体提供一些反馈。这是一个短文本字段，字段内容应为错误代码或错误文本，如“X509\u V\u ERR\u UNHANDLED\u CRITICAL\u CRL\u EXTENSION”。
Transient errors due to too-busy networks, TCP timeouts, etc., are not required to be reported.
由于网络太忙、TCP超时等导致的暂时性错误不需要报告。
The JSON schema is derived from the HTTP Public Key Pinning (HPKP) JSON schema; see Section 3 of [RFC7469].
JSON模式源自HTTP公钥固定（HPKP）JSON模式；见[RFC7469]第3节。
{
"organization-name": organization-name,
"date-range": {
"start-datetime": date-time,
"end-datetime": date-time
},
"contact-info": email-address,
"report-id": report-id,
"policies": [{
"policy": {
"policy-type": policy-type,
"policy-string": policy-string,
"policy-domain": domain,
"mx-host": mx-host-pattern
},
"summary": {
"total-successful-session-count": total-successful-session-count,
"total-failure-session-count": total-failure-session-count
},
"failure-details": [
{
"result-type": result-type,
"sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo,
"receiving-ip": receiving-ip,
"failed-session-count": failed-session-count,
"additional-information": additional-info-uri,
"failure-reason-code": failure-reason-code
}
]
}
]
}
{
"organization-name": organization-name,
"date-range": {
"start-datetime": date-time,
"end-datetime": date-time
},
"contact-info": email-address,
"report-id": report-id,
"policies": [{
"policy": {
"policy-type": policy-type,
"policy-string": policy-string,
"policy-domain": domain,
"mx-host": mx-host-pattern
},
"summary": {
"total-successful-session-count": total-successful-session-count,
"total-failure-session-count": total-failure-session-count
},
"failure-details": [
{
"result-type": result-type,
"sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo,
"receiving-ip": receiving-ip,
"failed-session-count": failed-session-count,
"additional-information": additional-info-uri,
"failure-reason-code": failure-reason-code
}
]
}
]
}
JSON Report Format
JSON报告格式
o "organization-name": The name of the organization responsible for the report. It is provided as a string.
o “组织名称”：负责报告的组织名称。它作为字符串提供。
o "date-time": The date-time indicates the start and end times for the report range. It is provided as a string formatted according to "Internet Date/Time Format", Section 5.6 of [RFC3339]. The report should be for a full UTC day, 00:00-24:00.
o “日期时间”：日期时间表示报告范围的开始和结束时间。它是根据[RFC3339]第5.6节“互联网日期/时间格式”格式化的字符串。报告应为整个UTC日00:00-24:00。
o "email-address": The contact information for the party responsible for the report. It is provided as a string formatted according to "Addr-Spec Specification", Section 3.4.1 of [RFC5322].
o “电子邮件地址”：负责报告的一方的联系信息。它是根据[RFC5322]第3.4.1节“Addr Spec规范”格式化的字符串。
o "report-id": A unique identifier for the report. Report authors may use whatever scheme they prefer to generate a unique identifier. It is provided as a string.
o “报告id”：报告的唯一标识符。报表作者可以使用他们喜欢的任何方案来生成唯一标识符。它作为字符串提供。
o "policy-type": The type of policy that was applied by the sending domain. Presently, the only three valid choices are "tlsa", "sts", and the literal string "no-policy-found". It is provided as a string.
o “策略类型”：发送域应用的策略类型。目前，只有三个有效的选择是“tlsa”、“sts”和文本字符串“未找到任何策略”。它作为字符串提供。
o "policy-string": An encoding of the applied policy as a JSON array of strings, whether it's a TLSA record ([RFC6698], Section 2.3) or an MTA-STS Policy. Examples follow in the next section.
o “策略字符串”：将应用的策略编码为字符串的JSON数组，无论是TLSA记录（[RFC6698]，第2.3节）还是MTA-STS策略。下一节将给出示例。
o "domain": The Policy Domain against which the MTA-STS or DANE policy is defined. In the case of Internationalized Domain Names [RFC5891], the domain MUST consist of the Punycode-encoded A-labels [RFC3492] and not the U-labels.
o “域”：定义MTA-STS或DANE策略的策略域。对于国际化域名[RFC5891]，域必须由Punycode编码的A标签[RFC3492]而不是U标签组成。
o "mx-host-pattern": In the case where "policy-type" is "sts", it's the pattern of MX hostnames from the applied policy. It is provided as a JSON array of strings and is interpreted in the same manner as the rules in "MX Host Validation"; see Section 4.1 of [RFC8461]. In the case of Internationalized Domain Names [RFC5891], the domain MUST consist of the Punycode-encoded A-labels [RFC3492] and not the U-labels.
o “mx主机模式”：在“策略类型”为“sts”的情况下，它是应用策略中mx主机名的模式。它作为字符串的JSON数组提供，并以与“MX主机验证”中的规则相同的方式进行解释；见[RFC8461]第4.1节。对于国际化域名[RFC5891]，域必须由Punycode编码的A标签[RFC3492]而不是U标签组成。
o "result-type": A value from Section 4.3, "Result Types", above.
o “结果类型”：上述第4.3节“结果类型”中的值。
o "ip-address": The IP address of the Sending MTA that attempted the STARTTLS connection. It is provided as a string representation of an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or colon-hexadecimal notation.
o “ip地址”：尝试STARTTLS连接的发送MTA的ip地址。它以点十进制或冒号十六进制表示法作为IPv4（见下文）或IPv6[RFC5952]地址的字符串表示形式提供。
o "receiving-mx-hostname": The hostname of the receiving MTA MX record with which the Sending MTA attempted to negotiate a STARTTLS connection.
o “receiving mx hostname”：发送MTA尝试与之协商STARTTLS连接的接收MTA mx记录的主机名。
o "receiving-mx-helo" (optional): The HELLO (HELO) or Extended HELLO (EHLO) string from the banner announced during the reported session.
o “receiving mx helo”（可选）：报告会话期间宣布的横幅中的HELLO（helo）或Extended HELLO（EHLO）字符串。
o "receiving-ip": The destination IP address that was used when creating the outbound session. It is provided as a string representation of an IPv4 (see below) or IPv6 [RFC5952] address in dot-decimal or colon-hexadecimal notation.
o “接收ip”：创建出站会话时使用的目标ip地址。它以点十进制或冒号十六进制表示法作为IPv4（见下文）或IPv6[RFC5952]地址的字符串表示形式提供。
o "total-successful-session-count": The aggregate count (an integer, encoded as a JSON number) of successfully negotiated TLS-enabled connections to the receiving site.
o “total successful session count”：与接收站点成功协商的启用TLS的连接的聚合计数（整数，编码为JSON编号）。
o "total-failure-session-count": The aggregate count (an integer, encoded as a JSON number) of failures to negotiate a TLS-enabled connection to the receiving site.
o “total failure session count”：协商到接收站点的启用TLS的连接失败的聚合计数（整数，编码为JSON编号）。
o "failed-session-count": The number of (attempted) sessions that match the relevant "result-type" for this section (an integer, encoded as a JSON number).
o “失败会话计数”：与此节的相关“结果类型”（整数，编码为JSON编号）匹配的（尝试的）会话数。
o "additional-info-uri" (optional): A URI [RFC3986] that points to additional information around the relevant "result-type". For example, this URI might host the complete certificate chain presented during an attempted STARTTLS session.
o “附加信息uri”（可选）：指向相关“结果类型”周围附加信息的uri[RFC3986]。例如，此URI可能承载在尝试的STARTTLS会话期间呈现的完整证书链。
o "failure-reason-code": A text field to include a TLS-related error code or error message.
o “故障原因代码”：包含TLS相关错误代码或错误消息的文本字段。
For report purposes, an IPv4 address is defined via the following ABNF:
出于报告目的，IPv4地址通过以下ABNF定义：
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
And an IPv6 address is defined via the following ABNF:
IPv6地址通过以下ABNF定义：
IPv6address = <as defined in [RFC5954]>
IPv6address = <as defined in [RFC5954]>
Part of the report body includes the policy that is applied when attempting relay to the destination.
报告正文的一部分包括尝试中继到目标时应用的策略。
For DANE TLSA policies, this is a JSON array of strings each representing the RDATA of a single TLSA resource record as a space-separated list of its four TLSA fields; the fields are in presentation format (defined in [RFC6698], Section 2.2) with no internal spaces or grouping parentheses:
对于DANE TLSA策略，这是一个JSON字符串数组，每个字符串表示单个TLSA资源记录的RDATA，作为其四个TLSA字段的空格分隔列表；字段采用表示格式（在[RFC6698]第2.2节中定义），没有内部空格或分组括号：
[ "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513 D747D1D085D", "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513 D747D1D1234" ]
[“3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513 D747D1D085D”，“3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513 D747D1D1234”]
For MTA-STS policies, this is an array of JSON strings that represents the policy that is declared by the receiving site, including any errors that may be present. Note that where there are multiple "mx" values, they must be listed as separate "mx" elements in the policy array rather than as a single nested "mx" sub-array.
对于MTA-STS策略，这是一个JSON字符串数组，表示接收站点声明的策略，包括可能出现的任何错误。请注意，如果有多个“mx”值，则它们必须在策略数组中作为单独的“mx”元素列出，而不是作为单个嵌套的“mx”子数组列出。
[ "version: STSv1", "mode: testing", "mx: mx1.example.com", "mx: mx2.example.com", "mx: mx.backup-example.com", "max_age: 604800" ]
[“version:STSv1”、“mode:testing”、“mx:mx1.example.com”、“mx:mx2.example.com”、“mx:mx.backup example.com”、“max_age:604800”]
Reports can be delivered either via SMTP (as an email message) or via HTTP POST.
报告可以通过SMTP（电子邮件）或HTTP POST发送。
The filename is RECOMMENDED to be constructed using the following ABNF:
建议使用以下ABNF构造文件名：
filename = sender "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
filename = sender "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
unique-id = 1*(ALPHA / DIGIT)
unique-id = 1*(ALPHA / DIGIT)
sender = domain ; from [RFC5321] -- this is used
; as the domain for the `contact-info`
; address in the report body.
; In the case of Internationalized Domain
; Names [RFC5891], the domain MUST consist of
; the Punycode-encoded A-labels [RFC3492] and
; not the U-labels.
sender = domain ; from [RFC5321] -- this is used
; as the domain for the `contact-info`
; address in the report body.
; In the case of Internationalized Domain
; Names [RFC5891], the domain MUST consist of
; the Punycode-encoded A-labels [RFC3492] and
; not the U-labels.
policy-domain = domain
; In the case of Internationalized Domain
; Names [RFC5891], the domain MUST consist of
; the Punycode-encoded A-labels [RFC3492] and
; not the U-labels.
policy-domain = domain
; In the case of Internationalized Domain
; Names [RFC5891], the domain MUST consist of
; the Punycode-encoded A-labels [RFC3492] and
; not the U-labels.
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
extension = "json" / "json.gz"
extension = "json" / "json.gz"
The extension MUST be "json" for a plain JSON file or "json.gz" for a JSON file compressed using gzip.
对于普通json文件，扩展名必须是“json”，对于使用gzip压缩的json文件，扩展名必须是“json.gz”。
"unique-id" allows an optional unique ID generated by the Sending MTA to distinguish among multiple reports generated simultaneously by different sources for the same Policy Domain. For example, this is a possible filename for a compressed report to the Policy Domain "example.net" from the Sending MTA "mail.sndr.example.com":
“唯一id”允许发送MTA生成可选的唯一id，以区分不同来源为同一策略域同时生成的多个报告。例如，这是从发送MTA“mail.sndr.example.com”到策略域“example.net”的压缩报告的可能文件名：
"mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
"mail.sndr.example.com!example.net!1470013207!1470186007!001.json.gz"
The report SHOULD be subjected to gzip [RFC1952] compression for both email and HTTPS transport. Declining to apply compression can cause the report to be too large for a receiver to process (a commonly observed receiver limit is ten megabytes); compressing the file increases the chances of acceptance of the report at some computational cost.
对于电子邮件和HTTPS传输，报告都应进行gzip[RFC1952]压缩。拒绝应用压缩可能导致报告太大，接收器无法处理（通常观察到的接收器限制为10兆字节）；压缩文件会增加报告被接受的机会，但需要付出一定的计算成本。
The report MAY be delivered by email. To make the reports machine-parsable for the receivers, we define a top-level media type "multipart/report" with a new parameter "report-type="tlsrpt"". Inside it, there are two parts: The first part is human readable, typically "text/plain", and the second part is machine readable with a new media type defined called "application/tlsrpt+json". If compressed, the report should use the media type "application/ tlsrpt+gzip".
报告可通过电子邮件发送。为了使报告机器对接收者可解析，我们定义了一个顶级媒体类型“multipart/report”，并使用一个新参数“report type=“tlsrpt”。在它里面，有两个部分：第一部分是人类可读的，通常是“文本/普通”，第二部分是机器可读的，定义了一种称为“application/tlsrpt+json”的新媒体类型。如果压缩，报告应使用媒体类型“application/tlsrpt+gzip”。
In addition, the following two new top-level message header fields are defined:
此外，还定义了以下两个新的顶级消息头字段：
"TLS-Report-Domain: Receiver-Domain"
“TLS报告域：接收方域”
"TLS-Report-Submitter: Sender-Domain"
“TLS报告提交者：发件人域”
The "TLS-Report-Submitter" value MUST match the value found in the domain [RFC5321] of the "contact-info" from the report body. These message header fields MUST be included and should allow for easy searching for all reports submitted by a reporting domain or a particular submitter, for example, in IMAP [RFC3501]:
“TLS报告提交人”值必须与报告正文中“联系人信息”的域[RFC5321]中的值匹配。必须包含这些消息头字段，并允许轻松搜索报告域或特定提交者提交的所有报告，例如，在IMAP[RFC3501]中：
"s SEARCH HEADER "TLS-Report-Domain" "example.com""
s搜索标题“TLS报告域”“example.com”
It is presumed that the aggregate reporting address will be equipped to process new message header fields and extract MIME parts with the prescribed media type and filename, and ignore the rest. These additional headers SHOULD be included in the DKIM [RFC6376] signature for the message.
据推测，聚合报告地址将用于处理新的消息头字段，提取具有指定媒体类型和文件名的MIME部分，并忽略其余部分。这些额外的头应该包含在消息的DKIM[RFC6376]签名中。
The RFC5322.Subject field for report submissions SHOULD conform to the following ABNF:
报告提交的RFC5322.主题字段应符合以下ABNF：
tlsrpt-subject = %s"Report" FWS ; "Report"
%s"Domain:" FWS ; "Domain:"
domain-name FWS ; per [RFC6376]
%s"Submitter:" FWS ; "Submitter:"
domain-name FWS ; per [RFC6376]
%s"Report-ID:" FWS ; "Report-ID:
"<" id-left "@" id-right ">" ; per [RFC5322]
[CFWS] ; per [RFC5322]
; (as with FWS)
tlsrpt-subject = %s"Report" FWS ; "Report"
%s"Domain:" FWS ; "Domain:"
domain-name FWS ; per [RFC6376]
%s"Submitter:" FWS ; "Submitter:"
domain-name FWS ; per [RFC6376]
%s"Report-ID:" FWS ; "Report-ID:
"<" id-left "@" id-right ">" ; per [RFC5322]
[CFWS] ; per [RFC5322]
; (as with FWS)
The first domain-name indicates the DNS domain name about which the report was generated. The second domain-name indicates the DNS domain name representing the Sending MTA generating the report. The purpose of the "Report-ID:" portion of the field is to enable the Policy Domain to identify and ignore duplicate reports that might be sent by a Sending MTA.
第一个域名表示生成报告的DNS域名。第二个域名表示表示生成报告的发送MTA的DNS域名。该字段“报告ID:”部分的目的是使策略域能够识别和忽略可能由发送MTA发送的重复报告。
For instance, this is a possible Subject field for a report to the Policy Domain "example.net" from the Sending MTA "mail.sender.example.com". It is line-wrapped as allowed by [RFC5322]:
例如，对于从发送MTA“mail.sender.example.com”发送到策略域“example.net”的报告，这是一个可能的主题字段。按照[RFC5322]的允许进行换行：
Subject: Report Domain: example.net
Submitter: mail.sender.example.com
Report-ID: <735ff.e317+bf22029@mailexample.net>
Subject: Report Domain: example.net
Submitter: mail.sender.example.com
Report-ID: <735ff.e317+bf22029@mailexample.net>
From: tlsrpt@mail.sender.example.com
Date: Fri, May 09 2017 16:54:30 -0800
To: mts-sts-tlsrpt@example.net
Subject: Report Domain: example.net
Submitter: mail.sender.example.com
Report-ID: <735ff.e317+bf22029@example.net>
TLS-Report-Domain: example.net
TLS-Report-Submitter: mail.sender.example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type="tlsrpt";
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
From: tlsrpt@mail.sender.example.com
Date: Fri, May 09 2017 16:54:30 -0800
To: mts-sts-tlsrpt@example.net
Subject: Report Domain: example.net
Submitter: mail.sender.example.com
Report-ID: <735ff.e317+bf22029@example.net>
TLS-Report-Domain: example.net
TLS-Report-Submitter: mail.sender.example.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type="tlsrpt";
boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
Content-Language: en-us
This is a multipart message in MIME format.
这是MIME格式的多部分消息。
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
This is an aggregate TLS report from mail.sender.example.com
这是来自mail.sender.example.com的聚合TLS报告
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/tlsrpt+gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.sender.example!example.com!
1013662812!1013749130.json.gz"
------=_NextPart_000_024E_01CC9B0A.AFE54C00
Content-Type: application/tlsrpt+gzip
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="mail.sender.example!example.com!
1013662812!1013749130.json.gz"
<gzipped content of report>
<gzip报告内容>
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
...
------=_NextPart_000_024E_01CC9B0A.AFE54C00--
...
Note that, when sending failure reports via SMTP, Sending MTAs MUST NOT honor MTA-STS or DANE TLSA failures.
请注意，当通过SMTP发送失败报告时，发送MTA不得接受MTA-STS或DANE TLSA失败。
The report MAY be delivered by POST to HTTPS. If compressed, the report SHOULD use the media type "application/tlsrpt+gzip"; otherwise it SHOULD use the media type "application/tlsrpt+json" (see Section 6, "IANA Considerations").
报告可通过邮寄至HTTPS。如果压缩，报告应使用媒体类型“application/tlsrpt+gzip”；否则，它应该使用媒体类型“application/tlsrpt+json”（参见第6节“IANA注意事项”）。
The receiving system MUST return a "successful" response from its HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. Other codes could indicate a delivery failure and may be retried as per
接收系统必须从其HTTPS服务器返回“成功”响应，通常是200或201 HTTP代码[RFC7231]。其他代码可能表示交付失败，并可能根据需要重试
local sender policy. The receiving system is not expected to process reports at receipt time and MAY store them for processing at a later time.
本地发件人策略。接收系统预计不会在接收时处理报告，可能会存储这些报告以供以后处理。
In the event of a delivery failure, regardless of the delivery method, a sender SHOULD attempt redelivery for up to 24 hours after the initial attempt. As previously stated, the reports are optional, so while it is ideal to attempt redelivery, it is not required. If multiple retries are attempted, ideally they SHOULD be done with exponential backoff.
如果交付失败，无论采用何种交付方式，发送方应在首次尝试后24小时内尝试重新交付。如前所述，报告是可选的，因此虽然尝试重新交付是理想的，但不需要。如果尝试多次重试，理想情况下应采用指数退避。
As stated above, there are a variable number of ways to declare information about the data therein. If any of the items declared via subject or filename disagree with the report, the report MUST be considered the authoritative source.
如上所述，有多种方法可以声明其中数据的相关信息。如果通过主题或文件名声明的任何项目与报告不一致，则必须将报告视为权威来源。
The following are the IANA considerations discussed in this document.
以下是本文件中讨论的IANA注意事项。
Below is the Internet Assigned Numbers Authority (IANA) Permanent Message Header Field registration information per [RFC3864].
以下是互联网分配号码管理局（IANA）根据[RFC3864]提供的永久消息头字段注册信息。
Header field name: TLS-Report-Domain
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8460
Header field name: TLS-Report-Domain
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8460
Header field name: TLS-Report-Submitter
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8460
Header field name: TLS-Report-Submitter
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document(s): RFC 8460
This document creates a new registry for the "report-type" parameter to the Content-Type header field for the "multipart/report" top-level media type defined in [RFC6522].
本文档为[RFC6522]中定义的“多部分/报告”顶级媒体类型的内容类型标题字段的“报告类型”参数创建一个新注册表。
The registry name is "Report Type Registry", and the procedure for updating the registry will be "Specification Required" [RFC8126].
注册表名为“Report Type registry”，更新注册表的过程为“Specification Required”[RFC8126]。
An entry in this registry should contain:
此注册表中的条目应包含：
o the report-type being registered
o 正在注册的报表类型
o one or more registered media types that can be used with this report-type
o 可与此报告类型一起使用的一个或多个已注册媒体类型
o the document containing the registration action
o 包含注册操作的文档
o an optional comment
o 随意的评论
The initial entries are:
初始条目为：
Report-Type: tlsrpt
Media Type: application/tlsrpt+gzip, application/tlsrpt+json
Registered By: [RFC8460]
Comment: Media types suitable for use with this report-type are
defined in Sections 6.4 and 6.5 of [RFC8460]
Report-Type: tlsrpt
Media Type: application/tlsrpt+gzip, application/tlsrpt+json
Registered By: [RFC8460]
Comment: Media types suitable for use with this report-type are
defined in Sections 6.4 and 6.5 of [RFC8460]
Report-Type: disposition-notification Media Type: message/disposition-notification Registered By: [RFC8098], Section 10
报告类型：处置通知媒体类型：消息/处置通知注册人：[RFC8098]，第10节
Report-Type: disposition-notification Media Type: message/global-disposition-notification Registered By: [RFC6533], Section 6
报告类型：处置通知媒体类型：消息/全局处置通知注册人：[RFC6533]，第6节
Report-Type: delivery-status Media Type: message/delivery-status Registered By: [RFC3464], Section 6.2
报告类型：传递状态媒体类型：邮件/传递状态注册人：[RFC3464]，第6.2节
Report-Type: delivery-status Media Type: message/global-delivery-status Registered By: [RFC6533], Section 6
报告类型：传递状态媒体类型：邮件/全局传递状态注册人：[RFC6533]，第6节
This document registers a new media type suffix "+gzip". The gzip format is a public domain, cross-platform, interoperable file storage and transfer format, specified in [RFC1952]; it supports compression and is used as the underlying representation by a variety of file formats. The media type "application/gzip" has been registered for such files. The suffix "+gzip" MAY be used with any media type whose representation follows that established for "application/gzip". The registration form for the structured syntax suffix for use with media types is as follows:
本文档注册了一个新的媒体类型后缀“+gzip”。gzip格式是[RFC1952]中规定的公共域、跨平台、可互操作的文件存储和传输格式；它支持压缩，并被各种文件格式用作底层表示。已为此类文件注册了媒体类型“application/gzip”。后缀“+gzip”可用于任何媒体类型，其表示形式遵循为“应用程序/gzip”建立的表示形式。用于媒体类型的结构化语法后缀的注册表格如下：
Type name: gzip file storage and transfer format.
类型名称：gzip文件存储和传输格式。
+suffix: +gzip
+suffix: +gzip
References: [RFC1952] [RFC6713]
参考文献：[RFC1952][RFC6713]
Encoding considerations: gzip is a binary encoding.
编码注意事项：gzip是二进制编码。
Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for +gzip SHOULD be as specified for "application/gzip". (At publication of this document, there is no fragment identification syntax defined for "application/gzip".) The syntax and semantics for fragment identifiers for a specific "xxx/ yyy+gzip" SHOULD be processed as follows:
片段标识符注意事项：为+gzip指定的片段标识符的语法和语义应该与为“application/gzip”指定的相同。（在本文档发布时，没有为“应用程序/gzip”定义片段标识语法。）特定“xxx/yyy+gzip”的片段标识符的语法和语义应按如下方式处理：
For cases defined in +gzip, where the fragment identifier resolves per the +gzip rules, process as specified in +gzip.
对于在+gzip中定义的情况，其中片段标识符根据+gzip规则解析，请按照+gzip中的指定进行处理。
For cases defined in +gzip, where the fragment identifier does not resolve per the +gzip rules, process as specified in "xxx/yyy+gzip".
对于在+gzip中定义的情况，如果片段标识符没有按照+gzip规则解析，请按照“xxx/yyy+gzip”中的指定进行处理。
For cases not defined in +gzip, process as specified in "xxx/yyy+gzip".
对于+gzip中未定义的情况，按照“xxx/yyy+gzip”中的规定进行处理。
Interoperability considerations: N/A
互操作性注意事项：不适用
Security considerations: gzip format doesn't provide confidentiality protection. Integrity protection is provided by an Adler-32 checksum, which is not cryptographically strong. See also the security considerations of [RFC6713]. Each individual media type registered with a +gzip suffix can have additional security considerations. Additionally, gzip objects can contain multiple
安全注意事项：gzip格式不提供机密性保护。完整性保护由Adler-32校验和提供，该校验和在加密方面不强。另请参见[RFC6713]的安全注意事项。使用+gzip后缀注册的每种媒体类型都有额外的安全注意事项。此外，gzip对象可以包含多个
files and associated paths. File paths must be validated when the files are extracted; a malicious file path could otherwise cause the extractor to overwrite application or system files.
文件和关联路径。提取文件时必须验证文件路径；恶意文件路径可能会导致提取器覆盖应用程序或系统文件。
Contact: art@ietf.org
联系人：art@ietf.org
Author/Change controller: Internet Engineering Task Force (iesg@ietf.org).
作者/变更控制员：互联网工程任务组(iesg@ietf.org).
This document registers multiple media types, beginning with Table 1 below.
本文档登记了多种介质类型，从下表1开始。
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File Ext | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+json | .json | Section 5.3 |
+-------------+----------------+-------------+-------------------+
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File Ext | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+json | .json | Section 5.3 |
+-------------+----------------+-------------+-------------------+
Table 1: SMTP TLS Reporting Media Type
表1:SMTP TLS报告介质类型
Type name: application
类型名称：应用程序
Subtype name: tlsrpt+json
子类型名称：tlsrpt+json
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC7493].
编码注意事项：编码注意事项与为“application/json”媒体类型指定的注意事项相同。见[RFC7493]。
Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7.
安全注意事项：第7节讨论了与SMTP TLS报告相关的安全注意事项。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
互操作性注意事项：本文件规定了一致性消息的格式及其解释。
Published specification: Section 5.3 of RFC 8460.
已发布规范：RFC 8460第5.3节。
Applications that use this media type: Mail User Agents (MUAs) and Mail Transfer Agents.
使用此媒体类型的应用程序：邮件用户代理（MUA）和邮件传输代理。
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): ".json"
文件扩展名：“.json”
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the Authors' Addresses section.
联系人和电子邮件地址以了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: See the Authors' Addresses section.
作者：参见作者地址部分。
Change controller: Internet Engineering Task Force (iesg@ietf.org).
变更控制员：互联网工程特别工作组(iesg@ietf.org).
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File Ext | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+gzip | .gz | Section 5.3 |
+-------------+----------------+-------------+-------------------+
+-------------+----------------+-------------+-------------------+
| Type | Subtype | File Ext | Specification |
+-------------+----------------+-------------+-------------------+
| application | tlsrpt+gzip | .gz | Section 5.3 |
+-------------+----------------+-------------+-------------------+
Table 2: SMTP TLS Reporting Media Type
表2:SMTP TLS报告介质类型
Type name: application
类型名称：应用程序
Subtype name: tlsrpt+gzip
子类型名称：tlsrpt+gzip
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: Binary
编码注意事项：二进制
Security considerations: Security considerations relating to SMTP TLS Reporting are discussed in Section 7. Security considerations related to gzip compression are discussed in RFC 6713.
安全注意事项：第7节讨论了与SMTP TLS报告相关的安全注意事项。RFC6713中讨论了与gzip压缩相关的安全注意事项。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
互操作性注意事项：本文件规定了一致性消息的格式及其解释。
Published specification: Section 5.3 of RFC 8460.
已发布规范：RFC 8460第5.3节。
Applications that use this media type: Mail User Agents (MUAs) and Mail Transfer Agents.
使用此媒体类型的应用程序：邮件用户代理（MUA）和邮件传输代理。
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): The first two bytes are 0x1f, 0x8b.
幻数：前两个字节是0x1f、0x8b。
File extension(s): ".gz"
文件扩展名：“.gz”
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: See the Authors' Addresses section.
联系人和电子邮件地址以了解更多信息：请参阅作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: See the Authors' Addresses section.
作者：参见作者地址部分。
Change controller: Internet Engineering Task Force (iesg@ietf.org).
变更控制员：互联网工程特别工作组(iesg@ietf.org).
This document creates a new registry, "STARTTLS Validation Result Types". The initial entries in the registry are:
本文档创建了一个新的注册表“STARTTLS验证结果类型”。注册表中的初始条目为：
+-----------------------------+--------------+
| Result Type | Description |
+-----------------------------+--------------+
| starttls-not-supported | Section 4.3 |
| certificate-host-mismatch | Section 4.3 |
| certificate-expired | Section 4.3 |
| tlsa-invalid | Section 4.3 |
| dnssec-invalid | Section 4.3 |
| dane-required | Section 4.3 |
| certificate-not-trusted | Section 4.3 |
| sts-policy-invalid | Section 4.3 |
| sts-webpki-invalid | Section 4.3 |
| validation-failure | Section 4.3 |
| sts-policy-fetch-error | Section 4.3 |
+-----------------------------+--------------+
+-----------------------------+--------------+
| Result Type | Description |
+-----------------------------+--------------+
| starttls-not-supported | Section 4.3 |
| certificate-host-mismatch | Section 4.3 |
| certificate-expired | Section 4.3 |
| tlsa-invalid | Section 4.3 |
| dnssec-invalid | Section 4.3 |
| dane-required | Section 4.3 |
| certificate-not-trusted | Section 4.3 |
| sts-policy-invalid | Section 4.3 |
| sts-webpki-invalid | Section 4.3 |
| validation-failure | Section 4.3 |
| sts-policy-fetch-error | Section 4.3 |
+-----------------------------+--------------+
The above entries are described in Section 4.3, "Result Types". New result types can be added to this registry using the "Expert Review" IANA registration policy.
第4.3节“结果类型”中描述了上述条目。可以使用“专家评审”IANA注册策略将新结果类型添加到此注册表。
SMTP TLS Reporting provides visibility into misconfigurations or attempts to intercept or tamper with mail between hosts who support STARTTLS. There are several security risks presented by the existence of this reporting channel:
SMTP TLS报告提供了对支持STARTTLS的主机之间的错误配置或试图拦截或篡改邮件的可见性。该报告渠道的存在带来了若干安全风险：
o Flooding of the Aggregate Report URI (rua) endpoint: An attacker could flood the endpoint with excessive reporting traffic and prevent the receiving domain from accepting additional reports. This type of Denial-of-Service attack would limit visibility into STARTTLS failures, leaving the receiving domain blind to an ongoing attack.
o 聚合报告URI（rua）终结点泛滥：攻击者可以使用过多的报告流量泛滥终结点，并阻止接收域接受其他报告。这种类型的拒绝服务攻击将限制对STARTTLS故障的可见性，使接收域对正在进行的攻击视而不见。
o Untrusted content: An attacker could inject malicious code into the report, exploiting any vulnerabilities in the report-handling systems of the receiving domain. Implementers are advised to take precautions against evaluating the contents of the report.
o 不受信任的内容：攻击者可以向报告中注入恶意代码，利用接收域的报告处理系统中的任何漏洞。建议实施者在评估报告内容时采取预防措施。
o Report snooping: An attacker could create a bogus TLSRPT record to receive statistics about a domain the attacker does not own. Since an attacker that is able to poison DNS is already able to receive counts of SMTP connections (and, absent DANE or MTA-STS policies, actual SMTP message payloads), this does not present a significant new vulnerability.
o 报告窥探：攻击者可以创建虚假的TLSRPT记录，以接收有关攻击者不拥有的域的统计信息。由于能够毒害DNS的攻击者已经能够接收SMTP连接计数（以及在缺少DANE或MTA-STS策略的情况下，实际SMTP邮件有效负载），因此这并不构成新的重大漏洞。
o Ignoring HTTPS validation when submitting reports: When reporting benign misconfigurations, it is likely that a misconfigured SMTP server may also mean a misconfigured HTTPS server; as a result, reporters who require HTTPS validity on the reporting endpoint may fail to alert administrators about such misconfigurations. Conversely, in the event of an actual attack, an attacker who wishes to create a gap in reporting and could intercept HTTPS reports could, just as easily, simply thwart the resolution of the TLSRPT TXT record or establishment of the TCP session to the HTTPS endpoint. Furthermore, such a man-in-the-middle attacker could discover most or all of the metadata exposed in a report merely through passive observation. As a result, we consider the risks of failure to deliver reports on misconfigurations to outweigh those of attackers intercepting reports.
o 提交报告时忽略HTTPS验证：报告良性错误配置时，错误配置的SMTP服务器可能也意味着错误配置的HTTPS服务器；因此，在报告端点上要求HTTPS有效性的报告者可能无法向管理员提醒此类错误配置。相反，在发生实际攻击的情况下，希望在报告中造成漏洞并能够截获HTTPS报告的攻击者可能同样容易地阻止解析TLSRPT TXT记录或建立到HTTPS端点的TCP会话。此外，这种中间人攻击者仅通过被动观察就可以发现报告中暴露的大部分或全部元数据。因此，我们认为失败的风险交付错误配置报告超过攻击者拦截报告。
o Reports as DDoS: TLSRPT allows specifying destinations for the reports that are outside the authority of the Policy Domain, which allows domains to delegate processing of reports to a partner organization. However, an attacker who controls the Policy Domain DNS could also use this mechanism to direct the reports to an unwitting victim, flooding that victim with excessive reports. DMARC [RFC7489] defines a solution for verifying delegation to avoid such attacks; the need for this is greater with DMARC, however, because DMARC allows an attacker to trigger reports to a target from an innocent third party by sending mail to that third party (which triggers a report from the third party to the target). In the case of TLSRPT, the attacker would have to induce the third party to send mail to the attacker in order to trigger reports from the third party to the victim; this reduces the risk of such an attack and the need for a verification mechanism.
o 报告为DDoS:TLSRPT允许为策略域权限之外的报告指定目标，这允许域将报告处理委托给合作伙伴组织。但是，控制策略域DNS的攻击者也可以使用此机制将报告定向到不知情的受害者，从而使该受害者收到大量报告。DMARC[RFC7489]定义了一种验证委托以避免此类攻击的解决方案；但是，对于DMARC来说，这种需求更大，因为DMARC允许攻击者通过向无辜的第三方发送邮件（这会触发第三方向目标发送的报告）来触发来自该第三方的报告。在TLSRPT的情况下，攻击者必须诱使第三方向攻击者发送邮件，以触发第三方向受害者的报告；这降低了此类攻击的风险和对验证机制的需要。
Finally, because TLSRPT is intended to help administrators discover man-in-the-middle attacks against transport-layer encryption, including attacks designed to thwart negotiation of encrypted connections (by downgrading opportunistic encryption or, in the case of MTA-STS, preventing discovery of a new MTA-STS Policy), we must also consider the risk that an adversary who can induce such a downgrade attack can also prevent discovery of the TLSRPT TXT record (and thus prevent discovery of the successful downgrade attack). Administrators are thus encouraged to deploy TLSRPT TXT records with a large TTL (reducing the window for successful application of transient attacks against DNS resolution of the record) or to deploy DNSSEC on the deploying zone.
最后，由于TLSRPT旨在帮助管理员发现针对传输层加密的中间人攻击，包括旨在阻止加密连接协商的攻击（通过降级机会主义加密，或者在MTA-STS的情况下，阻止发现新的MTA-STS策略），我们还必须考虑一个能够引起这种降级攻击的对手的风险，也可以防止TLSRPT TXT记录的发现（从而防止发现成功的降级攻击）。因此，鼓励管理员部署具有较大TTL的TLSRPT TXT记录（减少成功应用针对记录DNS解析的瞬态攻击的窗口）或在部署区域上部署DNSSEC。
MTAs are generally considered public knowledge; however, the internals of how those MTAs are configured and the users of those MTAs may not be as public. It should be noted that providing a receiving site with information about TLS failures may reveal information about the sender's configuration or even information about the senders themselves. For example, sending a report may disclose what TLS implementation the sender uses, as the inability to negotiate a session may be a known incompatibility between two implementations. This may, indirectly, leak information on the reporter's operating system or even region, if, for example, a rare TLS implementation is popular among certain users or in certain locations.
MTA通常被认为是公共知识；但是，这些MTA的内部配置和用户可能并不公开。应注意，向接收站点提供有关TLS故障的信息可能会泄露有关发送方配置的信息，甚至可能泄露有关发送方自身的信息。例如，发送报告可能会披露发送方使用的TLS实现，因为无法协商会话可能是两个实现之间的已知不兼容。这可能会间接泄漏报告者操作系统甚至地区的信息，例如，如果某个罕见的TLS实现在某些用户或某些位置流行的话。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.
[RFC1952]Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC 1952，DOI 10.17487/RFC1952，1996年5月<https://www.rfc-editor.org/info/rfc1952>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<https://www.rfc-editor.org/info/rfc3339>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, <https://www.rfc-editor.org/info/rfc3492>.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，DOI 10.17487/RFC3492，2003年3月<https://www.rfc-editor.org/info/rfc3492>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 5891，DOI 10.17487/RFC5891，2010年8月<https://www.rfc-editor.org/info/rfc5891>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<https://www.rfc-editor.org/info/rfc5952>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, <https://www.rfc-editor.org/info/rfc6068>.
[RFC6068]Duerst，M.，Masinter，L.，和J.Zawinski，“mailto”URI方案”，RFC 6068，DOI 10.17487/RFC6068，2010年10月<https://www.rfc-editor.org/info/rfc6068>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<https://www.rfc-editor.org/info/rfc6376>.
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, <https://www.rfc-editor.org/info/rfc6522>.
[RFC6522]Kucherawy，M.，Ed.，“用于报告邮件系统管理消息的多部分/报告媒体类型”，STD 73，RFC 6522，DOI 10.17487/RFC6522，2012年1月<https://www.rfc-editor.org/info/rfc6522>.
[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, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC6713] Levine, J., "The 'application/zlib' and 'application/gzip' Media Types", RFC 6713, DOI 10.17487/RFC6713, August 2012, <https://www.rfc-editor.org/info/rfc6713>.
[RFC6713]Levine，J.，“应用程序/zlib”和“应用程序/gzip”媒体类型”，RFC 6713，DOI 10.17487/RFC6713，2012年8月<https://www.rfc-editor.org/info/rfc6713>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<https://www.rfc-editor.org/info/rfc7208>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405]Kyzivat，P.，“ABNF中的区分大小写字符串支持”，RFC 7405，DOI 10.17487/RFC7405，2014年12月<https://www.rfc-editor.org/info/rfc7405>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493]Bray，T.，Ed.，“I-JSON消息格式”，RFC 7493，DOI 10.17487/RFC7493，2015年3月<https://www.rfc-editor.org/info/rfc7493>.
[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, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<https://www.rfc-editor.org/info/rfc7671>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-editor.org/info/rfc7672>.
[RFC7672]Dukhovni，V.和W.Hardaker，“通过基于机会DNS的命名实体身份验证（DANE）传输层安全性（TLS）实现SMTP安全”，RFC 7672，DOI 10.17487/RFC7672，2015年10月<https://www.rfc-editor.org/info/rfc7672>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.
[RFC8461]Margolis，D.，Risher，M.，Ramakrishnan，B.，Brotman，A.，和J.Jones，“SMTP MTA严格传输安全（MTA-STS）”，RFC 8461，DOI 10.17487/RFC8461，2018年9月<https://www.rfc-editor.org/info/rfc8461>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，DOI 10.17487/RFC3207，2002年2月<https://www.rfc-editor.org/info/rfc3207>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <https://www.rfc-editor.org/info/rfc3464>.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，DOI 10.17487/RFC3464，2003年1月<https://www.rfc-editor.org/info/rfc3464>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<https://www.rfc-editor.org/info/rfc3501>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<https://www.rfc-editor.org/info/rfc3864>.
[RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, DOI 10.17487/RFC6533, February 2012, <https://www.rfc-editor.org/info/rfc6533>.
[RFC6533]Hansen，T.，Ed.，Newman，C.，和A.Melnikov，“国际化交付状态和处置通知”，RFC 6533，DOI 10.17487/RFC6533，2012年2月<https://www.rfc-editor.org/info/rfc6533>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<https://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7469]Evans，C.，Palmer，C.，和R.Sleevi，“HTTP的公钥锁定扩展”，RFC 7469，DOI 10.17487/RFC7469，2015年4月<https://www.rfc-editor.org/info/rfc7469>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<https://www.rfc-editor.org/info/rfc7489>.
[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, <https://www.rfc-editor.org/info/rfc8098>.
[RFC8098]Hansen，T.，Ed.和A.Melnikov，Ed.，“消息处置通知”，STD 85，RFC 8098，DOI 10.17487/RFC8098，2017年2月<https://www.rfc-editor.org/info/rfc8098>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
_smtp._tls.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com"
_smtp._tls.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com"
_smtp._tls.mail.example.com. IN TXT \
"v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt"
_smtp._tls.mail.example.com. IN TXT \
"v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt"
Below is an example JSON report for messages from Company-X to Company-Y, where 100 sessions were attempted to Company-Y servers with an expired certificate, and 200 sessions were attempted to Company-Y servers that did not successfully respond to the "STARTTLS" command. Additionally, 3 sessions failed due to "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
下面是从Company-X到Company-Y的消息的JSON报告示例，其中使用过期证书尝试向Company-Y服务器发送100个会话，并尝试向未成功响应“STARTTLS”命令的Company-Y服务器发送200个会话。此外，由于“超过X509\u V\u ERR\u PROXY\u PATH\u LENGTH\u”，3个会话失败。
{
"organization-name": "Company-X",
"date-range": {
"start-datetime": "2016-04-01T00:00:00Z",
"end-datetime": "2016-04-01T23:59:59Z"
},
"contact-info": "sts-reporting@company-x.example",
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policies": [{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1","mode: testing",
"mx: *.mail.company-y.example","max_age: 86400"],
"policy-domain": "company-y.example",
"mx-host": "*.mail.company-y.example"
},
"summary": {
"total-successful-session-count": 5326,
"total-failure-session-count": 303
},
"failure-details": [{
"result-type": "certificate-expired",
"sending-mta-ip": "2001:db8:abcd:0012::1",
"receiving-mx-hostname": "mx1.mail.company-y.example",
"failed-session-count": 100
}, {
{
"organization-name": "Company-X",
"date-range": {
"start-datetime": "2016-04-01T00:00:00Z",
"end-datetime": "2016-04-01T23:59:59Z"
},
"contact-info": "sts-reporting@company-x.example",
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policies": [{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1","mode: testing",
"mx: *.mail.company-y.example","max_age: 86400"],
"policy-domain": "company-y.example",
"mx-host": "*.mail.company-y.example"
},
"summary": {
"total-successful-session-count": 5326,
"total-failure-session-count": 303
},
"failure-details": [{
"result-type": "certificate-expired",
"sending-mta-ip": "2001:db8:abcd:0012::1",
"receiving-mx-hostname": "mx1.mail.company-y.example",
"failed-session-count": 100
}, {
"result-type": "starttls-not-supported",
"sending-mta-ip": "2001:db8:abcd:0013::1",
"receiving-mx-hostname": "mx2.mail.company-y.example",
"receiving-ip": "203.0.113.56",
"failed-session-count": 200,
"additional-information": "https://reports.company-x.example/
report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
}, {
"result-type": "validation-failure",
"sending-mta-ip": "198.51.100.62",
"receiving-ip": "203.0.113.58",
"receiving-mx-hostname": "mx-backup.mail.company-y.example",
"failed-session-count": 3,
"failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
}]
}]
}
"result-type": "starttls-not-supported",
"sending-mta-ip": "2001:db8:abcd:0013::1",
"receiving-mx-hostname": "mx2.mail.company-y.example",
"receiving-ip": "203.0.113.56",
"failed-session-count": 200,
"additional-information": "https://reports.company-x.example/
report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
}, {
"result-type": "validation-failure",
"sending-mta-ip": "198.51.100.62",
"receiving-ip": "203.0.113.58",
"receiving-mx-hostname": "mx-backup.mail.company-y.example",
"failed-session-count": 3,
"failure-reason-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
}]
}]
}
Contributors
贡献者
Laetitia Baudoin Google, Inc. lbaudoin@google.com
莱蒂蒂亚·博杜恩谷歌公司。lbaudoin@google.com
Authors' Addresses
作者地址
Daniel Margolis Google, Inc.
丹尼尔·马戈利斯谷歌公司。
Email: dmargolis@google.com
Email: dmargolis@google.com
Alexander Brotman Comcast, Inc.
亚历山大·布罗特曼康卡斯特公司。
Email: alex_brotman@comcast.com
Email: alex_brotman@comcast.com
Binu Ramakrishnan Oath, Inc.
比努罗摩克里希南誓言公司。
Email: prbinu@yahoo.com
Email: prbinu@yahoo.com
Janet Jones Microsoft, Inc.
珍妮特·琼斯微软公司。
Email: janet.jones@microsoft.com
Email: janet.jones@microsoft.com
Mark Risher Google, Inc.
马克·瑞舍谷歌公司。
Email: risher@google.com
Email: risher@google.com