Internet Engineering Task Force (IETF) J. Falk
Request for Comments: 6650 Return Path
Updates: 5965 M. Kucherawy, Ed.
Category: Standards Track Cloudmark
ISSN: 2070-1721 June 2012
Internet Engineering Task Force (IETF) J. Falk
Request for Comments: 6650 Return Path
Updates: 5965 M. Kucherawy, Ed.
Category: Standards Track Cloudmark
ISSN: 2070-1721 June 2012
Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
电子邮件反馈报告的创建和使用：滥用报告格式（ARF）的适用性声明
Abstract
摘要
RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed.
RFC 5965定义了一种可扩展的机器可读格式，用于邮件操作员向其他方报告收到的电子邮件的反馈。本适用性声明描述了使用此格式报告滥用和身份验证失败事件的常用方法。任何大小的邮箱提供程序、邮件发送实体和最终用户都可以使用这些方法作为创建最适合他们的过程的基础。还讨论了一些相关的可选机制。
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/rfc6650.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6650.
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 .....................................................4
3. Solicited and Unsolicited Reports ...............................4
4. Generating and Handling Solicited Abuse Reports .................4
4.1. General Considerations for Feedback Providers ..............4
4.2. Where to Send Reports ......................................5
4.3. What to Put in Reports .....................................5
4.4. General Considerations for Feedback Consumers ..............5
4.5. What to Expect .............................................6
4.6. What to Do with Reports ....................................6
5. Generating and Handling Unsolicited Abuse Reports ...............6
5.1. General Considerations .....................................6
5.2. When to Generate Reports ...................................7
5.3. Where to Send Reports ......................................7
5.4. What to Put in Reports .....................................8
5.5. What to Do with Reports ....................................9
6. Generating Automatic Authentication Failure Reports ............10
7. Security Considerations ........................................11
7.1. Security Considerations in Other Documents ................11
7.2. Forgeries .................................................11
7.3. Amplification Attacks .....................................11
7.4. Automatic Generation ......................................11
7.5. Reporting Multiple Incidents ..............................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................14
1. Introduction ....................................................3
2. Definitions .....................................................4
3. Solicited and Unsolicited Reports ...............................4
4. Generating and Handling Solicited Abuse Reports .................4
4.1. General Considerations for Feedback Providers ..............4
4.2. Where to Send Reports ......................................5
4.3. What to Put in Reports .....................................5
4.4. General Considerations for Feedback Consumers ..............5
4.5. What to Expect .............................................6
4.6. What to Do with Reports ....................................6
5. Generating and Handling Unsolicited Abuse Reports ...............6
5.1. General Considerations .....................................6
5.2. When to Generate Reports ...................................7
5.3. Where to Send Reports ......................................7
5.4. What to Put in Reports .....................................8
5.5. What to Do with Reports ....................................9
6. Generating Automatic Authentication Failure Reports ............10
7. Security Considerations ........................................11
7.1. Security Considerations in Other Documents ................11
7.2. Forgeries .................................................11
7.3. Amplification Attacks .....................................11
7.4. Automatic Generation ......................................11
7.5. Reporting Multiple Incidents ..............................12
8. Acknowledgements ...............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................14
The Abuse Reporting Format (ARF) was initially developed for two very specific use cases. Initially, it was intended to be used for reporting feedback between large email operators, or from large email operators to end user network access operators, any of whom could be presumed to have automated abuse-handling systems. Secondarily, it is used by those same large mail operators to send those same reports to other entities, including those involved in sending bulk email for commercial purposes. In either case, the reports would be triggered by direct end user action such as clicking on a "report spam" button in their email client.
滥用报告格式（ARF）最初是为两个非常具体的用例开发的。最初，它旨在用于报告大型电子邮件运营商之间的反馈，或从大型电子邮件运营商到最终用户网络访问运营商之间的反馈，其中任何一家都可以被认为拥有自动滥用处理系统。第二，这些大型邮件运营商使用它向其他实体发送相同的报告，包括那些为商业目的发送批量电子邮件的实体。在这两种情况下，报告都将由直接的最终用户操作触发，例如单击其电子邮件客户端中的“报告垃圾邮件”按钮。
Though other uses for ARF as defined in [RFC5965] have been discussed (and may be documented similarly in the future), abuse reporting remains the primary application, with a small amount of adoption of extensions that enable authentication failure reporting.
尽管已经讨论了[RFC5965]中定义的ARF的其他用途（将来可能会有类似的记录），但滥用报告仍然是主要应用，少量采用了支持身份验证失败报告的扩展。
This applicability statement provides direction for using ARF in both contexts. It also includes some statements about the use of ARF in conjunction with other email technologies.
此适用性声明为在两种上下文中使用ARF提供了方向。它还包括一些关于ARF与其他电子邮件技术结合使用的声明。
The purpose for reporting abusive messages is to stop recurrences. The methods described in this document focus on automating abuse reporting as much as practical, so as to minimize the work of a site's abuse team. There are further reasons why abuse feedback generation is worthwhile, such as instruction of mail filters or reputation trackers, or initiation of investigations of particularly egregious abuses. These other applications are not discussed in this memo.
报告滥用信息的目的是防止再次发生。本文件中描述的方法侧重于尽可能实际地自动化滥用报告，以尽量减少网站滥用团队的工作。产生滥用反馈是值得的，还有其他原因，如指示邮件过滤器或声誉追踪者，或开始调查特别严重的滥用行为。本备忘录中未讨论这些其他应用程序。
Further introduction to this topic may be found in [RFC6449], which has more information about the general topic of abuse reporting. Many of the specific ARF guidelines in this document were taken from the principles presented in [RFC6449].
[RFC6449]中可以找到对该主题的进一步介绍，其中有关于虐待报告一般主题的更多信息。本文件中的许多具体ARF指南取自[RFC6449]中提出的原则。
At the time of publication of this document, five feedback types are registered. This document only discusses two of them ("abuse" [RFC5965] and "auth-failure" [RFC6591]), as they are seeing sufficient use in practice that applicability statements can be made about them. The others, i.e., "fraud" [RFC5965], "other" [RFC5965], and "not-spam" [RFC6430], are either too new or too seldom used to be included here.
在本文件出版时，登记了五种反馈类型。本文件仅讨论其中两个（“滥用”[RFC5965]和“认证失败”[RFC6591]），因为它们在实践中得到了充分的应用，可以对它们进行适用性声明。其他内容，即“欺诈”[RFC5965]、“其他”[RFC5965]和“非垃圾邮件”[RFC6430]，要么太新，要么太少用于此处。
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 [RFC2119] and are intended to replace the Requirement Levels described in Section 3.3 of [RFC2026].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释，并旨在取代[RFC2026]第3.3节中所述的要求级别。
Some of the terminology used in this document is taken from [RFC5598].
本文件中使用的一些术语取自[RFC5598]。
"Mailbox Provider" refers to an organization that accepts, stores, and offers access to [RFC5322] messages ("email messages") for end users. Such an organization has typically implemented SMTP [RFC5321] and might provide access to messages through IMAP [RFC3501], the Post Office Protocol (POP) [RFC1939], a proprietary interface designed for HTTP [RFC2616], or a proprietary protocol.
“邮箱提供商”是指接受、存储并向最终用户提供[RFC5322]邮件（“电子邮件”）访问权限的组织。这样的组织通常已经实现了SMTP[RFC5321]，并且可以通过IMAP[RFC3501]、邮局协议（POP）[RFC1939]、专为HTTP设计的专有接口[RFC2616]或专有协议提供对消息的访问。
The original, and still by far the most common, application of [RFC5965] is when two mail systems make a private agreement to exchange abuse reports -- usually reports due to recipients manually reporting messages as spam. We refer to these as solicited reports.
[RFC5965]最早也是迄今为止最常见的应用是两个邮件系统达成私人协议交换滥用报告——通常是由于收件人手动将邮件报告为垃圾邮件而产生的报告。我们将这些报告称为征求报告。
Other uses for ARF involve such reports sent between parties that don't know each other. These unsolicited reports are sent without prior arrangement between the parties as to the context and meaning of the reports. Therefore, the constraints on how these unsolicited reports need to be structured such that they are likely to be useful to the recipient -- e.g., to what address(es) they can usefully be sent, what issues they can be used to report, and how they can be handled by the receiver of the report -- are very different.
ARF的其他用途包括在彼此不认识的各方之间发送此类报告。这些未经请求的报告未经双方事先就报告的上下文和含义作出安排而发送。因此，这些未经请求的报告需要如何结构化，以使其可能对接收者有用——例如，它们可以有效地发送到什么地址，它们可以用来报告什么问题，以及报告接收者如何处理这些问题——这些限制是非常不同的。
The two cases are covered separately in the sections that follow.
这两种情况将在下面的章节中分别介绍。
A Mailbox Provider receives reports of abusive or unwanted mail from its users, most often by providing a "report spam" button (or similar nomenclature) in the MUA (Mail User Agent). The method of transferring this message and any associated metadata from the MUA to the Mailbox Provider's ARF processing system is not defined by any standards document but is discussed further in Section 3.2 of [RFC6449]. Policy concerns related to the collection of this data are discussed in Section 3.4 of [RFC6449].
邮箱提供商接收来自其用户的滥用或不需要的邮件的报告，通常通过在MUA（邮件用户代理）中提供“报告垃圾邮件”按钮（或类似术语）来实现。将此消息和任何相关元数据从MUA传输到邮箱提供商的ARF处理系统的方法未在任何标准文件中定义，但将在[RFC6449]的第3.2节中进一步讨论。[RFC6449]第3.4节讨论了与该数据收集相关的政策问题。
To implement the recommendations of this memo, the reports are formatted per [RFC5965] and transmitted as an email message [RFC5322], typically using SMTP [RFC5321].
为实施本备忘录的建议，报告按照[RFC5965]进行格式化，并作为电子邮件[RFC5322]传输，通常使用SMTP[RFC5321]。
Ongoing maintenance of an ARF processing system is discussed in Section 3.6 of [RFC6449].
[RFC6449]第3.6节讨论了ARF处理系统的持续维护。
The Mailbox Provider SHOULD NOT send reports to addresses that have not explicitly requested them. A valid deviation might be the result of local policy instructions. The process whereby such parties may request the reports is discussed in Section 3.5 of [RFC6449].
邮箱提供程序不应向未明确请求报告的地址发送报告。有效偏差可能是当地政策指示的结果。[RFC6449]第3.5节讨论了此类缔约方要求报告的过程。
The reports SHOULD use "Feedback-Type: abuse" for the report type. Although a Mailbox Provider generating the reports can use other types appropriate to the nature of the abuse being reported, the operator receiving the reports might not treat different feedback types differently.
报告应使用“反馈类型：滥用”作为报告类型。尽管生成报告的邮箱提供商可以使用与报告的滥用性质相适应的其他类型，但接收报告的操作员可能不会对不同的反馈类型进行不同的处理。
The following fields are optional in [RFC5965] but SHOULD be used in this context when their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. Other optional fields can be included as deemed appropriate by the implementer.
以下字段在[RFC5965]中是可选的，但当其相应值可用时，应在此上下文中使用：原始邮件发件人、到达日期、源IP和原始Rcpt收件人。其他可选字段可以包括在实施者认为合适的范围内。
User-identifiable data MAY be obscured as described in [RFC6590].
如[RFC6590]所述，用户可识别数据可能会被遮挡。
ARF report streams are established proactively between Feedback Providers and Feedback Consumers. Recommendations for preparing to request feedback are discussed in Section 4.1 of [RFC6449].
ARF报告流是在反馈提供者和反馈消费者之间主动建立的。[RFC6449]第4.1节讨论了准备请求反馈的建议。
Operators MUST be able to accept ARF [RFC5965] reports as email messages [RFC5322] over SMTP [RFC5321]. These messages, and other types of email messages that can be received, are discussed in Section 4.2 of [RFC6449].
操作员必须能够通过SMTP[RFC5321]将ARF[RFC5965]报告作为电子邮件[RFC5322]接受。[RFC6449]第4.2节讨论了这些邮件以及可以接收的其他类型的电子邮件。
Recipients of feedback reports that are part of formal feedback arrangements have to be capable of handling large volumes of reports. This could require automation of report processing as discussed in Section 4.4 of [RFC6449].
作为正式反馈安排一部分的反馈报告的接收者必须能够处理大量报告。如[RFC6449]第4.4节所述，这可能需要报告处理的自动化。
The list of valid Feedback-Types is defined in [RFC5965], which created an IANA registry for valid values to allow for extensions. However, to allow for handling of new types that are not yet supported, an automated report processing system MUST NOT reject (in the SMTP sense) a report based solely on an unknown Feedback-Type. The automated system can simply set reports of unknown types aside for manual handling. However, Mailbox Providers might only make use of the "abuse" Feedback-Type. Therefore, report receivers might be required to do additional analysis to separate different types of abuse reports after receipt if they do not have prior specific knowledge of the sender of the report.
[RFC5965]中定义了有效反馈类型的列表，它为有效值创建了IANA注册表，以允许扩展。但是，为了允许处理尚未受支持的新类型，自动报告处理系统不得拒绝（从SMTP意义上说）仅基于未知反馈类型的报告。自动化系统可以简单地将未知类型的报告放在一边进行手动处理。但是，邮箱提供程序可能只使用“滥用”反馈类型。因此，如果报告接收人事先不知道报告发送者的具体情况，则可能需要在收到报告后进行额外分析，以区分不同类型的滥用报告。
Report receivers MUST accept reports that have obscured their user-identifiable data as described in [RFC6590]. That document also discusses the handling of such reports. This technique is also discussed in Section 4.4 of [RFC6449].
如[RFC6590]所述，报告接收人必须接受模糊其用户可识别数据的报告。该文件还讨论了此类报告的处理。[RFC6449]第4.4节也讨论了该技术。
Section 4.3 of [RFC6449] discusses actions that mail operators might take upon receiving a report (or multiple reports).
[RFC6449]第4.3节讨论了邮件操作员在收到一份报告（或多份报告）时可能采取的行动。
It is essential for report recipients to be capable of throttling reports being sent to avoid damage to their own installations. Therefore, Feedback Providers MUST provide a way for report recipients to request that no further reports be sent. Unfortunately, no standardized mechanism for such requests exists to date, and all existing mechanisms for meeting this requirement are out-of-band.
报表收件人必须能够限制发送的报表，以避免损坏自己的安装。因此，反馈提供者必须为报告接收者提供一种请求不再发送报告的方式。不幸的是，迄今为止还没有针对此类请求的标准化机制，所有满足这一要求的现有机制都超出了范围。
Message authentication is generally a good idea, but it is especially important to encourage credibility of, and thus response to, unsolicited reports. Therefore, as with any other message, Feedback Providers sending unsolicited reports SHOULD send reports that they expect will pass the Sender Policy Framework (SPF) [RFC4408] and/or DomainKeys Identified Mail (DKIM) [RFC6376] checks.
消息身份验证通常是一个好主意，但鼓励未经请求的报告的可信度，从而对其作出响应，这一点尤为重要。因此，与任何其他消息一样，发送未经请求的报告的反馈提供程序应发送他们预期将通过发件人策略框架（SPF）[RFC4408]和/或域密钥标识邮件（DKIM）[RFC6376]检查的报告。
Handling of unsolicited reports has a significant cost to the report receiver. Senders of unsolicited reports, especially those sending large volumes of them automatically, SHOULD NOT send reports that cannot be used as a basis for action by the recipient, whether this is due to the report being sent about an incident that is not abuse-related, the report being sent to an email address that won't result in action, or the content or format of the report being hard for the recipient to read or use.
处理未经请求的报告会给报告接收者带来巨大的成本。未经请求的报告的发件人，尤其是自动发送大量报告的发件人，不应发送无法作为收件人采取行动依据的报告，无论这是因为发送的报告涉及与滥用无关的事件，报告发送到不会导致采取行动的电子邮件地址，或报告的内容或格式难以收件人阅读或使用。
Feedback Providers SHOULD NOT report all mail sent from a particular sender merely because some of it is determined to be abusive.
反馈提供者不应该仅仅因为某些邮件被确定为滥用而报告来自某个特定发件人的所有邮件。
Mechanical reports of mail that "looks like" spam, based solely on the results of inline content analysis tools, SHOULD NOT be sent since, because of their subjective nature, they are unlikely to provide a basis for the recipient to take action. Complaints generated by end users about mail that is determined by them to be abusive, or mail delivered to "spam trap" or "honeypot" addresses, are far more likely to be accurate and MAY be sent.
仅基于内联内容分析工具的结果的“看起来像”垃圾邮件的邮件机械报告不应发送，因为由于其主观性质，它们不可能为收件人采取行动提供依据。最终用户对其确定为滥用的邮件或发送到“垃圾邮件陷阱”或“蜜罐”地址的邮件提出的投诉更可能是准确的，并且可能会被发送。
If a Feedback Provider applies SPF [RFC4408] to arriving messages, a report SHOULD NOT be generated to the RFC5321.MailFrom domain if the SPF evaluation produced a "Fail", "SoftFail", "TempError", or "PermError" report, as no reliable assertion or assumption can be made that use of the domain was authorized. A valid exception would be specific knowledge that the SPF result is not definitive for that domain under those circumstances (for example, a message that is also signed using DKIM [RFC6376] by the same domain, and that signature validates).
如果反馈提供者将SPF[RFC4408]应用于到达的消息，则如果SPF评估产生了“失败”、“软失败”、“温度错误”或“PermError”报告，则不应向RFC5321.MailFrom域生成报告，因为无法做出任何可靠的断言或假设，即域的使用已获得授权。一个有效的例外是特定的知识，即SPF结果在这些情况下对于该域不是确定的（例如，同一域也使用DKIM[RFC6376]签名的消息，并且该签名验证）。
Rather than generating feedback reports themselves, MUAs SHOULD create abuse reports and send these reports back to their Mailbox Providers so that they can generate and send ARF messages on behalf of end users (see Section 3.2 of [RFC6449]). This allows centralized processing and tracking of reports, and provides training input to filtering systems. There is, however, no standard mechanism for this signaling between MUAs and Mailbox Providers to trigger abuse reports.
MUA不应自行生成反馈报告，而应创建滥用报告并将这些报告发送回其邮箱提供商，以便他们能够代表最终用户生成和发送ARF消息（参见[RFC6449]第3.2节）。这允许集中处理和跟踪报告，并为过滤系统提供培训输入。然而，MUA和邮箱提供程序之间没有标准的信令机制来触发滥用报告。
Feedback Providers SHOULD NOT send reports to recipients that are uninvolved or only peripherally involved. For example, they SHOULD NOT send reports to the operator of every Autonomous System in the path between the apparent originating system and the operator
反馈提供者不应向未涉及或仅涉及外围设备的收件人发送报告。例如，他们不应向明显的原始系统和操作员之间的路径中的每个自治系统的操作员发送报告
generating the report. Instead, they need to send reports to recipients that are both responsible for the messages and able to do something about them.
生成报告。相反，他们需要向收件人发送报告，这些收件人既要对邮件负责，也要能够对邮件采取措施。
Deciding where to send an unsolicited report will typically rely on heuristics. Abuse addresses in WHOIS [RFC3912] records of the IP address relaying the subject message and/or of the domain name found in the results of a PTR ("reverse lookup") query on that address are likely reasonable candidates, as is the abuse@domain role address (see [RFC2142]) of related domains. Unsolicited reports SHOULD NOT be sent to email addresses that are not clearly intended to handle abuse reports. Legitimate candidates include those found in WHOIS records or on a web site that either are explicitly described as an abuse contact or are of the form "abuse@domain".
决定向何处发送未经请求的报告通常依赖于启发式。WHOIS[RFC3912]记录中转发主题消息的IP地址和/或在PTR（“反向查找”）查询该地址的结果中找到的域名的滥用地址可能是合理的候选地址，如下所示：abuse@domain相关域的角色地址（请参见[RFC2142]）。未经请求的报告不应发送到未明确用于处理滥用报告的电子邮件地址。合法候选人包括在WHOIS记录或网站上发现的那些被明确描述为虐待联系人或以下形式的人”abuse@domain".
Where an abusive message is authenticated using a domain-level authentication technology such as DKIM [RFC6376] or SPF [RFC4408], the domain that has been verified by the authentication mechanism is often a reasonable candidate for receiving feedback about the message. For DKIM, though, while the authenticated domain has some responsibility for the mail sent, it can be a poor contact point for abuse issues (for example, it could represent the message's author but not its sender, it could identify the bad actor responsible for the message, or it could refer to a domain that cannot receive mail at all).
在使用域级认证技术（如DKIM[RFC6376]或SPF[RFC4408]）认证滥用消息的情况下，已由认证机制验证的域通常是接收关于消息的反馈的合理候选域。不过，对于DKIM来说，虽然经过身份验证的域对发送的邮件负有一定责任，但它可能是滥用问题的不良联系点（例如，它可能代表邮件的作者而不是发件人，它可能识别负责邮件的坏行为人，或者它可能指向一个根本无法接收邮件的域）。
Often, unsolicited reports will have no meaning if sent to abuse reporting addresses belonging to the abusive parties themselves. In fact, it is possible that such reports might reveal information about complainants. Reports SHOULD NOT be sent to such addresses if they can be identified beforehand, except where the abusive party is known to be responsive to such reports.
通常，未经请求的报告如果发送到属于虐待方本身的虐待报告地址，将毫无意义。事实上，此类报告可能会披露投诉人的信息。如果可以事先确定报告的地址，则不应将报告发送至此类地址，除非已知虐待方对此类报告作出回应。
Reports SHOULD use "Feedback-Type: abuse" but can use other types as appropriate. However, the Mailbox Provider generating the reports cannot assume that the operator receiving the reports will treat different Feedback-Types differently.
报告应使用“反馈类型：滥用”，但可酌情使用其他类型。但是，生成报告的邮箱提供程序不能假定接收报告的操作员将以不同的方式处理不同的反馈类型。
Reports SHOULD include the following optional fields whenever their corresponding values are available and applicable to the report: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. Other optional fields can be included as deemed appropriate by the implementer.
只要报告的相应值可用且适用于报告，则报告应包括以下可选字段：原始邮件发件人、到达日期、源IP和原始Rcpt收件人。其他可选字段可以包括在实施者认为合适的范围内。
Experience suggests that the use of ARF is advisable in most contexts. Automated recipient systems can handle abuse reports sent in ARF at least as well as any other format such as plain text, with or without a copy of the message attached. That holds even for systems that did not request ARF reports, assuming such reports are generated considering the possibility of recipients that don't use automated ARF parsing. Anyone sending unsolicited reports in ARF can legitimately presume that some recipients will only be able to access the human-readable (first, text/plain) part of it and SHOULD include all information needed also in this part. Further, they SHOULD ensure that the report is readable when viewed as plain text, to give low-end ticketing systems as much assistance as possible. In extreme cases, failure to take these steps may result in the report being discarded or ignored.
经验表明，在大多数情况下，使用抗逆转录病毒药物是可取的。自动收件人系统可以处理以ARF格式发送的滥用报告，至少可以处理任何其他格式（如纯文本）的滥用报告，无论是否附加邮件副本。这甚至适用于未请求ARF报告的系统，假设生成此类报告时考虑到收件人不使用自动ARF解析的可能性。任何在ARF中发送未经请求的报告的人都可以合理地假定某些收件人只能访问其中的可读部分（第一部分，文本/普通），并且应该在该部分中包含所有需要的信息。此外，他们应确保报告在以纯文本形式查看时可读，以尽可能为低端票务系统提供帮助。在极端情况下，不采取这些步骤可能导致报告被丢弃或忽略。
Receivers of unsolicited reports can take advantage of the standardized parts of ARF to automate processing. Independent of the sender of the report, they can improve processing by separating valid reports from invalid reports by, for example, looking for references to IP address ranges, domains, and mailboxes for which the recipient organization is responsible in the copy of the reported message, and by correlating multiple reports of similar messages to identify bulk email senders.
未经请求报告的接收者可以利用ARF的标准化部分来自动化处理。独立于报告的发件人，他们可以通过将有效报告与无效报告分开来改进处理，例如，在报告邮件的副本中查找收件人组织负责的IP地址范围、域和邮箱的引用，并通过关联多个类似邮件的报告来识别批量电子邮件发件人。
Per Section 4.4 of [RFC6449], a network service provider MAY use ARF data for automated forwarding of feedback messages to the originating customer.
根据[RFC6449]第4.4节，网络服务提供商可使用ARF数据自动将反馈消息转发给发起客户。
Published abuse mailbox addresses SHOULD NOT reject non-ARF messages based solely on the format, as generation of ARF messages can occasionally be unavailable or not applicable. Deviation from this requirement could be done due to local policy decisions regarding other message criteria.
发布的滥用邮箱地址不应仅基于格式拒绝非ARF邮件，因为ARF邮件的生成有时不可用或不适用。由于当地有关其他消息标准的政策决定，可能会偏离此要求。
Although [RFC6449] suggests that replying to feedback is not useful, in the case of receipt of ARF reports where no feedback arrangement has been established, a non-automated reply might be desirable to indicate what action resulted from the complaint, heading off more severe filtering by the Feedback Provider. In addition, using an address that cannot receive replies precludes any requests for additional information and increases the likelihood that further reports will be discarded or blocked. Thus, a Feedback Provider sending unsolicited reports SHOULD NOT generate reports for which a reply cannot be received. Where an unsolicited report results in the establishment of contact with a responsible and responsive party, this data can be saved for future complaint handling and possible
尽管[RFC6449]表明对反馈的回复没有用处，但在收到ARF报告时，如果没有建立反馈安排，则可能需要非自动回复，以表明投诉导致的行动，从而避免反馈提供者进行更严格的过滤。此外，使用无法接收回复的地址会阻止任何对附加信息的请求，并增加丢弃或阻止进一步报告的可能性。因此，发送未经请求的报告的反馈提供者不应生成无法收到答复的报告。如果未经请求的报告导致与责任方和响应方建立联系，则可以保存此数据，以备将来处理投诉并在可能的情况下使用
establishment of a formal (solicited) feedback arrangement. See Section 3.5 of [RFC6449] for a discussion of establishment of feedback arrangements.
建立正式的（征求的）反馈安排。有关建立反馈安排的讨论，请参见[RFC6449]第3.5节。
There are some cases where report generation is caused by automation rather than user requests. A specific example of this is reporting, using ARF (or extensions to it), of messages that fail particular message authentication checks. Examples of this include [RFC6651] and [RFC6652]. The considerations presented below apply in those cases.
有些情况下，报告生成是由自动化而不是用户请求引起的。这方面的一个具体示例是使用ARF（或其扩展）报告未通过特定消息身份验证检查的消息。这方面的例子包括[RFC6651]和[RFC6652]。下列考虑事项适用于这些情况。
The applicability statement for this use case is somewhat smaller, as many of the issues associated with abuse reports are not relevant to reports about authentication failures.
这个用例的适用性声明稍微小一些，因为与滥用报告相关的许多问题与关于认证失败的报告无关。
Automatic feedback generators MUST select actual message recipients based on data provided by willing report receivers. In particular, recipients MUST NOT be selected using heuristics.
自动反馈生成器必须根据自愿报告接收者提供的数据选择实际的消息接收者。特别是，不得使用启发式选择收件人。
If the message under evaluation by the Verifier is an ARF [RFC5965] message, a report MUST NOT be automatically generated.
如果验证器评估的消息是ARF[RFC5965]消息，则不得自动生成报告。
The message for a new report sent via SMTP MUST be constructed so as to avoid amplification attacks, deliberate or otherwise. The envelope sender address of the report MUST be chosen so that these reports will not generate mail loops. Similar to Section 2 of [RFC3464], the envelope sender address of the report MUST be chosen to ensure that no feedback reports will be issued in response to the report itself. Therefore, when an SMTP transaction is used to send a report, the MAIL FROM command SHOULD use the NULL reverse-path, i.e., "MAIL FROM:<>". An exception to this would be the use of a reverse-path selected such that SPF checks on the report will pass; in such cases, the operator will need to make provisions to avoid the amplification attack or mail loop via other means.
必须构造通过SMTP发送的新报告的消息，以避免故意或其他放大攻击。必须选择报告的信封发件人地址，以便这些报告不会生成邮件循环。与[RFC3464]第2节类似，必须选择报告的信封发送者地址，以确保不会针对报告本身发布反馈报告。因此，当SMTP事务用于发送报告时，MAIL FROM命令应使用空的反向路径，即“MAIL FROM:<>”。例外情况是使用选择的反向路径，以使报告上的SPF检查通过；在这种情况下，运营商需要采取措施避免通过其他方式进行放大攻击或邮件循环。
Reports SHOULD use "Feedback-Type: auth-failure" but MAY use other types as appropriate. However, the Mailbox Provider generating the reports cannot assume that the operator receiving the reports will treat different Feedback-Types differently.
报告应使用“反馈类型：身份验证失败”，但可根据需要使用其他类型。但是，生成报告的邮箱提供程序不能假定接收报告的操作员将以不同的方式处理不同的反馈类型。
These reports SHOULD include the following fields, although they are optional in [RFC5965], whenever their corresponding values are available: Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. Other optional fields can be included as deemed appropriate by the implementer.
这些报告应包括以下字段，尽管它们在[RFC5965]中是可选的，只要它们的相应值可用：原始邮件发件人、到达日期、源IP和原始Rcpt收件人。其他可选字段可以包括在实施者认为合适的范围内。
Implementers are strongly urged to review, at a minimum, the Security Considerations sections of [RFC5965] and [RFC6449].
强烈建议实施者至少审查[RFC5965]和[RFC6449]中的安全注意事项部分。
Feedback Providers that relay user complaints directly, rather than by reference to a stored message (e.g., IMAP or POP), could be duped into sending a complaint about a message that the complaining user never actually received, as an attack on the purported originator of the falsified message. Feedback Providers need to be resilient to such attack methods.
直接转发用户投诉的反馈提供者，而不是通过引用存储的消息（例如IMAP或POP），可能会被欺骗，发送投诉用户从未实际收到的消息的投诉，从而攻击伪造消息的声称发起人。反馈提供者需要对此类攻击方法具有弹性。
Also, these reports may 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 reports of any kind should take appropriate precautions to minimize the potential damage from denial-of-service attacks.
此外，这些报告可能像普通互联网电子邮件一样容易伪造。希望自动使用任何类型报告的用户代理和自动邮件处理设施（如邮件分发列表爆炸器）应采取适当的预防措施，将拒绝服务攻击的潜在损害降至最低。
Perhaps the simplest means of mitigating this threat is to assert that these reports should themselves be signed with something like DKIM and/or authorized by something like SPF. Note, however, that if there is a problem with the email infrastructure at either end, DKIM and/or SPF may result in reports that aren't trusted or even accepted by their intended recipients, so it is important to make sure those components are properly configured. The use of both technologies in tandem can resolve this concern to a degree, since they generally have disjoint failure modes.
也许减轻这一威胁的最简单方法是断言这些报告本身应该由DKIM之类的人签署和/或由SPF之类的人授权。但是，请注意，如果两端的电子邮件基础结构出现问题，DKIM和/或SPF可能会导致报告不受信任，甚至无法被预期的收件人接受，因此确保这些组件的配置正确非常重要。这两种技术的串联使用可以在一定程度上解决这一问题，因为它们通常具有不相交的故障模式。
Failure to comply with the recommendations regarding selection of the envelope sender can lead to amplification denial-of-service attacks. This is discussed in Section 6 as well as in [RFC3464].
如果不遵守有关选择信封发送方的建议，可能会导致拒绝服务攻击的扩大。第6节以及[RFC3464]中对此进行了讨论。
ARF [RFC5965] reports have historically been generated individually as a result of some kind of human request, such as someone clicking a "Report Abuse" button in a mail reader. In contrast, the mechanisms described in some extension documents (i.e., [RFC6651] and [RFC6652]) are focused around automated reporting. This obviously implies the
ARF[RFC5965]报告历来都是由于某种人工请求而单独生成的，例如有人单击邮件阅读器中的“报告滥用”按钮。相反，一些扩展文档（即[RFC6651]和[RFC6652]）中描述的机制主要围绕自动报告。这显然意味着
potential for much larger volumes or higher frequency of messages, and thus greater mail system load (both for Feedback Providers and report receivers).
可能会产生更大的邮件量或更高的邮件频率，从而产生更大的邮件系统负载（对于反馈提供者和报告接收者）。
Those mechanisms are primarily intended for use in generating reports to aid implementers of DKIM [RFC6376], Author Domain Signing Practices (ADSP) [RFC5617], and SPF [RFC4408], and other related protocols during development and debugging. They are not generally intended for prolonged forensic use, specifically because of these load concerns. However, extended use is possible by ADministrative Management Domains (ADMDs) that want to keep a close watch for fraud or infrastructure problems. It is important to consider the impact of doing so on both Feedback Providers and the requesting ADMDs.
这些机制主要用于在开发和调试期间生成报告，以帮助DKIM[RFC6376]、作者域签名实践（ADSP）[RFC5617]和SPF[RFC4408]以及其他相关协议的实现者。它们通常不用于长期的法医用途，特别是因为这些负载问题。但是，希望密切监视欺诈或基础设施问题的管理管理域（ADMD）可以扩展使用。重要的是考虑这样做对反馈提供者和请求ADMD的影响。
A sender requesting these reports can cause its mail servers to be overwhelmed if it sends out signed messages whose signatures fail to verify for some reason, provoking a large number of reports from Feedback Providers. Similarly, a Feedback Provider could be overwhelmed by a large volume of messages requesting reports whose signatures fail to validate, as the Feedback Provider now needs to send reports back to the Signer.
如果请求这些报告的发件人发送的签名消息由于某种原因无法验证其签名，从而引发来自反馈提供商的大量报告，则可能会导致其邮件服务器无法正常工作。类似地，由于反馈提供者现在需要将报告发送回签名者，反馈提供者可能会被大量请求报告的消息淹没，这些消息的签名无法验证。
Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information.
限制这些消息的生成速度可能是适当的，但可能会抑制重要且可能对时间敏感的信息的分发。
In general ARF feedback loop terms, it is often suggested that Feedback Providers only create these (or any) ARF reports after an out-of-band arrangement has been made between two parties. These extension mechanisms provide ways to adjust parameters of an authorized abuse report feedback loop that is configured and activated by private agreement. The alternative (sending reports automatically based solely on data found in the messages) may have unintended consequences.
在一般ARF反馈循环术语中，通常建议反馈提供者仅在双方做出带外安排后创建这些（或任何）ARF报告。这些扩展机制提供了调整授权滥用报告反馈循环参数的方法，授权滥用报告反馈循环由私人协议配置和激活。替代方案（仅根据消息中找到的数据自动发送报告）可能会产生意外后果。
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 [RFC5965] provides a limited form of mitigation. The host that generates reports can elect to send reports only periodically, with each report representing a number of identical or nearly identical incidents. One might even do
ARF[RFC5965]中引用的事件计数提供了一种有限形式的缓解措施。生成报告的主机可以选择仅定期发送报告，每个报告表示若干相同或几乎相同的事件。人们甚至可以这样做
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.
以指数反比的方式发送前十个事件中的每个事件的报告，然后每十个事件发送100个，然后每一百个事件发送1000个，以此类推，直到一段相对平静的时间之后，限制重置。
The use of this technique for "nearly 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 could 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.
然而，对“几乎相同”的事件使用这种技术尤其会导致报告质量下降。例如，如果来自一个攻击者的大量垃圾邮件，报告代理可以决定只发送一份关于这些邮件的一小部分的报告。虽然这避免了向系统管理员发送大量报告，但同样不会发送每个事件的确切细节。
Other rate-limiting provisions might be considered, such as detecting a temporary failure response from the report destination and thus halting report generation to that destination for some period, or simply imposing or negotiating a hard limit on the number of reports to be sent to a particular receiver in a given time frame.
可以考虑其他速率限制规定，例如检测来自报告目的地的临时故障响应，从而在一段时间内停止向该目的地生成报告，或者简单地对在给定时间范围内发送给特定接收者的报告数量施加或协商硬限制。
The author and editor wish to thank Steve Atkins, John Levine, Shmuel Metz, S. Moonesamy, and Alessandro Vesely for their contributions to this memo.
作者和编辑谨感谢史蒂夫·阿特金斯、约翰·莱文、施穆尔·梅茨、S.穆内萨米和亚历山德罗·维斯利对本备忘录的贡献。
All of the best practices referenced by this document are found in [RFC6449], written within the Collaboration Committee of the Messaging Anti-Abuse Working Group (MAAWG).
本文件引用的所有最佳实践见[RFC6449]，由信息传递反滥用工作组（MAAWG）协作委员会编写。
Finally, the original author wishes to thank the doctors and staff at the University of Texas MD Anderson Cancer Center for doing what they do.
最后，原作者希望感谢德克萨斯大学MD安德森癌症中心的医生和工作人员做他们所做的事情。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, August 2010.
[RFC5965]Shafranovich，Y.，Levine，J.，和M.Kucherawy，“电子邮件反馈报告的可扩展格式”，RFC 59652010年8月。
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, April 2012.
[RFC6591]Fontana，H.，“使用滥用报告格式的认证失败报告”，RFC 65912012年4月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997.
[RFC2142]Crocker，D.，“公共服务、角色和功能的邮箱名称”，RFC 2142，1997年5月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[RFC3912]Daigle，L.，“WHOIS协议规范”，RFC 3912，2004年9月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[RFC4408]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
[RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: not-spam", RFC 6430, November 2011.
[RFC6430]Li，K.和B.Leiba，“电子邮件反馈报告类型值：非垃圾邮件”，RFC 6430，2011年11月。
[RFC6449] Falk, J., Ed., "Complaint Feedback Loop Operational Recommendations", RFC 6449, November 2011.
[RFC6449]Falk，J.，Ed.，“投诉反馈回路操作建议”，RFC 6449，2011年11月。
[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月。
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, June 2012.
[RFC6651]Kucherawy，M.，“用于故障报告的域密钥识别邮件（DKIM）扩展”，RFC 66512012年6月。
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012.
[RFC6652]Kitterman，S.，“使用滥用报告格式的发送方策略框架（SPF）身份验证失败报告”，RFC 66522012年6月。
Authors' Addresses
作者地址
J.D. Falk Return Path 100 Mathilda Place, Suite 100 Sunnyvale, CA 94086 USA
美国加利福尼亚州桑尼维尔市玛蒂尔达广场100号J.D.福尔克返回通道，邮编94086
URI: http://www.returnpath.net/
URI: http://www.returnpath.net/
Murray S. Kucherawy (editor) Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
Murray S. Kucherawy（编辑）CuldMax 128国王圣，第二楼旧金山，CA 94107美国
EMail: superuser@gmail.com
EMail: superuser@gmail.com