Internet Engineering Task Force (IETF) H. Fontana
Request for Comments: 6591 April 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) H. Fontana
Request for Comments: 6591 April 2012
Category: Standards Track
ISSN: 2070-1721
Authentication Failure Reporting Using the Abuse Reporting Format
使用滥用报告格式的身份验证失败报告
Abstract
摘要
This memo registers an extension report type for the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks.
此备忘录为滥用报告格式（ARF）注册扩展报告类型，影响多个注册表，用于生成有关未通过一个或多个电子邮件验证检查的邮件的接收时间报告。
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/rfc6591.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6591.
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 ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Email Architecture .........................................3
2.3. Base64 .....................................................3
2.4. Technologies ...............................................3
3. ARF Extension for Authentication Failure Reporting ..............3
3.1. New ARF Feedback Type ......................................4
3.2. New ARF Header Field Names .................................5
3.2.1. Required for All Reports ............................5
3.2.2. Optional for All Reports ............................5
3.2.3. Required for DKIM Reports ...........................5
3.2.4. Optional for DKIM Reports ...........................6
3.2.5. Required for ADSP Reports ...........................6
3.2.6. Required for SPF Reports ............................6
3.3. Authentication Failure Types ...............................6
4. Syntax for Added ARF Header Fields ..............................7
5. IANA Considerations .............................................8
5.1. Updates to ARF Feedback Types ..............................8
5.2. Updates to ARF Header Field Names ..........................8
6. Security Considerations ........................................10
6.1. Inherited Considerations ..................................10
6.2. Forgeries .................................................10
6.3. Automatic Generation ......................................11
6.4. Envelope Sender Selection .................................11
6.5. Reporting Multiple Incidents ..............................11
6.6. Redaction of Data in DKIM Reports .........................12
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................13
Appendix A. Acknowledgements ......................................14
Appendix B. Example ...............................................14
B.1. Example Use of ARF Extension Headers .......................14
1. Introduction ....................................................2
2. Definitions .....................................................3
2.1. Key Words ..................................................3
2.2. Email Architecture .........................................3
2.3. Base64 .....................................................3
2.4. Technologies ...............................................3
3. ARF Extension for Authentication Failure Reporting ..............3
3.1. New ARF Feedback Type ......................................4
3.2. New ARF Header Field Names .................................5
3.2.1. Required for All Reports ............................5
3.2.2. Optional for All Reports ............................5
3.2.3. Required for DKIM Reports ...........................5
3.2.4. Optional for DKIM Reports ...........................6
3.2.5. Required for ADSP Reports ...........................6
3.2.6. Required for SPF Reports ............................6
3.3. Authentication Failure Types ...............................6
4. Syntax for Added ARF Header Fields ..............................7
5. IANA Considerations .............................................8
5.1. Updates to ARF Feedback Types ..............................8
5.2. Updates to ARF Header Field Names ..........................8
6. Security Considerations ........................................10
6.1. Inherited Considerations ..................................10
6.2. Forgeries .................................................10
6.3. Automatic Generation ......................................11
6.4. Envelope Sender Selection .................................11
6.5. Reporting Multiple Incidents ..............................11
6.6. Redaction of Data in DKIM Reports .........................12
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................13
Appendix A. Acknowledgements ......................................14
Appendix B. Example ...............................................14
B.1. Example Use of ARF Extension Headers .......................14
The Abuse Reporting Format [ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye towards automating both the generation and consumption of those reports. There is now also a desire to extend the ARF to include the reporting of messages that fail to authenticate using known message authentication methods, such as DomainKeys Identified Mail [DKIM] and Sender Policy Framework [SPF], as these are sometimes evidence of abuse that can be detected and reported through automated means. The same mechanism can be used to convey forensic information about the
滥用报告格式[ARF]定义了一种用于在消息传递基础设施中发送滥用报告的消息格式，旨在自动化这些报告的生成和使用。现在还希望将ARF扩展到包括使用已知消息身份验证方法（如域密钥识别邮件[DKIM]和发件人策略框架[SPF]）无法进行身份验证的消息的报告，因为这些有时是可以通过自动化手段检测和报告的滥用证据。同样的机制也可用于传达有关犯罪的法医信息
specific reason the authentication method failed. Thus, this memo presents such extensions to ARF that allow for detailed reporting of message authentication method failures.
身份验证方法失败的特定原因。因此，本备忘录提供了ARF的此类扩展，允许详细报告消息身份验证方法失败。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
This memo uses some terms whose definitions and descriptions can be found in [EMAIL-ARCH].
本备忘录使用了一些术语，其定义和说明可在[EMAIL-ARCH]中找到。
Base64 is defined in Section 4 of [BASE64].
Base64在[Base64]的第4节中定义。
The values that are base64 encodings MAY contain folding whitespace (FWS) for formatting purposes as per the usual header field wrapping defined in [MAIL]. During decoding, any characters not in the base64 alphabet are ignored so that such line wrapping does not harm the value. The ABNF token "FWS" is defined in [DKIM]. No other extensions to the valid base64 character set are permitted.
base64编码的值可能包含折叠空格（FWS），以便按照[MAIL]中定义的常用头字段包装进行格式化。在解码过程中，将忽略base64字母表中未包含的任何字符，以便此类换行不会损害该值。ABNF标记“FWS”在[DKIM]中定义。不允许对有效的base64字符集进行其他扩展。
There are technologies in email security that provide authentication services and some that do authorization. These are often conflated. A discussion that is useful for establishing context can be found in Section 1.5.2 of [AUTH-RESULTS].
电子邮件安全中有一些技术提供身份验证服务，有些技术提供授权。这些经常被混为一谈。可在[AUTH-RESULTS]第1.5.2节中找到有助于建立上下文的讨论。
The current report format defined in [ARF] lacks some specific features required to do effective email authentication failure reporting. This section defines extensions to ARF to accommodate this requirement.
[ARF]中定义的当前报告格式缺少执行有效电子邮件身份验证失败报告所需的一些特定功能。本节定义了ARF的扩展以满足此要求。
A single report describes a single email authentication failure. Multiple reports MAY be used to report multiple failures for a single message.
单个报告描述单个电子邮件身份验证失败。多个报告可用于报告单个消息的多个故障。
A new feedback type, "auth-failure", is defined in this document as an extension, per Section 7.3 of [ARF].
根据[ARF]第7.3节，本文件将新反馈类型“认证失败”定义为扩展。
A message that uses this feedback type has the following modified header field requirements for the second (machine-parseable) [MIME] part of the report:
使用此反馈类型的消息对报告的第二部分（机器可解析）[MIME]具有以下修改的标题字段要求：
Authentication-Results: Syntax as specified in [AUTH-RESULTS]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present, but it MUST reflect only a single authentication method's result.
验证结果：语法如[AUTH-Results]中所述。此外，[ARF]指定此字段为可选字段，最多显示一次；对于此扩展，此字段必须存在，但它必须仅反映单个身份验证方法的结果。
Original-Envelope-Id: Syntax as specified in [ARF]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field's inclusion is RECOMMENDED, where that value is available, to aid in diagnosing the authentication failure.
原始信封Id:[ARF]中指定的语法。此外，[ARF]指定此字段为可选字段，最多显示一次；对于此扩展，如果该值可用，建议包含此字段，以帮助诊断身份验证失败。
Original-Mail-From: Syntax as specified in [ARF]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field's inclusion is RECOMMENDED, where that value is available, to aid in diagnosing the authentication failure.
原始邮件发件人：[ARF]中指定的语法。此外，[ARF]指定此字段为可选字段，最多显示一次；对于此扩展，如果该值可用，建议包含此字段，以帮助诊断身份验证失败。
Source-IP: Syntax as specified in [ARF]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field's inclusion is RECOMMENDED, where that value is available, to aid in diagnosing the authentication failure.
源IP:[ARF]中指定的语法。此外，[ARF]指定此字段为可选字段，最多显示一次；对于此扩展，如果该值可用，建议包含此字段，以帮助诊断身份验证失败。
Reported-Domain: Syntax as specified in [ARF]. Furthermore, [ARF] specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present if such a value is available.
报告的域：[ARF]中指定的语法。此外，[ARF]指定此字段为可选字段，最多显示一次；对于此扩展，如果此值可用，则必须存在此字段。
Delivery-Result: As specified in Section 3.2.2. This field is OPTIONAL, but it MUST NOT appear more than once. If present, it SHOULD indicate the outcome of the message in some meaningful way, but it MAY be set to "other" for local policy reasons.
交付结果：如第3.2.2节所述。此字段是可选的，但不能出现多次。如果存在，则应以某种有意义的方式指示消息的结果，但出于当地政策原因，可能会将其设置为“其他”。
The third MIME part of the message is either of type "message/rfc822" (as defined in [MIME-TYPES]) or of type "text/rfc822-headers" (as defined in [REPORT]) and contains a copy of the entire header block from the original message. This part MUST be included (contrary to [REPORT], which makes it optional).
消息的第三个MIME部分是类型“message/rfc822”（如[MIME-TYPES]中所定义）或类型“text/rfc822 headers”（如[REPORT]中所定义），包含原始消息的整个头块的副本。必须包括该部分（与[报告]相反，该报告是可选的）。
For privacy reasons, report generators might need to redact portions of a reported message, such as an identifier or address associated with the end user whose complaint action resulted in the report. A discussion of relevant issues and a suggested method for doing so can be found in [RFC6590].
出于隐私原因，报告生成器可能需要编辑报告消息的部分内容，例如与最终用户相关联的标识符或地址，最终用户的投诉行为导致了报告。[RFC6590]中有相关问题的讨论和建议的解决方法。
The following new ARF field names are defined as extensions to Section 3.1 of [ARF].
以下新的ARF字段名定义为[ARF]第3.1节的扩展。
Auth-Failure: Indicates the failure from an email authentication method that is being reported. The list of valid values is enumerated in Section 3.3.
身份验证失败：表示正在报告的电子邮件身份验证方法的失败。第3.3节列举了有效值列表。
Delivery-Result: The final message disposition that was enacted by the ADministrative Management Domain (ADMD) generating the report. It MUST NOT appear more than once. Possible values are as follows:
传递结果：由生成报告的管理管理域（ADMD）制定的最终邮件处置。它不能出现多次。可能的值如下所示：
delivered: The message was delivered (not specific as to where).
已传递：消息已传递（不特定于在何处）。
spam: The message was delivered to the recipient's spam folder (or equivalent).
垃圾邮件：邮件已传递到收件人的垃圾邮件文件夹（或等效文件夹）。
policy: The message was not delivered to the intended inbox due to a failure from an email authentication method. The specific action taken is not specified.
策略：由于电子邮件身份验证方法失败，邮件未送达预期收件箱。未指定所采取的具体行动。
reject: The message was rejected.
拒绝：消息被拒绝。
other: The message had a final disposition not covered by one of the above values.
其他：消息的最终处置不包含在上述值中。
DKIM-Domain: The domain that signed the message, taken from the "d=" tag of the signature.
DKIM域：对消息进行签名的域，取自签名的“d=”标记。
DKIM-Identity: The identity of the signature that failed verification, taken from the "i=" tag of the signature.
DKIM标识：验证失败的签名的标识，取自签名的“i=”标记。
DKIM-Selector: The selector of the signature that failed verification, taken from the "s=" tag of the signature.
DKIM选择器：验证失败的签名的选择器，取自签名的“s=”标记。
DKIM-Canonicalized-Header: A base64 encoding of the canonicalized header of the message as generated by the verifier.
DKIM规范化标头：验证程序生成的消息规范化标头的base64编码。
DKIM-Canonicalized-Body: A base64 encoding of the canonicalized body of the message as generated by the verifier. The encoded content MUST be limited to those octets that contribute to the DKIM body hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]).
DKIM规范化正文：由验证器生成的消息规范化正文的base64编码。编码的内容必须限于那些构成DKIM正文哈希的八位字节（即“l=”标记的值；参见[DKIM]第3.7节）。
If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode redacted data, they MUST NOT be included. Otherwise, they SHOULD be included. The data presented there have to be exactly the canonicalized header and body as defined by [DKIM] and computed at the verifier. This is because these fields are intended to aid in identifying message alterations that invalidate DKIM signatures in transit. Including redacted data in them renders the data unusable. (See also Sections 3.1 and 6.6 for further discussion.)
如果DKIM规范化头和DKIM规范化体对编辑的数据进行编码，则不能包含它们。否则，应将其包括在内。此处提供的数据必须是[DKIM]定义并在验证器上计算的规范化标头和正文。这是因为这些字段旨在帮助识别在传输过程中使DKIM签名无效的消息更改。如果在其中包含已编辑的数据，则会导致数据不可用。（进一步讨论请参见第3.1节和第6.6节。）
DKIM-ADSP-DNS: Includes the Author Domain Signing Practices (ADSP) policy used to obtain the verifier's ADSP result. This MUST be formatted per Section 4.2.1 of [ADSP].
DKIM-ADSP-DNS：包括用于获取验证器ADSP结果的作者域签名实践（ADSP）策略。必须按照[ADSP]第4.2.1节对其进行格式化。
SPF-DNS: This field MUST appear once for every SPF record [SPF] used to obtain the SPF result. It MUST include the DNS RRTYPE used, the DNS domain from which the record was retrieved, and the content of that record. The syntax is defined in Section 4.
SPF-DNS：对于用于获取SPF结果的每个SPF记录[SPF]，此字段必须出现一次。它必须包括使用的DNS RRTYPE、从中检索记录的DNS域以及该记录的内容。第4节对语法进行了定义。
The list of defined email authentication failure types used in the "Auth-Failure:" header field (defined above), is as follows:
“Auth failure:”标题字段（定义见上文）中使用的已定义电子邮件身份验证失败类型列表如下：
adsp: The message did not conform to the author domain's published [ADSP] signing practices. The DKIM-ADSP-DNS field MUST be included in the report.
adsp:消息不符合作者域发布的[adsp]签名惯例。报告中必须包含DKIM-ADSP-DNS字段。
bodyhash: The body hash in the signature and the body hash computed by the verifier did not match. The DKIM-Canonicalized-Body field SHOULD be included in the report (see Section 3.2.4).
bodyhash：签名中的正文哈希与验证器计算的正文哈希不匹配。报告中应包括DKIM规范化正文字段（见第3.2.4节）。
revoked: The DKIM key referenced by the signature on the message has been revoked. The DKIM-Domain and DKIM-Selector fields MUST be included in the report.
吊销：消息上签名引用的DKIM密钥已吊销。报告中必须包含DKIM域和DKIM选择器字段。
signature: The DKIM signature on the message did not successfully verify against the header hash and public key. The DKIM-Domain and DKIM-Selector fields MUST be included in the report, and the DKIM-Canonicalized-Header field SHOULD be included in the report (see Section 3.2.4).
签名：消息上的DKIM签名未成功验证标头哈希和公钥。DKIM域和DKIM选择器字段必须包含在报告中，DKIM规范化标题字段应包含在报告中（见第3.2.4节）。
spf: The evaluation of the author domain's SPF record produced a "none", "fail", "softfail", "temperror", or "permerror" result. ("none" is not strictly a failure per [SPF], but a service that demands successful SPF evaluations of clients could treat it like a failure.)
spf：对作者域的spf记录的评估产生了“无”、“失败”、“软失败”、“温度错误”或“permerror”结果。（“none”严格来说并不是[SPF]的失败，但要求对客户端进行成功的SPF评估的服务可能会将其视为失败。）
Supplementary data MAY be included in the form of comments compliant with [MAIL]. For example, "Auth-Failure: adsp" could be augmented by a comment to indicate that the failed message was rejected because it was not signed when it should have been. See Appendix B for an example.
补充数据可能以符合[邮件]的注释形式包含。例如，“Auth Failure:adsp”可以添加一条注释，以指示失败的消息被拒绝，因为它在应该被拒绝时没有被签名。有关示例，请参见附录B。
The [ABNF] definitions for the new fields are as follows:
新字段的[ABNF]定义如下：
auth-failure = "Auth-Failure:" [CFWS]
( "adsp" / "bodyhash" / "revoked" /
"signature" / "spf" ) [CFWS] CRLF
; "CFWS" is defined in [MAIL]
auth-failure = "Auth-Failure:" [CFWS]
( "adsp" / "bodyhash" / "revoked" /
"signature" / "spf" ) [CFWS] CRLF
; "CFWS" is defined in [MAIL]
delivery-result = "Delivery-Result:" [CFWS]
( "delivered" / "spam" / "policy" /
"reject" / "other" ) [CFWS] CRLF
delivery-result = "Delivery-Result:" [CFWS]
( "delivered" / "spam" / "policy" /
"reject" / "other" ) [CFWS] CRLF
dkim-header = "DKIM-Canonicalized-Header:" [CFWS] base64string CRLF ; "base64string" is defined in [DKIM]
dkim header=“dkim规范化头：”[CFWS]base64string CRLF；[DKIM]中定义了“base64string”
dkim-sig-domain = "DKIM-Domain:" [CFWS] domain-name [CFWS] CRLF ; "domain-name" is defined in [DKIM]
dkim sig domain=“dkim domain:[CFWS]域名[CFWS]CRLF；“域名”的定义见[DKIM]
dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@" domain-name [CFWS] CRLF ; "local-part" is defined in [MAIL]
dkim identity=“dkim identity:[CFWS][local part]“@”域名[CFWS]CRLF；“本地部分”在[邮件]中定义
dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF ; "selector" is defined in [DKIM]
dkim选择器=“dkim选择器：”[CFWS]选择器[CFWS]CRLF；“选择器”的定义见[DKIM]
dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS] quoted-string [CFWS] CRLF ; "quoted-string" is defined in [MAIL]
dkim adsp dns=“dkim-adsp-dns:“[CFWS]带引号的字符串[CFWS]CRLF；“引用字符串”在[邮件]中定义
dkim-body = "DKIM-Canonicalized-Body:" [CFWS] base64string CRLF
dkim body=“dkim规范化正文：”[CFWS]base64string CRLF
dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS] quoted-string [CFWS] CRLF
dkim selector dns=“dkim selector dns:[CFWS]带引号的字符串[CFWS]CRLF
spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS]
domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF
spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS]
domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF
As required by [IANA], this section contains registry information for the extension to [ARF].
根据[IANA]的要求，本节包含[ARF]扩展的注册表信息。
The following feedback type has been added to the Feedback Report Type Values registry:
以下反馈类型已添加到反馈报告类型值注册表：
Feedback Type: auth-failure Description: email authentication failure report Published in: [RFC6591] Status: current
反馈类型：身份验证失败描述：在[RFC6591]中发布的电子邮件身份验证失败报告状态：当前
The following headers are added to the Feedback Report Header Fields registry:
将以下标题添加到“反馈报告标题字段”注册表中：
Field Name: Auth-Failure Description: Type of email authentication method failure Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：身份验证失败描述：电子邮件身份验证方法失败类型多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: Delivery-Result Description: Final disposition of the subject message Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：传递结果说明：主题消息的最终处理多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-ADSP-DNS Description: Retrieved DKIM ADSP record Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM-ADSP-DNS描述：检索到的DKIM ADSP记录多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-Canonicalized-Body Description: Canonicalized body, per DKIM Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM规范化正文描述：规范化正文，每个DKIM多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-Canonicalized-Header Description: Canonicalized header, per DKIM Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM规范化标题说明：规范化标题，每个DKIM多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-Domain Description: DKIM signing domain from "d=" tag Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM域描述：DKIM签名域来自“d=”标记多个外观：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-Identity Description: Identity from DKIM signature Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM标识说明：来自DKIM签名的标识多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-Selector Description: Selector from DKIM signature Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM选择器说明：来自DKIM签名的选择器多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: DKIM-Selector-DNS Description: Retrieved DKIM key record Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：DKIM选择器DNS描述：检索到的DKIM密钥记录多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
Field Name: SPF-DNS Description: Retrieved SPF record Multiple Appearances: No Related "Feedback-Type": auth-failure Published in: [RFC6591] Status: current
字段名称：SPF-DNS说明：检索到的SPF记录多次出现：无相关“反馈类型”：身份验证失败发布于：[RFC6591]状态：当前
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], [SPF], and [ARF].
建议实施者考虑[DIMK]、[ASP]、[SPF]和[ARF]的安全考虑部分。
These reports can be forged as easily as ordinary Internet electronic mail. User agents and automatic mail-handling facilities (such as mail distribution list exploders) that wish to make automatic use of Delivery Status Notifications (DSNs) of any kind should take appropriate precautions to minimize the potential damage from denial-of-service attacks.
这些报告可以像普通的互联网电子邮件一样容易伪造。希望自动使用任何类型的传递状态通知（DSN）的用户代理和自动邮件处理设施（如邮件分发列表爆炸器）应采取适当的预防措施，将拒绝服务攻击的潜在损害降至最低。
Security threats related to forged DSNs include the sending of
与伪造DSN相关的安全威胁包括发送
a. A falsified email authentication method failure notification when the message was in fact delivered to the indicated recipient;
a. 当邮件实际送达指定收件人时，虚假的电子邮件身份验证方法失败通知；
b. Falsified signature information, such as selector, domain, etc.
b. 伪造的签名信息，如选择器、域等。
Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM. On the other hand, if there's a problem with the DKIM infrastructure at the verifier, signing DKIM failure reports might produce reports that aren't trusted or even accepted by their intended recipients.
也许减轻这一威胁的最简单方法是断言这些报告本身应该与DKIM之类的东西签署。另一方面，如果验证器上的DKIM基础结构出现问题，则签署DKIM失败报告可能会生成不受信任的报告，甚至可能不被其预期收件人接受。
Automatic generation of these reports by verifying agents can cause a denial-of-service attack when a large volume of email is sent that causes email authentication failures for whatever reason.
当发送大量电子邮件时，通过验证代理自动生成这些报告可能会导致拒绝服务攻击，无论出于何种原因导致电子邮件身份验证失败。
Limiting the rate of generation of these messages might be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information.
限制这些消息的生成速度可能是适当的，但可能会抑制重要且可能对时间敏感的信息的分发。
In general ARF feedback loop terms, it is suggested that report generators only create these (or any) ARF reports after an out-of-band arrangement has been made between two parties. This mechanism then becomes a way to adjust parameters of an authorized abuse report feedback loop that is configured and activated by private agreement rather than starting to send them automatically based solely on discovered data in the DNS.
在一般的ARF反馈回路术语中，建议报告生成器仅在双方作出带外安排后创建这些（或任何）ARF报告。然后，该机制成为调整授权滥用报告反馈循环参数的一种方式，该循环由私人协议配置和激活，而不是仅根据DNS中发现的数据开始自动发送。
In the case of transmitted reports in the form of a new message, it is necessary to consider the construction and transmission of the message so as to avoid amplification attacks, deliberate or otherwise. See Section 5 of [ARF] for further information.
在以新消息的形式发送报告的情况下，有必要考虑消息的构造和传输，以避免放大攻击、故意或其他。更多信息请参见[ARF]第5节。
If it is known that a particular host generates abuse reports upon certain incidents, an attacker could forge a high volume of messages that will trigger such a report. The recipient of the report could then be inundated with reports. This could easily be extended to a distributed denial-of-service attack by finding a number of report-generating servers.
如果已知特定主机在发生某些事件时生成滥用报告，攻击者可能伪造大量消息，从而触发此类报告。然后，报告的接收者可能会被报告淹没。通过查找大量生成报告的服务器，这很容易扩展到分布式拒绝服务攻击。
The incident count referenced in [ARF] provides a limited form of mitigation. The host generating reports may elect to send reports only periodically, with each report representing a number of identical or near-identical incidents. One might even do something inverse-exponentially, sending reports for each of the first ten incidents, then every tenth incident up to 100, then every 100th incident up to 1000, etc., until some period of relative quiet after which the limitation resets.
[ARF]中引用的事件计数提供了有限的缓解形式。生成报告的主机可以选择仅定期发送报告，每个报告表示若干相同或接近相同的事件。人们甚至可能以指数反比的方式做一些事情，发送前十个事件中的每个事件的报告，然后每十个事件发送100个，然后每一百个事件发送1000个，等等，直到一段相对平静的时间之后，限制重置。
The use of this technique for "near-identical" incidents in particular causes a degradation in reporting quality, however. If, for example, a large number of pieces of spam arrive from one attacker, a reporting agent might decide only to send a report about
然而，对“几乎相同”的事件使用这种技术尤其会导致报告质量下降。例如，如果一个攻击者发送了大量垃圾邮件，则报告代理可能只决定发送一份关于垃圾邮件的报告
a fraction of those messages. While this averts a flood of reports to a system administrator, the precise details of each incident are similarly not sent.
这些信息的一小部分。虽然这避免了向系统管理员发送大量报告，但同样不会发送每个事件的确切细节。
This memo requires that the canonicalized header and body be returned without being subject to redaction when a DKIM failure is being reported. This is necessary to ensure that the returned canonicalized forms are useful for debugging, as they must be compared to the equivalent form at the signer. If a message is altered in transit, and the returned data are also redacted, the redacted portion and the altered portion may overlap, rendering the comparison results meaningless. However, unredacted data can leak information the reporting entity considers to be private. It is for this reason the return of the canonicalized forms is not required.
此备忘录要求在报告DKIM失败时，返回规范化的标头和正文，而无需进行编辑。这对于确保返回的规范化表单对调试有用是必要的，因为它们必须与签名者处的等效表单进行比较。如果消息在传输过程中被修改，并且返回的数据也被修改，那么修改的部分和修改的部分可能会重叠，从而使比较结果变得毫无意义。但是，未经编辑的数据可能会泄漏报告实体认为是私有的信息。正是由于这个原因，不需要返回规范化的表单。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，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月。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[AUTH-RESULTS]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 54512009年4月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson，S.，“Base16、Base32和BASE64数据编码”，RFC4648，2006年10月。
[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月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA]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月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME-TYPES]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[REPORT] Kucherawy, M., Ed., "The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages", STD 73, RFC 6522, January 2012.
[报告]Kucherawy，M.，Ed.，“用于报告邮件系统管理消息的多部分/报告媒体类型”，STD 73，RFC 6522，2012年1月。
[RFC6590] Falk, J., Ed., and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", RFC 6590, April 2012.
[RFC6590]Falk，J.，Ed.，和M.Kucherawy，Ed.，“邮件滥用报告中潜在敏感数据的编校”，RFC 65902012年4月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[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月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Frank Ellermann, J.D. Falk, Scott Kitterman, John Levine, Mike Markley, Kelly Wanser, Murray Kucherawy, and Alessandro Vesely.
作者希望感谢以下各方对本提案的审查和建设性批评：弗兰克·埃勒曼、J.D.福尔克、斯科特·基特曼、约翰·莱文、迈克·马克利、凯利·温瑟、默里·库奇拉维和亚历山德罗·维斯利。
This section contains an example of the use of the extension defined by this memo.
本节包含使用本备忘录定义的扩展名的示例。
An ARF-formatted report using the proposed ARF extension fields:
使用建议的ARF扩展字段的ARF格式报告：
Message-ID: <433689.81121.example@mta.mail.receiver.example>
From: "SomeISP Antispam Feedback" <feedback@mail.receiver.example>
To: arf-failure@sender.example
Subject: FW: You have a new bill from your bank
Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT)
MIME-Version: 1.0
Content-Type: multipart/report;
boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
report-type=feedback-report
Content-Transfer-Encoding: 7bit
Message-ID: <433689.81121.example@mta.mail.receiver.example>
From: "SomeISP Antispam Feedback" <feedback@mail.receiver.example>
To: arf-failure@sender.example
Subject: FW: You have a new bill from your bank
Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT)
MIME-Version: 1.0
Content-Type: multipart/report;
boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
report-type=feedback-report
Content-Transfer-Encoding: 7bit
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
This is an authentication failure report for an email message received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT). For more information about this format, please see [RFC6591].
这是2011年10月8日20:15:58+0000（GMT）从a.sender.example收到的电子邮件的身份验证失败报告。有关此格式的更多信息，请参阅[RFC6591]。
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
Feedback-Type: auth-failure
User-Agent: Someisp!Mail-Feedback/1.0
Version: 1
Original-Mail-From: anexample.reply@a.sender.example
Original-Envelope-Id: o3F52gxO029144
Authentication-Results: mta1011.mail.tp2.receiver.example;
dkim=fail (bodyhash) header.d=sender.example
Auth-Failure: bodyhash
Feedback-Type: auth-failure
User-Agent: Someisp!Mail-Feedback/1.0
Version: 1
Original-Mail-From: anexample.reply@a.sender.example
Original-Envelope-Id: o3F52gxO029144
Authentication-Results: mta1011.mail.tp2.receiver.example;
dkim=fail (bodyhash) header.d=sender.example
Auth-Failure: bodyhash
DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9keSB0 aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIHNhbWU gdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJpZnksIH RoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVzaXZlIG9yI HBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoaW50cy4gIElu ZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdGhlIGZvbGxvd2l uZyB0ZXh0OgoKICAgUGxlYXNlIGVudGVyIHlvdXIgZnVsbCBiYW5rIG NyZWRlbnRpYWxzIGF0CiAgIGh0dHA6Ly93d3cuc2VuZGVyLmV4YW1wb GUvCgpXZSBhcmUgaW1wbHlpbmcgdGhhdCwgYWx0aG91Z2ggbXVsdGlw bGUgZmFpbHVyZXMKcmVxdWlyZSBtdWx0aXBsZSByZXBvcnRzLCBhIHN pbmdsZSBmYWlsdXJlIGNhbiBiZQpyZXBvcnRlZCBhbG9uZyB3aXRoIH BoaXNoaW5nIGluIGEgc2luZ2xlIHJlcG9ydC4K DKIM-Domain: sender.example DKIM-Identity: @sender.example DKIM-Selector: testkey Arrival-Date: 8 Oct 2011 20:15:58 +0000 (GMT) Source-IP: 192.0.2.1 Reported-Domain: a.sender.example Reported-URI: http://www.sender.example/
DKIM标准化主体：VGHPCYBPCHI1LC3NHZ2UGYM9KESB0 AGF0IGDVDB2RPZMLZCBBIB0CMFUC20LGOKQQGdGhliHnhbWU GDGLTZSB0AGF0IHROZSB2R5AGFZACBYWLSCYB0B2ZXJPZNKSIH ROZQPTZNZYWYWLIGNBNQGAXMY2LYXLYXJSESBHYNZYNVZLIG9YIG9Y HBOKZBOA10IGN1YMBLN3Q0QGdGdGdGdG29GdGdGdGdGdGdGdGwG29GwGdGdGdGdGdGwG29BYWZZYWZZZYWZZZZZYWZZZZZYWZZZUZYB0ZXH0Ogokicagugxlyxnligvudgzvyihlvdxigznvsbcbiyw5Rig NYZWRLBNRPYWxZigf0Ciagigh0D6LY93D3CuC2VuzgVyL4Yw1WB GuVCGPxZSBHCMUGAW1WBHLPBMCGDGhHhdcWyW0Ag91Z2GbxVSdGbWbGbZfPyZxMxMxMxMxMxMvxDwLyZbZbTbWbWbWxDxBxBxBxBxBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBhBDKIM标识：@sender.example DKIM选择器：测试密钥到达日期：2011年10月8日20:15:58+0000（GMT）源IP:192.0.2.1报告域：a.sender.example报告URI:http://www.sender.example/
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: 7bit
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: 7bit
Authentication-Results: mta1011.mail.tp2.receiver.example;
dkim=fail (bodyhash) header.d=sender.example;
spf=pass smtp.mailfrom=anexample.reply@a.sender.example
Received: from smtp-out.sender.example
by mta1011.mail.tp2.receiver.example
with SMTP id oB85W8xV000169;
Sat, 08 Oct 2011 13:15:58 -0700 (PDT)
DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
s=testkey; d=sender.example; h=From:To:Subject:Date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=
Received: from mail.sender.example
by smtp-out.sender.example
with SMTP id o3F52gxO029144;
Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
Received: from internal-client-001.sender.example
by mail.sender.example
with SMTP id o3F3BwdY028431;
Sat, 08 Oct 2011 13:15:24 -0700 (PDT)
Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT)
Reply-To: anexample.reply@a.sender.example
Authentication-Results: mta1011.mail.tp2.receiver.example;
dkim=fail (bodyhash) header.d=sender.example;
spf=pass smtp.mailfrom=anexample.reply@a.sender.example
Received: from smtp-out.sender.example
by mta1011.mail.tp2.receiver.example
with SMTP id oB85W8xV000169;
Sat, 08 Oct 2011 13:15:58 -0700 (PDT)
DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
s=testkey; d=sender.example; h=From:To:Subject:Date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=
Received: from mail.sender.example
by smtp-out.sender.example
with SMTP id o3F52gxO029144;
Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
Received: from internal-client-001.sender.example
by mail.sender.example
with SMTP id o3F3BwdY028431;
Sat, 08 Oct 2011 13:15:24 -0700 (PDT)
Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT)
Reply-To: anexample.reply@a.sender.example
From: anexample@a.sender.example
To: someuser@receiver.example
Subject: You have a new bill from your bank
Message-ID: <87913910.1318094604546@out.sender.example>
From: anexample@a.sender.example
To: someuser@receiver.example
Subject: You have a new bill from your bank
Message-ID: <87913910.1318094604546@out.sender.example>
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg--
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg--
Example 1: Example ARF Report Using These Extensions
示例1：使用这些扩展的示例ARF报告
This example ARF message is making the following assertion:
此示例ARF消息做出以下断言：
o DKIM verification of the signature added within "sender.example" failed.
o 在“sender.example”中添加的签名的DKIM验证失败。
o The cause of the verification failure was a mismatch between the body contents observed at the verifier and the body hash contained in the signature.
o 验证失败的原因是在验证器上观察到的正文内容与签名中包含的正文哈希不匹配。
Author's Address
作者地址
Hilda L. Fontana 3579 E. Foothill Blvd., Suite 282 Pasadena, CA 91107 US
美国加利福尼亚州帕萨迪纳市山麓大道东3579号希尔达L.丰塔纳282室，邮编：91107
Phone: +1 626 676 8852
EMail: hilda@hfontana.com
Phone: +1 626 676 8852
EMail: hilda@hfontana.com