Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6651 Cloudmark
Category: Standards Track June 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6651 Cloudmark
Category: Standards Track June 2012
ISSN: 2070-1721
Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting
用于故障报告的域密钥标识邮件（DKIM）扩展
Abstract
摘要
This document presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion.
本文档提供了对DomainKeys Identified Mail（DKIM）规范的扩展，以允许按需方式详细报告消息身份验证失败。
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/rfc6651.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6651.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Notation ...................................................3
2.3. Imported Definitions .......................................3
2.4. Other Definitions ..........................................3
3. Optional Reporting for DKIM .....................................4
3.1. Extension DKIM Signature Tag ...............................4
3.2. DKIM Reporting TXT Record ..................................4
3.3. DKIM Reporting Algorithm ...................................6
4. Optional Reporting Address for DKIM ADSP ........................8
5. Requested Reports ...............................................9
5.1. Requested Reports for DKIM Failures .......................10
5.2. Requested Reports for DKIM ADSP Failures ..................10
6. Report Generation ..............................................11
6.1. Report Format .............................................11
6.2. Other Guidance ............................................11
7. IANA Considerations ............................................11
7.1. DKIM Signature Tag Registration ...........................11
7.2. DKIM ADSP Tag Registration ................................12
7.3. DKIM Reporting Tag Registry ...............................12
8. Security Considerations ........................................13
8.1. Inherited Considerations ..................................13
8.2. Report Volume .............................................13
8.3. Deliberate Misuse .........................................13
8.4. Unreported Fraud ..........................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Acknowledgements ......................................16
Appendix B. Examples ..............................................16
B.1. Example Use of DKIM Signature Extension Tag ...............16
B.2. Example DKIM Reporting TXT Record .........................17
B.3. Example Use of DKIM ADSP Extension Tags ...................17
1. Introduction ....................................................3
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Notation ...................................................3
2.3. Imported Definitions .......................................3
2.4. Other Definitions ..........................................3
3. Optional Reporting for DKIM .....................................4
3.1. Extension DKIM Signature Tag ...............................4
3.2. DKIM Reporting TXT Record ..................................4
3.3. DKIM Reporting Algorithm ...................................6
4. Optional Reporting Address for DKIM ADSP ........................8
5. Requested Reports ...............................................9
5.1. Requested Reports for DKIM Failures .......................10
5.2. Requested Reports for DKIM ADSP Failures ..................10
6. Report Generation ..............................................11
6.1. Report Format .............................................11
6.2. Other Guidance ............................................11
7. IANA Considerations ............................................11
7.1. DKIM Signature Tag Registration ...........................11
7.2. DKIM ADSP Tag Registration ................................12
7.3. DKIM Reporting Tag Registry ...............................12
8. Security Considerations ........................................13
8.1. Inherited Considerations ..................................13
8.2. Report Volume .............................................13
8.3. Deliberate Misuse .........................................13
8.4. Unreported Fraud ..........................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Acknowledgements ......................................16
Appendix B. Examples ..............................................16
B.1. Example Use of DKIM Signature Extension Tag ...............16
B.2. Example DKIM Reporting TXT Record .........................17
B.3. Example Use of DKIM ADSP Extension Tags ...................17
DomainKeys Identified Mail [DKIM] introduced a mechanism for message signing and authentication. It uses digital signing to associate a domain name with a message in a reliable manner. The verified domain name can then be evaluated (e.g., checking advertised sender policy, comparison to a known-good list, submission to a reputation service, etc.).
域密钥识别邮件[DKIM]引入了一种消息签名和身份验证机制。它使用数字签名以可靠的方式将域名与消息关联起来。然后可以评估已验证的域名（例如，检查公布的发件人策略、与已知良好列表的比较、提交给声誉服务等）。
Deployers of message authentication technologies are increasingly seeking visibility into DKIM verification failures and conformance failures involving the published signing practices (e.g., Author Domain Signing Practices [ADSP]) of an ADministrative Management Domain (ADMD; see [EMAIL-ARCH]).
消息身份验证技术的部署者越来越多地寻求了解涉及管理域（ADMD；请参阅[EMAIL-ARCH]）的已发布签名实践（例如，作者域签名实践[ADSP]）的DKIM验证失败和一致性失败。
This document extends [DKIM] and [ADSP] to add an optional reporting address and some reporting parameters. Reports are generated using the format defined in [ARF-AUTHFAIL].
本文档扩展了[DKIM]和[ADSP]，添加了可选的报告地址和一些报告参数。使用[ARF-AUTHFAIL]中定义的格式生成报告。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Certain properties of email messages described in this document are referenced using notation found in [EMAIL-ARCH] (e.g., "RFC5322.From").
本文档中描述的电子邮件的某些属性使用[email-ARCH]中的符号表示（例如，“RFC5322.From”）。
Numerous DKIM-specific terms used here are defined in [DKIM]. The definitions of the [ABNF] tokens "domain-name" and "dkim-quoted-printable" can also be found there.
[DKIM]中定义了此处使用的许多DKIM专用术语。[ABNF]标记“域名”和“dkim quoted printable”的定义也可以在这里找到。
report generator: A report generator is an entity that generates and sends reports. For the scope of this document, the term refers to Verifiers, as defined in Section 2.2 of [DKIM], with the added capability to generate authentication failure reports according to this specification.
报表生成器：报表生成器是生成和发送报表的实体。在本文件范围内，该术语指[DKIM]第2.2节中定义的验证者，具有根据本规范生成认证失败报告的附加能力。
A domain name owner employing [DKIM] for email signing and authentication might want to know when signatures that ought to be verifiable are not successfully verifying. Currently, there is no such mechanism defined.
使用[DKIM]进行电子邮件签名和身份验证的域名所有者可能想知道应该可验证的签名何时未成功验证。目前，还没有定义这样的机制。
This section adds optional "tags" (as defined in [DKIM]) to the DKIM-Signature header field and the DKIM key record in the DNS, using the formats defined in that specification.
本节使用该规范中定义的格式，向DNS中的DKIM签名头字段和DKIM密钥记录添加可选的“标记”（如[DKIM]中定义）。
The following tag is added to DKIM-Signature header fields when a Signer wishes to request that reports of failed verifications be generated by a Verifier:
当签名者希望请求验证者生成验证失败的报告时，将在DKIM签名头字段中添加以下标记：
r= Reporting Requested (plain-text; OPTIONAL; no default). If present, this tag indicates that the Signer requests that Verifiers generate a report when verification of the DKIM signature fails. At present, the only legal value is the single character "y". A complete description and illustration of how this is applied can be found in Section 3.3.
r=请求的报告（纯文本；可选；无默认值）。如果存在，此标记表示签名者请求验证者在DKIM签名验证失败时生成报告。目前，唯一的法律价值是单个字符“y”。在第3.3节中可以找到关于如何应用该方法的完整描述和说明。
ABNF:
荷兰银行：
sig-r-tag = %x72 *WSP "=" *WSP %x79
; "r=y" (lower-case only)
sig-r-tag = %x72 *WSP "=" *WSP %x79
; "r=y" (lower-case only)
When a Signer wishes to advertise that it wants to receive failed verification reports, it places in the DNS a TXT Resource Record (RR). The RR contains a sequence of tag-value objects in a format similar to DKIM key records (see Section 3.6.1 of [DKIM]), but it is entirely independent of those key records and is found at a different name. The tag-value objects in this case comprise the parameters to be used when generating the reports. A report generator will request the content of this record when it sees an "r=" tag in a DKIM-Signature header field.
当签名者希望公布其希望接收失败的验证报告时，它会在DNS中放置一个TXT资源记录（RR）。RR包含一系列标签值对象，其格式类似于DKIM关键记录（见[DKIM]第3.6.1节），但它完全独立于这些关键记录，并以不同的名称找到。在这种情况下，标记值对象包括生成报告时要使用的参数。当报表生成器在DKIM签名头字段中看到“r=”标记时，将请求此记录的内容。
Section 3.6.2.2 of [DKIM] provides guidance with respect to the handling of a TXT RR that comprises multiple distinct strings ("character-strings" in the parlance of [DNS]). The same process MUST be applied here.
[DKIM]第3.6.2.2节提供了关于处理包含多个不同字符串的TXT RR的指南（“DNS术语中的字符串”）。这里必须采用同样的程序。
Implementations MUST support all tags defined in this document, and any other tag found in the content of the record that is not recognized by an implementation MUST be ignored. See Section 7.3 for details about finding or registering extension tags.
实现必须支持本文档中定义的所有标记，并且必须忽略在记录内容中发现的实现无法识别的任何其他标记。有关查找或注册扩展标签的详细信息，请参见第7.3节。
The initial list of tags supported for the reporting TXT record is as follows:
reporting TXT记录支持的标记的初始列表如下所示：
ra= Reporting Address (plain-text; OPTIONAL). A dkim-quoted-printable string (see Section 2.11 of [DKIM]) containing the local-part of an email address to which a report SHOULD be sent when mail fails DKIM verification for one of the reasons enumerated below. The value MUST be interpreted as a local-part only. To construct the actual address to which the report is sent, the Verifier simply appends to this value an "@" followed by the domain name found in the "d=" tag of the DKIM-Signature header field. Therefore, a Signer making use of this specification MUST ensure that an email address thus constructed can receive reports generated as described in Section 6.
ra=报告地址（纯文本；可选）。dkim引用的可打印字符串（见[dkim]第2.11节），其中包含电子邮件地址的本地部分，当邮件由于以下列举的原因之一未通过dkim验证时，应向其发送报告。该值必须仅解释为本地部分。要构造报告发送到的实际地址，验证器只需在该值后面附加一个“@”，后跟在DKIM签名头字段的“d=”标记中找到的域名。因此，使用本规范的签名人必须确保这样构造的电子邮件地址能够接收第6节所述生成的报告。
ABNF:
荷兰银行：
rep-ra-tag = %x72.61 *WSP "=" *WSP dkim-quoted-printable
; "ra=..." (lower-case only for the tag name)
rep-ra-tag = %x72.61 *WSP "=" *WSP dkim-quoted-printable
; "ra=..." (lower-case only for the tag name)
rp= Requested Report Percentage (plain-text; OPTIONAL; default is "100"). The value is an integer from 0 to 100 inclusive that indicates what percentage of incidents of signature authentication failures, selected at random, are to cause reports to be generated. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. Report generators MAY make use of the "Incidents:" field in [ARF] to indicate that there are more reportable incidents than there are reports.
rp=请求的报告百分比（纯文本；可选；默认值为“100”）。该值是一个从0到100（含0到100）的整数，表示随机选择的签名身份验证失败事件的百分比将导致生成报告。报告生成器发布的报告不应超过请求的事件百分比。报告生成器可以使用[ARF]中的“事件：”字段来表示可报告的事件多于报告。
ABNF:
荷兰银行：
rep-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
; "rp=..." (lower-case only)
rep-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
; "rp=..." (lower-case only)
rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 5.1 for a list of valid tokens.
rr=请求的报告（纯文本；可选；默认为“全部”）。该值必须是以冒号分隔的标记列表，表示需要报告的条件。有关有效令牌的列表，请参见第5.1节。
ABNF:
荷兰银行：
rep-rr-type = ( "all" / "d" / "o" / "p" / "s" / "u" / "v" / "x" )
rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type
*WSP *( ":" *WSP rep-rr-type )
; "rr=..." (lower-case only for the tag name)
rep-rr-type = ( "all" / "d" / "o" / "p" / "s" / "u" / "v" / "x" )
rep-rr-tag = %x72.72 *WSP "=" *WSP rep-rr-type
*WSP *( ":" *WSP rep-rr-type )
; "rr=..." (lower-case only for the tag name)
rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). The value is a dkim-quoted-printable string that the publishing ADMD requests be included in [SMTP] error strings if messages are rejected during the delivery SMTP session.
rs=请求的SMTP错误字符串（纯文本；可选；无默认值）。该值是一个dkim引用的可打印字符串，如果邮件在传递SMTP会话期间被拒绝，则发布ADMD请求将包含在[SMTP]错误字符串中。
ABNF:
荷兰银行：
rep-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
; "rs=..." (lower-case only for the tag name)
rep-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
; "rs=..." (lower-case only for the tag name)
In the absence of an "ra=" tag, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report.
如果没有“ra=”标记，则必须忽略“rp=”和“rr=”标记，并且报告生成器不得发布报告。
Report generators MUST apply the following algorithm, or one semantically equivalent to it, for each DKIM-Signature header field whose verification fails for some reason. Note that this processing is done as a reporting extension only; the outcome of the specified DKIM evaluation MUST be otherwise unaffected.
对于由于某种原因验证失败的每个DKIM签名头字段，报表生成器必须应用以下算法，或语义上等效的算法。请注意，此处理仅作为报告扩展进行；否则，指定DKIM评估的结果必须不受影响。
1. If the DKIM-Signature field did not contain a valid "r=" tag, terminate.
1. 如果DKIM签名字段未包含有效的“r=”标记，请终止。
2. Issue a [DNS] TXT query to the name that results from appending the value of the "d=" tag in the DKIM-Signature field to the string "_report._domainkey.". For example, if the DKIM-Signature header field contains "d=example.com", issue a DNS TXT query to "_report._domainkey.example.com".
2. 对将DKIM签名字段中的“d=”标记的值附加到字符串“\u report.\u domainkey.”后得到的名称发出[DNS]TXT查询。例如，如果DKIM签名头字段包含“d=example.com”，则向“\u report.\u domainkey.example.com”发出DNS TXT查询。
3. If the DNS query returns anything other than RCODE 0 (NOERROR), or if multiple TXT records are returned, terminate.
3. 如果DNS查询返回RCODE 0（无错误）以外的任何内容，或者如果返回多个TXT记录，则终止。
4. If the resultant TXT is in several string fragments, concatenate them as described in Section 3.6.2.2 of [DKIM].
4. 如果生成的TXT包含在多个字符串片段中，请按照[DKIM]第3.6.2.2节中的说明连接它们。
5. If the TXT content is syntactically invalid (see Section 3.2), terminate.
5. 如果TXT内容在语法上无效（参见第3.2节），则终止。
6. If the reason for the signature evaluation failure does not match one of the report requests found in the "rr=" tag (or its default value), terminate.
6. 如果签名评估失败的原因与“rr=”标记中的一个报告请求（或其默认值）不匹配，则终止。
7. If a report percentage ("rp=") tag was present, select a random number between 0 and 99, inclusive; if the selected number is not lower than the tag's value, terminate.
7. 如果存在报告百分比（“rp=”）标记，请选择一个介于0和99之间（包括0和99）的随机数；如果所选数字不低于标记的值，则终止。
8. If no "ra=" tag was present, skip this step and the next one. Otherwise, determine the reporting address by extracting the value of the "ra=" tag and appending to it an "@" followed by the domain name found in the "d=" tag of the DKIM-Signature header field.
8. 如果不存在“ra=”标记，请跳过此步骤和下一步。否则，通过提取“ra=”标记的值并在其后面附加“@”，然后在DKIM签名头字段的“d=”标记中找到域名来确定报告地址。
9. Construct and send a report in compliance with Section 6 of this document that includes as its intended recipient the address constructed in the previous step.
9. 按照本文件第6节的规定编制并发送一份报告，报告中应包括在上一步中编制的地址，作为其预期收件人。
10. If the [SMTP] session during which the DKIM signature was evaluated is still active and the SMTP server has not already given its response to the DATA command that relayed the message, and an "rs=" tag was present in the TXT record, the SMTP server SHOULD include the decoded string found in the "rs=" tag in its SMTP reply to the DATA command.
10. 如果评估DKIM签名的[SMTP]会话仍然处于活动状态，并且SMTP服务器尚未对转发消息的数据命令做出响应，并且TXT记录中存在“rs=”标记，则SMTP服务器应在其对数据命令的SMTP回复中包含“rs=”标记中找到的解码字符串。
In order to thwart attacks that seek to convert report generators into unwitting denial-of-service attack participants, a report generator SHOULD NOT issue more than one report to any given domain as a result of a single message. Further, a report generator SHOULD establish an upper bound on the number of reports a single message can generate overall. For example, a message with three invalid signatures, two from example.com and one from example.net, would generate at most one report to each of those domains.
为了阻止试图将报表生成器转换为无意拒绝服务攻击参与者的攻击，报表生成器不应因一条消息向任何给定域发出多个报表。此外，报告生成器应建立单个消息可以生成的报告总数的上限。例如，一封包含三个无效签名（两个来自example.com，一个来自example.net）的邮件最多会向这些域中的每个域生成一份报告。
This algorithm has the following advantages over previous pre-standardization implementations, such as early versions of [OPENDKIM]:
与以前的预标准化实现（如早期版本的[OPENDKIM]）相比，该算法具有以下优势：
a. If the DKIM signature fails to verify, no additional DNS check is made to see if reporting is requested; the request is active in that it is included in the DKIM-Signature header field. (Previous implementations included the reporting address in the DKIM key record, which is not queried for certain failure cases. This meant, for full reporting, that the key record had to be retrieved even when it was not otherwise necessary.)
a. 如果DKIM签名无法验证，则不进行额外的DNS检查以查看是否请求报告；请求处于活动状态，因为它包含在DKIM签名头字段中。（以前的实现包括DKIM密钥记录中的报告地址，在某些故障情况下不会查询该地址。这意味着，对于完整报告，即使在没有其他必要的情况下，也必须检索密钥记录。）
b. The request is confirmed by the presence of a corresponding TXT record in the DNS, since the Signer thus provides the parameters required to construct and send the report. This means a malicious Signer cannot falsely assert that someone else wants failure reports and cause unwanted mail to be generated. It can cause additional DNS traffic against the domain listed in the "d=" signature tag, but negative caching of the requested DNS record will help to mitigate this issue.
b. 该请求通过DNS中存在相应的TXT记录来确认，因为签名者因此提供构造和发送报告所需的参数。这意味着恶意签名者不能错误地断言其他人想要失败报告并导致生成不需要的邮件。它可能会对“d=”签名标记中列出的域造成额外的DNS流量，但对请求的DNS记录进行负面缓存将有助于缓解此问题。
c. It is not possible for a Signer to direct reports to an email address outside of its own domain, preventing distributed email-based denial-of-service attacks.
c. 签名者不可能将报告直接发送到自己域之外的电子邮件地址，从而防止基于电子邮件的分布式拒绝服务攻击。
See Section 8.4 for some considerations regarding limitations of this mechanism.
有关该机制限制的一些注意事项，请参见第8.4节。
A domain name owner employing Author Domain Signing Practices [ADSP] may also want to know when messages are received without valid author domain signatures. Currently, there is no such mechanism defined.
采用作者域签名实践[ADSP]的域名所有者可能还想知道何时收到没有有效作者域签名的消息。目前，还没有定义这样的机制。
This section adds the following optional "tags" (as defined in [ADSP]) to the DKIM ADSP records, using the form defined in that specification:
本节使用该规范中定义的格式，将以下可选“标记”（如[ADSP]中定义）添加到DKIM ADSP记录中：
ra= Reporting Address (plain-text; OPTIONAL; no default). The value MUST be a dkim-quoted-printable string containing the local-part of an email address to which a report SHOULD be sent when mail claiming to be from this domain failed the verification algorithm described in [ADSP], in particular because a message arrived without a signature that validates, which contradicts what the ADSP record claims. The value MUST be interpreted as a local-part only. To construct the actual address to which the report is sent, the Verifier simply appends to this value an "@" followed by the domain whose policy was queried in order to evaluate the sender's ADSP, i.e., the RFC5322.From domain of the message under evaluation. Therefore, a Signer making use of this extension tag MUST ensure that an email address thus constructed can receive reports generated as described in Section 6.
ra=报告地址（纯文本；可选；无默认值）。该值必须是dkim引用的可打印字符串，包含电子邮件地址的本地部分，当声称来自该域的邮件未能通过[ADSP]中所述的验证算法时，报告应发送到该电子邮件地址，特别是因为到达的邮件没有验证签名，这与ADSP记录声称的内容相矛盾。该值必须仅解释为本地部分。为了构造报告发送到的实际地址，验证器只需在该值后面附加一个“@”，后跟被查询策略的域，以评估发送者的ADSP，即被评估消息的域RFC5322。因此，使用此扩展标记的签名者必须确保这样构造的电子邮件地址能够接收第6节所述生成的报告。
ABNF:
荷兰银行：
adsp-ra-tag = %x72.61 *WSP "=" dkim-quoted-printable
; "ra=..." (lower-case only for the tag name)
adsp-ra-tag = %x72.61 *WSP "=" dkim-quoted-printable
; "ra=..." (lower-case only for the tag name)
rp= Requested Report Percentage (plain-text; OPTIONAL; default is "100"). The value is a single integer from 0 to 100 inclusive that indicates what percentage of incidents of ADSP evaluation failures, selected at random, are to cause reports to be generated. The report generator SHOULD NOT issue reports for more than the requested percentage of incidents. An exception to this might be some out-of-band arrangement between two parties to override it with some mutually agreed value. Report generators MAY make use of the "Incidents:" field in [ARF] to indicate that there are more reportable incidents than there are reports.
rp=请求的报告百分比（纯文本；可选；默认值为“100”）。该值是一个从0到100（含0到100）的整数，表示随机选择的ADSP评估失败事件的百分比将导致生成报告。报告生成器发布的报告不应超过请求的事件百分比。例外情况可能是双方之间的一些带外安排，以某种相互商定的价值覆盖该协议。报告生成器可以使用[ARF]中的“事件：”字段来表示可报告的事件多于报告。
ABNF:
荷兰银行：
adsp-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
; "rp=..." (lower-case only)
adsp-rp-tag = %x72.70 *WSP "=" *WSP 1*3DIGIT
; "rp=..." (lower-case only)
rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 5.2 for a list of valid tokens.
rr=请求的报告（纯文本；可选；默认为“全部”）。该值必须是以冒号分隔的标记列表，表示需要报告的条件。有关有效令牌的列表，请参见第5.2节。
ABNF:
荷兰银行：
adsp-rr-type = ( "all" / "o" / "p" / "s" / "u" )
adsp-rr-tag = %x72.72 *WSP "=" *WSP adsp-rr-type
*WSP *( ":" *WSP adsp-rr-type )
; "rr=..." (lower-case only for the tag name)
adsp-rr-type = ( "all" / "o" / "p" / "s" / "u" )
adsp-rr-tag = %x72.72 *WSP "=" *WSP adsp-rr-type
*WSP *( ":" *WSP adsp-rr-type )
; "rr=..." (lower-case only for the tag name)
rs= Requested SMTP Error String (plain-text; OPTIONAL; no default). The value is a string the signing domain requests be included in [SMTP] error strings when messages are rejected during a single SMTP session.
rs=请求的SMTP错误字符串（纯文本；可选；无默认值）。该值是一个字符串，在单个SMTP会话期间拒绝邮件时，签名域请求将包含在[SMTP]错误字符串中。
ABNF:
荷兰银行：
adsp-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
; "rs=..." (lower-case only for the tag name)
adsp-rs-tag = %x72.73 *WSP "=" dkim-quoted-printable
; "rs=..." (lower-case only for the tag name)
In the absence of an "ra=" tag, the "rp=" and "rr=" tags MUST be ignored, and the report generator MUST NOT issue a report.
如果没有“ra=”标记，则必须忽略“rp=”和“rr=”标记，并且报告生成器不得发布报告。
The "rr" tags defined above allow a Signer to specify the types of errors about which it is interested in receiving reports. This section defines the error types and corresponding token values.
上面定义的“rr”标记允许签名者指定其对接收报告感兴趣的错误类型。本节定义错误类型和相应的令牌值。
Verifiers MUST NOT generate reports for incidents that do not match a requested report and MUST ignore requests for reports not included in this list.
验证者不得为与请求的报告不匹配的事件生成报告，并且必须忽略对未包含在此列表中的报告的请求。
The following report requests are defined for DKIM keys:
为DKIM密钥定义了以下报告请求：
all All reports are requested.
要求提交所有报告。
d Reports are requested for signature evaluation errors that resulted from DNS issues (e.g., key retrieval problems).
d对于由DNS问题（例如，关键检索问题）导致的签名评估错误，需要提交报告。
o Reports are requested for any reason related to DKIM signature evaluation not covered by other report requests listed here.
o 由于与DKIM签名评估相关的任何原因而要求提交报告，但此处列出的其他报告要求并未涵盖。
p Reports are requested for signatures that are rejected for local policy reasons at the Verifier that are related to DKIM signature evaluation.
p对于因当地政策原因而被拒绝的签名，在与DKIM签名评估相关的验证者处要求提交报告。
s Reports are requested for signature or key syntax errors.
请求的报告存在签名或密钥语法错误。
u Reports are requested for signatures that include unknown tags in the signature field.
对于签名字段中包含未知标记的签名，请求u报告。
v Reports are requested for signature verification failures or body hash mismatches.
请求v报告签名验证失败或正文哈希不匹配。
x Reports are requested for signatures rejected by the Verifier because the expiration time has passed.
由于过期时间已过，验证者拒绝签名，因此请求x个报告。
The following report requests are defined for ADSP records:
为ADSP记录定义了以下报告请求：
all All reports are requested.
要求提交所有报告。
o Reports are requested for any [ADSP]-related failure reason not covered by other report requests listed here.
o 对于此处列出的其他报告请求未涵盖的任何[ADSP]相关故障原因，都会请求报告。
p Reports are requested for messages that are rejected for local policy reasons at the Verifier that are related to [ADSP].
对于由于本地策略原因而被拒绝的与[ADSP]相关的验证程序的消息，将请求p报告。
s Reports are requested for messages that have a valid [DKIM] signature but do not match the published [ADSP] policy.
对于具有有效[DKIM]签名但与发布的[ADSP]策略不匹配的邮件，将请求s报告。
u Reports are requested for messages that have no valid [DKIM] signature and do not match the published [ADSP] policy.
对于没有有效[DKIM]签名且与发布的[ADSP]策略不匹配的邮件，将请求u报告。
This section describes the process for generating and sending reports in accordance with the request of the Signer and/or sender as described above.
本节描述了根据上述签名者和/或发送者的请求生成和发送报告的过程。
All reports generated as a result of requests contained in these extension parameters MUST be generated in compliance with [ARF] and its extension specific to this work, [ARF-AUTHFAIL]. Moreover, because abuse reports from unverified sources might be handled with some skepticism, report generators are strongly advised to use [DKIM] to sign reports they generate.
由于这些扩展参数中包含的请求而生成的所有报告必须按照[ARF]及其特定于此工作的扩展[ARF-AUTHFAIL]生成。此外，由于来自未经核实来源的滥用报告可能会受到一些怀疑，因此强烈建议报告生成者使用[DKIM]签署他们生成的报告。
Additional guidance about the generation of these reports can be found in [ARF-AS], especially in Section 6.
有关生成这些报告的其他指南，请参见[ARF-AS]，尤其是第6节。
As required by [IANA-CONS], this section contains registry information for the new [DKIM] signature tags and for the new [ADSP] tags. It also creates a DKIM reporting tag registry.
根据[IANA-CONS]的要求，本节包含新[DKIM]签名标签和新[ADSP]标签的注册表信息。它还创建一个DKIM报告标记注册表。
IANA has added the following item to the DKIM Signature Tag Specifications registry:
IANA已将以下项目添加到DKIM签名标签规范注册表：
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| r | (this document) | active |
+------+-----------------+--------+
+------+-----------------+--------+
| TYPE | REFERENCE | STATUS |
+------+-----------------+--------+
| r | (this document) | active |
+------+-----------------+--------+
IANA has added the following items to the DKIM ADSP Specification Tags registry:
IANA已将以下项目添加到DKIM ADSP规范标签注册表中：
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| ra | (this document) |
| rp | (this document) |
| rr | (this document) |
| rs | (this document) |
+------+-----------------+
+------+-----------------+
| TYPE | REFERENCE |
+------+-----------------+
| ra | (this document) |
| rp | (this document) |
| rr | (this document) |
| rs | (this document) |
+------+-----------------+
IANA has created a sub-registry of the DKIM Parameters registry called "DKIM Reporting Tag Registry". Additions to this registry follow the "Specification Required" rules, with the following columns required for all registrations:
IANA已经创建了DKIM参数注册表的子注册表，称为“DKIM报告标记注册表”。此注册表的添加遵循“要求规范”规则，所有注册都需要以下列：
Tag: The name of the tag being used in reporting records
标记：报告记录中使用的标记的名称
Reference: The document that specifies the tag being defined
引用：指定要定义的标记的文档
Status: The status of the tag's current use -- either "active" indicating active use, or "historic" indicating discontinued or deprecated use
状态：标记当前使用的状态——“活动”表示活动使用，或“历史”表示已停止或不推荐使用
The initial registry entries are as follows:
初始注册表项如下所示：
+-----+-----------------+--------+
| TAG | REFERENCE | STATUS |
+-----+-----------------+--------+
| ra | (this document) | active |
| rp | (this document) | active |
| rr | (this document) | active |
| rs | (this document) | active |
+-----+-----------------+--------+
+-----+-----------------+--------+
| TAG | REFERENCE | STATUS |
+-----+-----------------+--------+
| ra | (this document) | active |
| rp | (this document) | active |
| rr | (this document) | active |
| rs | (this document) | active |
+-----+-----------------+--------+
Security issues with respect to these reports are similar to those found in [DSN].
这些报告的安全问题与[DSN]中的类似。
Implementers are advised to consider the Security Considerations sections of [DKIM], [ADSP], [ARF-AS], and [ARF-AUTHFAIL]. Many security issues related to this document are already covered in those documents.
建议实施者考虑[DIMK]、[ADSP]、[ARF-As]和[ARF AuthValu]的安全考虑部分。与本文档相关的许多安全问题已包含在这些文档中。
It is impossible to predict the volume of reports this facility will generate when enabled by a report receiver. An implementer ought to anticipate substantial volume, since the amount of abuse occurring at receivers cannot be known ahead of time, and may vary rapidly and unpredictably.
当由报告接收器启用时，无法预测此工具将生成的报告量。实施者应该预测大量的滥用，因为在接收者处发生的滥用量无法提前知道，并且可能会迅速变化，不可预测。
Some threats caused by deliberate misuse of this error-reporting mechanism are discussed in Section 3.3, but they warrant further discussion here.
第3.3节讨论了故意误用此错误报告机制造成的一些威胁，但值得在此进一步讨论。
The presence of the DNS record that indicates willingness to accept reports opens the recipient to abuse. In particular, it is possible for an attacker to attempt to cause a flood of reports toward the domain identified in a signature's "d=" tag in one of these ways:
存在表明愿意接受报告的DNS记录会导致收件人滥用。特别是，攻击者可能会试图通过以下方式之一，向签名的“d=”标记中标识的域发送大量报告：
1. Alter existing DKIM-Signature header fields by adding an "r=y" tag (and possibly altering the "d=" tag to point at the target domain);
1. 通过添加“r=y”标记（并可能将“d=”标记更改为指向目标域），更改现有DKIM签名头字段；
2. Add a new but bogus signature bearing an "r=y" tag and a "d=" tag pointing at the target domain;
2. 添加一个新的伪签名，带有指向目标域的“r=y”标记和“d=”标记；
3. Generate a completely new message bearing an "r=y" tag and a "d=" tag pointing at the target domain.
3. 生成一条带有“r=y”标记和指向目标域的“d=”标记的全新消息。
Consider, for example, the situation where an attacker sends out a multi-million-message spam run and includes in the messages a fake DKIM signature containing "d=example.com; r=y". It won't matter that those signatures couldn't possibly be real: each will fail verification, and any implementations that support this specification will report those failures, in the millions and in short order, to example.com.
例如，考虑攻击者发出数百万消息垃圾邮件运行的情况，并在消息中包含一个伪造的DKIM签名，该签名包含“d＝Excel；com＝y”。这些签名不可能是真实的并不重要：每个签名都会在验证中失败，任何支持此规范的实现都会在短时间内向example.com报告数百万次的失败。
Implementers are therefore strongly advised not to advertise the DNS record specified in this document except when failure reports are desired. Upon doing so, unexpected traffic volumes and attacks should be anticipated.
因此，强烈建议实施者不要公布本文档中指定的DNS记录，除非需要故障报告。这样做时，应预料到意外的通信量和攻击。
Negative caching offers some protection against this pattern of abuse, although it will work only as long as the negative time-to-live on the relevant SOA record in the DNS.
负缓存提供了一些防止这种滥用模式的保护，尽管它只在DNS中相关SOA记录的负生存时间内起作用。
Positive caching of this DNS reply also means that turning off the flow of reports by removing the record is not likely to have an immediate effect. A low time-to-live on the record needs to be considered.
此DNS回复的正向缓存还意味着通过删除记录来关闭报告流不太可能立即生效。需要考虑记录在案的时间较短。
An attacker can craft fraudulent DKIM-Signature fields on messages, without using "r=" tags, and avoid having these reported. The procedure described in Section 3.3 does not permit the detection and reporting of such cases.
攻击者无需使用“r=”标记，即可在邮件上创建欺诈性DKIM签名字段，并避免报告这些字段。第3.3节所述程序不允许检测和报告此类案件。
It might be useful to some Signers to receive such reports, but the mechanism does not support it. To offer such support, a Verifier would have to violate the first step in the procedure and continue even in the absence of an "r=" tag. Although that would enable the desired report, it would also create a possible denial-of-service attack: such Verifiers would always look for the reporting TXT record, so a generator of fraudulent messages could simply send a large volume of messages without an "r=" tag to a number of destinations. To avoid that outcome, reports of fraudulent DKIM-Signature header fields are not possible using the published mechanism.
接收此类报告可能对某些签名者有用，但该机制不支持。要提供这种支持，验证者必须违反程序的第一步，即使没有“r=”标签，也必须继续。尽管这将启用所需的报告，但也可能会造成拒绝服务攻击：此类验证器将始终查找报告TXT记录，因此欺诈消息的生成器可以简单地向多个目的地发送大量没有“r=”标记的消息。为了避免这种结果，不可能使用发布机制报告欺诈性DKIM签名头字段。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 5234，2008年1月。
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[ADSP]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月。
[ARF] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[ARF]Shafranovich，Y.，Levine，J.，和M.Kucherawy，“电子邮件反馈报告的可扩展格式”，RFC 59652010年8月。
[ARF-AS] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, June 2012.
[ARF-AS]Falk，J.和M.Kucherawy，Ed.，“电子邮件反馈报告的创建和使用：滥用报告格式（ARF）的适用性声明”，RFC 66502012年6月。
[ARF-AUTHFAIL] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
[ARF-AUTHFAIL]Fontana，H.，“使用滥用报告格式的认证失败报告”，RFC 65912012年4月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA-CONS]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[OPENDKIM] Kucherawy, M., "OpenDKIM -- Open Source DKIM Library and Filter", August 2009, <http://www.opendkim.org>.
[OPENDKIM]Kucherawy，M.，“OPENDKIM——开源DKIM库和过滤器”，2009年8月<http://www.opendkim.org>.
The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Steve Atkins, Monica Chew, Dave Crocker, Tim Draegen, Frank Ellermann, J.D. Falk, John Levine, Scott Kitterman, and Andrew Sullivan.
作者希望感谢以下各方对本提案的审查和建设性批评：史蒂夫·阿特金斯、莫妮卡·周、戴夫·克罗克、蒂姆·德雷根、弗兰克·埃勒曼、J.D.福尔克、约翰·莱文、斯科特·基特曼和安德鲁·沙利文。
This section contains examples of the use of each of the extensions defined by this document.
本节包含使用本文档定义的每个扩展的示例。
This example shows a DKIM-Signature field using the extension tag defined by this document:
此示例显示使用此文档定义的扩展标记的DKIM签名字段：
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=example.com; s=jan2012; r=y;
h=from:to:subject:date:message-id;
bh=YJAYwiNdc3wMh6TD8FjVhtmxaHYHo7Z/06kHQYvQ4tQ=;
b=jHF3tpgqr6nH/icHKIqFK2IJPtCLF0CRJaz2Hj1Y8yNwTJ
IMYIZtLccho3ymGF2GYqvTl2nP/cn4dH+55rH5pqkWNnuJ
R9z54CFcanoKKcl9wOZzK9i5KxM0DTzfs0r8
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=example.com; s=jan2012; r=y;
h=from:to:subject:date:message-id;
bh=YJAYwiNdc3wMh6TD8FjVhtmxaHYHo7Z/06kHQYvQ4tQ=;
b=jHF3tpgqr6nH/icHKIqFK2IJPtCLF0CRJaz2Hj1Y8yNwTJ
IMYIZtLccho3ymGF2GYqvTl2nP/cn4dH+55rH5pqkWNnuJ
R9z54CFcanoKKcl9wOZzK9i5KxM0DTzfs0r8
Example 1: DKIM-Signature Field Using This Extension
示例1：使用此扩展名的DKIM签名字段
This example DKIM-Signature field contains the "r=" tag that indicates reports are requested on verification failure.
此示例DKIM签名字段包含“r=”标记，表示在验证失败时请求报告。
Assuming the public key retrieved from the DNS and processed according to [DKIM] would determine that the signature is invalid, a TXT query will be sent to "_report._domainkey.example.com" to retrieve a reporting address and other report parameters as described in Section 3.3.
假设从DNS检索并根据[DKIM]处理的公钥将确定签名无效，TXT查询将发送到“_report._domainkey.example.com”以检索报告地址和其他报告参数，如第3.3节所述。
An example DKIM Reporting TXT record as defined by this document is as follows:
本文件定义的DKIM报告TXT记录示例如下：
ra=dkim-errors; rp=100; rr=v:x
ra=dkim-errors; rp=100; rr=v:x
Example 2: Example DKIM Reporting TXT Record
示例2：示例DKIM报告TXT记录
This example, continuing from the previous one, shows a message that might be found at "_report._domainkey.example.com" in a TXT record. It makes the following requests:
本例继续上一个示例，显示了一条消息，该消息可能位于TXT记录中的“\u report.\u domainkey.example.com”。它提出以下要求：
o Reports about signature evaluation failures should be sent to the address "dkim-errors" at the Signer's domain;
o 关于签名评估失败的报告应发送到签名者域的“dkim错误”地址；
o All incidents (100%) should be reported;
o 应报告所有事件（100%）；
o Only reports about signature verification failures and expired signatures should be generated.
o 只应生成有关签名验证失败和过期签名的报告。
This example shows a DKIM ADSP record using the extensions defined by this document:
此示例显示使用本文档定义的扩展名的DKIM ADSP记录：
dkim=all; ra=dkim-adsp-errors; rr=u
dkim=all; ra=dkim-adsp-errors; rr=u
Example 3: DKIM ADSP Record Using These Extensions
示例3：使用这些扩展名的DKIM ADSP记录
This example ADSP record makes the following assertions:
此示例ADSP记录做出以下断言：
o The sending domain (i.e., the one that is advertising this policy) signs all mail it sends;
o 发送域（即发布此策略的域）对其发送的所有邮件进行签名；
o Reports about ADSP evaluation failures should be sent to the address "dkim-adsp-errors" at the Author's domain;
o 有关ADSP评估失败的报告应发送至作者所在域的“dkim ADSP错误”地址；
o Only reports about unsigned messages should be generated.
o 只应生成有关未签名邮件的报告。
Author's Address
作者地址
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
Murray S. Kucherawy CuldM标记128国王圣，第二楼旧金山，CA 94107美国
Phone: +1 415 946 3800
EMail: superuser@gmail.com
Phone: +1 415 946 3800
EMail: superuser@gmail.com