Internet Engineering Task Force (IETF) Y. Shafranovich
Request for Comments: 5965 ShafTek Enterprises
Category: Standards Track J. Levine
ISSN: 2070-1721 Taughannock Networks
M. Kucherawy
Cloudmark
August 2010
Internet Engineering Task Force (IETF) Y. Shafranovich
Request for Comments: 5965 ShafTek Enterprises
Category: Standards Track J. Levine
ISSN: 2070-1721 Taughannock Networks
M. Kucherawy
Cloudmark
August 2010
An Extensible Format for Email Feedback Reports
电子邮件反馈报告的可扩展格式
Abstract
摘要
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used in Internet email.
本文档定义了一种可扩展格式和MIME类型，邮件操作员可以使用该格式和MIME类型向其他方报告收到的电子邮件的反馈。此格式旨在作为当前在Internet电子邮件中使用的各种现有报告格式的机器可读替代品。
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/rfc5965.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5965.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Purpose ....................................................3
1.2. Requirements ...............................................4
1.3. Definitions ................................................4
1.3.1. General .............................................4
1.3.2. Email Specific ......................................4
2. Format of Email Feedback Reports ................................4
3. The 'message/feedback-report' Content Type ......................5
3.1. Required Fields ............................................6
3.2. Optional Fields Appearing Once .............................6
3.3. Optional Fields Appearing Multiple Times ...................7
3.4. Notes about URIs ...........................................8
3.5. Formal Definition ..........................................8
4. Handling Malformed Reports .....................................10
5. Transport Considerations .......................................10
6. Extensibility ..................................................10
7. IANA Considerations ............................................11
7.1. MIME Type Registration of 'message/feedback-report' .......11
7.2. Feedback Report Header Fields .............................12
7.3. Feedback Report Type Values ...............................15
8. Security Considerations ........................................17
8.1. Inherited from RFC 3462 ...................................17
8.2. Interpretation ............................................17
8.3. Attacks against Authentication Methods ....................17
8.4. Intentionally Malformed Reports ...........................18
8.5. Omitting Data from ARF Reports ............................18
8.6. Automatically Generated ARF Reports .......................18
8.7. Attached Malware ..........................................18
8.8. The User-Agent Field ......................................18
8.9. Malformed Messages ........................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Acknowledgements .....................................22
Appendix B. Sample Feedback Reports ..............................22
B.1. Simple Report for Email Abuse without Optional Headers ...22
B.2. Full Report for Email Abuse with All Headers .............23
1. Introduction ....................................................3
1.1. Purpose ....................................................3
1.2. Requirements ...............................................4
1.3. Definitions ................................................4
1.3.1. General .............................................4
1.3.2. Email Specific ......................................4
2. Format of Email Feedback Reports ................................4
3. The 'message/feedback-report' Content Type ......................5
3.1. Required Fields ............................................6
3.2. Optional Fields Appearing Once .............................6
3.3. Optional Fields Appearing Multiple Times ...................7
3.4. Notes about URIs ...........................................8
3.5. Formal Definition ..........................................8
4. Handling Malformed Reports .....................................10
5. Transport Considerations .......................................10
6. Extensibility ..................................................10
7. IANA Considerations ............................................11
7.1. MIME Type Registration of 'message/feedback-report' .......11
7.2. Feedback Report Header Fields .............................12
7.3. Feedback Report Type Values ...............................15
8. Security Considerations ........................................17
8.1. Inherited from RFC 3462 ...................................17
8.2. Interpretation ............................................17
8.3. Attacks against Authentication Methods ....................17
8.4. Intentionally Malformed Reports ...........................18
8.5. Omitting Data from ARF Reports ............................18
8.6. Automatically Generated ARF Reports .......................18
8.7. Attached Malware ..........................................18
8.8. The User-Agent Field ......................................18
8.9. Malformed Messages ........................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Acknowledgements .....................................22
Appendix B. Sample Feedback Reports ..............................22
B.1. Simple Report for Email Abuse without Optional Headers ...22
B.2. Full Report for Email Abuse with All Headers .............23
As the spam problem continues to expand and potential solutions evolve, mail operators are increasingly exchanging abuse reports among themselves and other parties. However, different operators have defined their own formats, and thus the receivers of these reports are forced to write custom software to interpret each of them. In addition, many operators use various other report formats to provide non-abuse-related feedback about processed email. This memo uses the "multipart/report" content type defined in [REPORT], and in that context defines a standard extensible format by creating the "message/feedback-report" [MIME] type for these reports.
随着垃圾邮件问题的不断扩大和潜在解决方案的发展，邮件运营商之间以及其他各方之间越来越多地交换滥用报告。然而，不同的运营商定义了自己的格式，因此这些报告的接收者被迫编写自定义软件来解释每种格式。此外，许多运营商使用各种其他报告格式提供有关已处理电子邮件的非滥用相关反馈。此备忘录使用[report]中定义的“multipart/report”内容类型，并在该上下文中通过为这些报告创建“message/feedback report”[MIME]类型定义标准的可扩展格式。
While there has been previous work in this area (e.g., [STRADS-BCP] and [ASRG-ABUSE]), none of it has yet been successful. It is hoped that this document will have a better fate.
虽然此前在这方面已经开展了一些工作（例如，[STRADS-BCP]和[ASRG-PRASE]），但没有一项工作取得成功。希望这份文件会有更好的命运。
This format is intended primarily as an Abuse Reporting Format (ARF) for reporting email abuse but also includes support for direct feedback via end user mail clients, reports of some types of virus activity, and some similar issues. This memo also contains provision for extensions should other specific types of reports be desirable in the future.
此格式主要用作报告电子邮件滥用的滥用报告格式（ARF），但也包括通过最终用户邮件客户端直接反馈的支持、某些类型病毒活动的报告以及一些类似问题。本备忘录还规定，如果将来需要其他特定类型的报告，可延长报告期限。
This document only defines the format and [MIME] content type to be used for these reports. Determination of where these reports should be sent, validation of their contents, and how trust among report generators and report recipients is established are outside the scope of this document. It is assumed that best practices will evolve over time, and will be codified in future documents.
本文档仅定义用于这些报告的格式和[MIME]内容类型。确定这些报告应发送到何处、验证其内容以及如何在报告生成器和报告接收方之间建立信任不在本文件的范围之内。假定最佳做法将随着时间的推移而演变，并将编入未来的文件中。
The reports defined in this document are intended to inform mail operators about:
本文件中定义的报告旨在告知邮件运营商：
o email abuse originating from their networks;
o 来自其网络的电子邮件滥用；
o potential issues with the perceived quality of outbound mail, such as email service providers sending mail that attracts the attention of automated abuse detection systems.
o 出站邮件感知质量的潜在问题，例如电子邮件服务提供商发送的邮件引起了自动滥用检测系统的注意。
Please note that while the parent "multipart/report" content type defined in [REPORT] is used for all kinds of administrative messages, this format is intended specifically for communications among providers regarding email abuse and related issues, and SHOULD NOT be used for other reports.
请注意，尽管[report]中定义的父级“multipart/report”内容类型用于所有类型的管理邮件，但此格式专门用于提供商之间关于电子邮件滥用和相关问题的通信，不应用于其他报告。
The following requirements are necessary for feedback reports (the actual specification is defined later in this document):
反馈报告需要满足以下要求（实际规范在本文件后面定义）：
o They must be both human and machine readable;
o 它们必须是人类和机器可读的；
o A copy of the original email message (both body and header) or the message header must be enclosed in order to allow the receiver to handle the report properly;
o 必须附上原始电子邮件（正文和页眉）或邮件页眉的副本，以便收件人正确处理报告；
o The machine-readable section must provide ability for the report generators to share meta-data with receivers;
o 机器可读部分必须为报告生成器提供与接收者共享元数据的能力；
o The format must be extensible.
o 格式必须是可扩展的。
This section defines various terms used throughout this document.
本节定义了本文件中使用的各种术语。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
[EMAIL-ARCH] introduces several terms and concepts that are used in this memo, and thus readers are advised to become familiar with it as well.
[EMAIL-ARCH]介绍了本备忘录中使用的几个术语和概念，因此建议读者也熟悉这些术语和概念。
To satisfy the requirements, an email feedback report is defined as a [MIME] message with a top-level MIME content type of "multipart/ report" (as defined in [REPORT]). The following apply:
为了满足这些要求，电子邮件反馈报告被定义为具有顶级MIME内容类型“multipart/report”（如[report]中所定义）的[MIME]消息。以下各项适用：
a. The "report-type" parameter of the "multipart/report" type is set to "feedback-report";
a. “多部分/报告”类型的“报告类型”参数设置为“反馈报告”；
b. The first MIME part of the message contains a human-readable description of the report and MUST be included.
b. 消息的第一个MIME部分包含报告的可读描述，必须包括在内。
c. The second MIME part of the message is a machine-readable section with the content type of "message/feedback-report" (defined later in this memo) and MUST be included. This section is intended to convey meta-data about the report in question that may not be readily available from the included email message itself.
c. 消息的第二个MIME部分是一个机器可读的部分，其内容类型为“消息/反馈报告”（在本备忘录后面定义），必须包括在内。本节旨在传达有关相关报告的元数据，这些元数据可能无法从包含的电子邮件中获取。
d. The third MIME part of the message is either of type "message/ rfc822" (as defined in [MIME-TYPES]) and contains the original message in its entirety OR is 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]). While some operators may choose to modify or redact this portion for privacy or legal reasons, it is RECOMMENDED that the entire original email message be included without any modification as such modifications can impede forensic work by the recipient of this report. See Section 8 for further discussion.
d. 消息的第三个MIME部分是类型“message/rfc822”（如[MIME-TYPES]中所定义）并包含完整的原始消息，或者是类型“text/rfc822 headers”（如[REPORT]中所定义），并包含原始消息的整个头块的副本。必须包括该部分（与[报告]相反）。尽管出于隐私或法律原因，一些运营商可能会选择修改或修订此部分，但建议在不进行任何修改的情况下包含整个原始电子邮件，因为此类修改可能会妨碍本报告收件人的取证工作。进一步讨论见第8节。
e. Except as discussed below, each feedback report MUST be related to only a single email message. Summary and aggregate formats are outside of the scope of this specification.
e. 除以下讨论外，每个反馈报告必须仅与一封电子邮件相关。摘要和汇总格式不在本规范的范围内。
f. The Subject header field of the feedback report SHOULD be the same as the included email message about which the report is being generated. If it differs, the difference MUST be limited to only a typical forwarding prefix used by Mail User Agents (MUAs) such as "FW:". (Many smaller operators using MUAs for abuse handling rely on the subject lines for processing.)
f. 反馈报告的主题标题字段应与生成报告时所包含的电子邮件消息相同。如果不同，则差异必须仅限于邮件用户代理（MUA）使用的典型转发前缀，如“FW:”。（许多使用MUA进行虐待处理的小型运营商依赖主题行进行处理。）
g. The primary evidence of the abuse being reported is found in the third part of the report, which contains the original message. The second part contains additional derived data that may help the receiver, but in terms of selecting actionable report data, report recipients SHOULD use the content of the third part first, then data from the second part. The first part is meant to contain explanatory text for human use but is not itself a part of the report, and SHOULD NOT be used if it is in conflict with the other parts.
g. 报告的第三部分载有原始信息，是报告所述虐待行为的主要证据。第二部分包含可能有助于接收者的其他派生数据，但就选择可操作的报告数据而言，报告接收者应首先使用第三部分的内容，然后使用第二部分的数据。第一部分旨在包含供人使用的解释性文本，但其本身不是报告的一部分，如果与其他部分冲突，则不应使用。
A new [MIME] content type called "message/feedback-report" is defined. This content type provides a machine-readable section intended to let the report generator convey meta-data to the report receiver. The intent of this section is to convey information that may not be obvious or may not be easily extracted from the original email message body or header.
定义了名为“消息/反馈报告”的新[MIME]内容类型。此内容类型提供了一个机器可读的部分，旨在让报表生成器将元数据传递给报表接收方。本节的目的是传达可能不明显或不容易从原始电子邮件正文或标题中提取的信息。
The body of this content type consists of multiple "fields" formatted according to the ABNF of [MAIL] header fields. This section defines the initial set of fields provided by this specification. Additional fields may be registered according to the procedure described later in this memo. Although these fields have a syntax similar to those of mail message header fields, they are semantically distinct; hence, they SHOULD NOT be repeated as header fields of the message containing the report. Note that these fields represent information that the receiver is asserting about the report in question, but are not necessarily verifiable. Report receivers MUST NOT assume that these assertions are always accurate.
此内容类型的正文由多个“字段”组成，这些字段的格式根据[MAIL]标题字段的ABNF设置。本节定义了本规范提供的初始字段集。可根据本备忘录后面描述的程序注册其他字段。尽管这些字段的语法与邮件消息头字段的语法相似，但它们在语义上是不同的；因此，它们不应作为包含报告的消息的标题字段重复。请注意，这些字段表示接收方声明的有关报告的信息，但不一定是可验证的。报告接收者不得假设这些断言总是准确的。
Note that the above limitation in no way restricts the use of message header fields that are registered in the IANA header field registry with the same field names.
请注意，上述限制并不限制在IANA标头字段注册表中注册的具有相同字段名的消息标头字段的使用。
The following report header fields MUST appear exactly once:
以下报告标题字段必须只出现一次：
o "Feedback-Type" contains the type of feedback report (as defined in the corresponding IANA registry and later in this memo). This is intended to let report parsers distinguish among different types of reports.
o “反馈类型”包含反馈报告的类型（定义见相应的IANA注册表和本备忘录后面部分）。这是为了让报表解析器区分不同类型的报表。
o "User-Agent" indicates the name and version of the software program that generated the report. The format of this field MUST follow section 14.43 of [HTTP]. This field is for documentation only; there is no registry of user agent names or versions, and report receivers SHOULD NOT expect user agent names to belong to a known set.
o “用户代理”表示生成报告的软件程序的名称和版本。此字段的格式必须遵循[HTTP]第14.43节。此字段仅用于文档编制；没有用户代理名称或版本的注册表，报告接收者不应期望用户代理名称属于已知的集合。
o "Version" indicates the version of specification that the report generator is using to generate the report. The version number in this specification is set to "1".
o “版本”表示报表生成器用于生成报表的规范版本。本规范中的版本号设置为“1”。
The following header fields are optional and MUST NOT appear more than once:
以下标题字段是可选的，不能出现多次：
o "Original-Envelope-Id" contains the envelope ID string used in the original [SMTP] transaction (see section 2.2.1 of [DSN]).
o “原始信封Id”包含原始[SMTP]交易中使用的信封Id字符串（见[DSN]第2.2.1节）。
o "Original-Mail-From" contains a copy of the email address used in the MAIL FROM portion of the original SMTP transaction. The format of this field is defined in section 4.1.2 of [SMTP] as "Reverse-path".
o “原始邮件发件人”包含原始SMTP事务的邮件发件人部分中使用的电子邮件地址的副本。[SMTP]第4.1.2节将此字段的格式定义为“反向路径”。
o "Arrival-Date" indicates the date and time at which the original message was received by the Mail Transfer Agent (MTA) of the generating ADMD (Administrative Management Domain). This field MUST be formatted as per section 3.3 of [MAIL].
o “到达日期”表示生成ADMD（管理管理域）的邮件传输代理（MTA）接收原始邮件的日期和时间。此字段的格式必须符合[邮件]第3.3节的规定。
o "Reporting-MTA" indicates the name of the MTA generating this feedback report. This field is defined in section 2.2.2 of [DSN], except that it is an optional field in this report.
o “Reporting MTA”表示生成此反馈报告的MTA的名称。该字段在[DSN]的第2.2.2节中定义，但它是本报告中的可选字段。
o "Source-IP" contains an IPv4 or IPv6 address of the MTA from which the original message was received. Addresses MUST be formatted as per section 4.1.3 of [SMTP].
o “源IP”包含从中接收原始邮件的MTA的IPv4或IPv6地址。地址的格式必须符合[SMTP]第4.1.3节的规定。
o "Incidents" contains an unsigned 32-bit integer indicating the number of incidents this report represents. The absence of this field implies the report covers a single incident.
o “事件”包含一个无符号32位整数，表示此报告所代表的事件数。缺少此字段意味着报告涵盖单个事件。
The historic field "Received-Date" SHOULD also be accepted and interpreted identically to "Arrival-Date". However, if both are present, the report is malformed and SHOULD be treated as described in Section 4.
历史字段“接收日期”也应被接受，并与“到达日期”的解释相同。但是，如果两者都存在，则报告格式不正确，应按照第4节中的说明进行处理。
The following set of header fields are optional and may appear any number of times as appropriate:
以下标题字段集是可选的，可能会出现任意次数（视情况而定）：
o "Authentication-Results" indicates the result of one or more authentication checks run by the report generator. The format of this field is defined in [AUTH-RESULTS]. Report receivers should note that this field only indicates an assertion made by the report generator.
o “身份验证结果”表示报表生成器运行的一个或多个身份验证检查的结果。此字段的格式在[AUTH-RESULTS]中定义。报表接收者应注意，此字段仅表示报表生成器所做的断言。
o "Original-Rcpt-To" includes a copy of the email address used in the RCPT TO portion of the original [SMTP] transaction. The format of this field is a "Reverse-path" defined in section 4.1.2 of that memo. This field SHOULD be repeated for every SMTP recipient seen by the report generator.
o “原始Rcpt To”包括原始[SMTP]交易的Rcpt To部分中使用的电子邮件地址的副本。该字段的格式为该备忘录第4.1.2节中定义的“反向路径”。对于报表生成器看到的每个SMTP收件人，应重复此字段。
o "Reported-Domain" includes a domain name that the report generator believes to be relevant to the report, e.g., the domain whose apparent actions provoked the generation of the report. It is unspecified how the report generator determines this information, and thus the report receiver cannot be certain how it was chosen. It is often used as a means of suggesting to the report receiver how this report might be handled. In cases where the derivation
o “报告域”包括报告生成器认为与报告相关的域名，例如，其明显行为引发报告生成的域。未指定报告生成器如何确定此信息，因此报告接收者无法确定其选择方式。它通常被用作向报告接收者建议如何处理该报告的一种方法。如果派生
is not obvious, the report generator is encouraged to clarify in the text section of the report. Domain format is defined in section 2.3.1 of [DNS].
不明显，鼓励报告生成器在报告的文本部分进行澄清。域格式在[DNS]第2.3.1节中定义。
o "Reported-URI" indicates a URI that the report generator believes to be relevant to the report, e.g., a suspect URI that was found in the message that caused the report to be generated. The same caveats about the origin of the value of "Reported-Domain" apply to this field. The URI format is defined in [URI].
o “报告的URI”表示报告生成器认为与报告相关的URI，例如，在导致生成报告的消息中发现的可疑URI。关于“Reported Domain”值的来源的警告同样适用于此字段。URI格式在[URI]中定义。
Implementors should be aware that the Reported-URI field can carry many different types of data depending on the URI scheme used. For more information, please consult the "URI Schemes" registry maintained by IANA.
实现者应该知道，根据所使用的URI方案，报告的URI字段可以携带许多不同类型的数据。有关更多信息，请查阅IANA维护的“URI方案”注册表。
Furthermore, it is outside the scope of this standard whether the data carried in this field implies any additional information. Implementors may negotiate their own agreements surrounding the interpretation of this data.
此外，此字段中的数据是否包含任何附加信息不在本标准范围内。实施者可以围绕这些数据的解释协商他们自己的协议。
The formal definition of the contents of a "message/feedback-report" media type using [ABNF] is as follows:
使用[ABNF]对“消息/反馈报告”媒体类型内容的正式定义如下：
feedback-report = *( feedback-type / user-agent / version )
opt-fields-once
*( opt-fields-many )
*( ext-field )
feedback-report = *( feedback-type / user-agent / version )
opt-fields-once
*( opt-fields-many )
*( ext-field )
feedback-type = "Feedback-Type:" [CFWS] token [CFWS] CRLF ; the "token" must be a registered feedback type as ; described elsewhere in this document
反馈类型=“反馈类型：”[CFWS]令牌[CFWS]CRLF；“令牌”必须是注册的反馈类型，如：；本文件其他部分描述
user-agent = "User-Agent:" [CFWS] product *( CFWS product ) [CFWS] CRLF
用户代理=“用户代理：”[CFWS]产品*（CFWS产品）[CFWS]CRLF
version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF
; as described above
version = "Version:" [CFWS] %x31-39 *DIGIT [CFWS] CRLF
; as described above
opt-fields-once = [ arrival-date ]
[ incidents ]
[ original-envelope-id ]
[ original-mail-from ]
[ reporting-mta ]
[ source-ip ]
opt-fields-once = [ arrival-date ]
[ incidents ]
[ original-envelope-id ]
[ original-mail-from ]
[ reporting-mta ]
[ source-ip ]
arrival-date = "Arrival-Date:" [CFWS] date-time CRLF
到货日期=“到货日期：”[CFWS]日期时间CRLF
incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
; must be a 32-bit unsigned integer
incidents = "Incidents:" [CFWS] 1*DIGIT [CFWS] CRLF
; must be a 32-bit unsigned integer
original-envelope-id = "Original-Envelope-Id:" [CFWS] envelope-id [CFWS] CRLF
原始信封id=“原始信封id:”[CFWS]信封id[CFWS]CRLF
original-mail-from = "Original-Mail-From:" [CFWS] reverse-path [CFWS] CRLF
原始邮件发件人=“原始邮件发件人：”[CFWS]反向路径[CFWS]CRLF
reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";" [CFWS] mta-name [CFWS] CRLF
reporting mta=“reporting mta:[CFWS]mta名称类型[CFWS]；”[CFWS]mta名称[CFWS]CRLF
source-ip = "Source-IP:" [CFWS] ( IPv4-address-literal / IPv6-address-literal ) [CFWS] CRLF
source ip=“source ip:[CFWS]（IPv4地址文本/IPv6地址文本）[CFWS]CRLF
opt-fields-many = [ authres-header ]
[ original-rcpt-to ]
[ reported-domain ]
[ reported-uri ]
opt-fields-many = [ authres-header ]
[ original-rcpt-to ]
[ reported-domain ]
[ reported-uri ]
original-rcpt-to = "Original-Rcpt-To:" [CFWS] forward-path [CFWS] CRLF
原始rcpt to=“原始rcpt to:”[CFWS]转发路径[CFWS]CRLF
reported-domain = "Reported-Domain:" [CFWS] domain [CFWS] CRLF
reported domain=“reported domain:[CFWS]域[CFWS]CRLF
reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF
reported uri=“reported uri:[CFWS]uri[CFWS]CRLF
ext-field = field-name ":" unstructured
ext field=字段名“：”非结构化
A set of fields satisfying this ABNF may appear in the transmitted message in any order.
满足此ABNF的一组字段可能以任何顺序出现在传输的消息中。
"CRLF" and "DIGIT" are imported from [ABNF].
“CRLF”和“数字”从[ABNF]导入。
"token" is imported from [MIME].
“令牌”是从[MIME]导入的。
"product" is imported from [HTTP].
“产品”是从[HTTP]导入的。
"field-name", "unstructured", "CFWS", "date-time", and "domain" are imported from [MAIL].
“字段名”、“非结构化”、“CFWS”、“日期-时间”和“域”从[邮件]导入。
"envelope-id", "mta-name-type", and "mta-name" are imported from [DSN].
“信封id”、“mta名称类型”和“mta名称”从[DSN]导入。
"reverse-path", "forward-path", "local-part", "IPv4-address-literal", and "IPv6-address-literal" are imported from [SMTP].
“反向路径”、“转发路径”、“本地部分”、“IPv4地址文字”和“IPv6地址文字”从[SMTP]导入。
"URI" is imported from [URI].
“URI”是从[URI]导入的。
"authres-header" is imported from [AUTH-RESULTS].
“authres头”是从[AUTH-RESULTS]导入的。
"ext-field" refers to extension fields, which are discussed in Section 6.
“ext字段”指扩展字段，在第6节中讨论。
When an agent that accepts and handles ARF messages receives a message that purports (by MIME type) to be an ARF message but syntactically deviates from this specification, that agent SHOULD ignore or reject the message. Where rejection is performed, the rejection notice (either via an [SMTP] reply or generation of a [DSN]) SHOULD identify the specific cause for the rejection.
当接受和处理ARF消息的代理接收到声称（通过MIME类型）是ARF消息但语法上偏离此规范的消息时，该代理应忽略或拒绝该消息。如果执行拒绝，拒绝通知（通过[SMTP]回复或生成[DSN]）应确定拒绝的具体原因。
See Section 8.9 for further discussion.
进一步讨论见第8.9节。
[DSN] requires that its reports be sent with the empty [SMTP] envelope sender to avoid bounce loops. A similar requirement was considered for this specification, but it seems unlikely that an ARF report would be generated in response to receipt of an ARF report, and furthermore such a requirement would prevent an ARF generator from ever determining that an ARF report was not actually received.
[DSN]要求使用空[SMTP]信封发件人发送其报告，以避免跳出循环。本规范考虑了类似的要求，但似乎不太可能在收到ARF报告后生成ARF报告，而且该要求将阻止ARF生成器确定实际未收到ARF报告。
On the other hand, if an ARF report is generated without the empty envelope sender and is sent to an address that actually does not work, then the generating address can also be overwhelmed by DSNs as a denial-of-service attack (see Section 8.6).
另一方面，如果在没有空信封发送方的情况下生成ARF报告，并将其发送到实际不起作用的地址，则生成的地址也可能被DSN淹没，成为拒绝服务攻击（参见第8.6节）。
This specification therefore makes no requirement related to the envelope sender of a generated report. Operators will have to consider what envelope sender to use within the context of their own installations.
因此，本规范不要求与生成报告的信封发送者相关。运营商将不得不考虑信封寄件人在自己安装的上下文中使用。
Like many other formats and protocols, this format may need to be extended over time to fit the ever-changing landscape of the Internet. Therefore, extensibility is provided via two IANA registries: one for feedback types and a second for report header fields. The feedback type registry is to be used in conjunction with the "Feedback-Type" field above. The header name registry is
与许多其他格式和协议一样，此格式可能需要随着时间的推移进行扩展，以适应不断变化的互联网环境。因此，可扩展性是通过两个IANA注册表提供的：一个用于反馈类型，另一个用于报告头字段。反馈类型注册表将与上面的“反馈类型”字段一起使用。标题名称注册表为
intended for registration of new meta-data fields to be used in the machine-readable portion (part 2) of this format. Please note that version numbers do not change with new field registrations unless a new specification of this format is published. Also, note that all new field registrations may only be registered as optional fields. Any new required fields REQUIRE a new version of this specification to be published.
用于注册本格式机器可读部分（第2部分）中使用的新元数据字段。请注意，除非发布此格式的新规范，否则版本号不会随新的字段注册而更改。另外，请注意，所有新字段注册只能注册为可选字段。任何新的必填字段都要求发布本规范的新版本。
In order to encourage extensibility and interoperability of this format, implementors MUST ignore any fields or report types they do not explicitly support.
为了鼓励这种格式的可扩展性和互操作性，实现者必须忽略他们不明确支持的任何字段或报告类型。
Additional report types (extension report types) or report header fields might be defined in the future by later revisions to this specification, or by registrations as described above. Such types and fields MUST be registered as described above and published in an Open Specification such as an RFC.
其他报告类型（扩展报告类型）或报告标题字段可能在将来通过本规范的后续修订或如上所述的注册来定义。此类类型和字段必须如上所述进行注册，并在开放规范（如RFC）中发布。
Experimental report types and report header fields MUST only be used between ADMDs that have explicitly consented to use them. These names and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and are not suitable for general use.
实验报告类型和报告标题字段只能在明确同意使用它们的ADMD之间使用。RFCs中未记录这些名称及其相关参数。因此，它们随时可能发生变化，不适合一般使用。
IANA has registered a new [MIME] type and created two new registries, as described below.
IANA注册了一个新的[MIME]类型，并创建了两个新的注册表，如下所述。
This section provides the media type registration application from [MIME-REG] for processing by IANA:
本节提供[MIME-REG]中的媒体类型注册应用程序，供IANA处理：
To: ietf-types@iana.org
致：ietf-types@iana.org
Subject: Registration of media type message/feedback-report
主题：媒体类型消息/反馈报告的注册
Type name: message
类型名称：消息
Subtype name: feedback-report
子类型名称：反馈报告
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
编码注意事项：“7bit”编码已足够，必须用于在非MIME邮件阅读器查看时保持可读性。
Security considerations: See Section 8 of [RFC5965].
安全注意事项：见[RFC5965]第8节。
Interoperability considerations: Implementors MUST ignore any fields they do not support.
互操作性注意事项：实现者必须忽略他们不支持的任何字段。
Published specification: [RFC5965]
已发布规范：[RFC5965]
Applications that use this media type: Abuse helpdesk software for ISPs, mail service bureaus, mail certifiers, and similar organizations
使用此媒体类型的应用程序：滥用ISP、邮件服务局、邮件认证机构和类似组织的帮助台软件
Additional information: none
其他信息：无
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Yakov Shafranovich <ietf@shaftek.org>
Yakov Shafranovich <ietf@shaftek.org>
Murray S. Kucherawy <msk@cloudmark.com>
Murray S. Kucherawy <msk@cloudmark.com>
Intended usage: COMMON
预期用途：普通
Author:
作者：
Yakov Shafranovich
雅科夫·沙夫拉诺维奇
John R. Levine
约翰·R·莱文
Murray S. Kucherawy
默里·S·库切拉维
Change controller: IESG
更改控制器：IESG
IANA has created the "Feedback Report Header Fields" registry. This registry contains header fields for use in feedback reports, as defined by this memo.
IANA已经创建了“反馈报告标题字段”注册表。此注册表包含用于此备忘录定义的反馈报告的标题字段。
New registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA]. Any new field thus registered is considered optional by this specification unless a new version of this memo is published.
新注册或更新必须按照[IANA]中所述的“所需规范”指南发布。除非发布了本备忘录的新版本，否则本规范认为任何新注册的字段都是可选的。
New registrations and updates MUST contain the following information:
新注册和更新必须包含以下信息：
1. Name of the field being registered or updated
1. 正在注册或更新的字段的名称
2. Short description of the field
2. 字段的简短描述
3. Whether the field can appear more than once
3. 该字段是否可以出现多次
4. To which feedback type(s) this field applies (or "any")
4. 此字段适用于哪种反馈类型（或“任何”）
5. The document in which the specification of the field is published
5. 发布字段规范的文档
6. New or updated status, which MUST be one of:
6. 新状态或更新状态，必须是以下状态之一：
current: The field is in current use
当前：该字段处于当前使用状态
deprecated: The field is in current use but its use is discouraged
不推荐使用：该字段当前正在使用，但不鼓励使用
historic: The field is no longer in current use
历史：该字段不再处于当前使用状态
An update may make a notation on an existing registration indicating that a registered field is historic or deprecated if appropriate.
更新可能会在现有注册上做标记，表明已注册字段是历史字段或已弃用字段（如果适用）。
The initial registry contains these values:
初始注册表包含以下值：
Field Name: Arrival-Date Description: date/time the original message was received Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：到达日期描述：收到原始邮件的日期/时间多次出现：无相关“反馈类型”：在[RFC5965]中发布的任何信息状态：当前
Field Name: Authentication-Results Description: results of authentication check(s) Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：身份验证结果说明：身份验证检查结果多次出现：是相关的“反馈类型”：任何在：[RFC5965]中发布的状态：当前
Field Name: Feedback-Type Description: registered feedback report type Multiple Appearances: No Related "Feedback-Type": N/A Published in: [RFC5965] Status: current
字段名称：反馈类型说明：已注册反馈报告类型多次出现：无相关“反馈类型”：未在[RFC5965]中发布状态：当前
Field Name: Incidents Description: expression of how many similar incidents are represented by this report Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：事件描述：此报告表示多少类似事件多次出现：无相关“反馈类型”：在：[RFC5965]中发布的任何事件状态：当前
Field Name: Original-Mail-From Description: email address used in the MAIL FROM portion of the original SMTP transaction Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：原始邮件发件人描述：原始SMTP事务的邮件发件人部分中使用的电子邮件地址多次出现：无相关“反馈类型”：在[RFC5965]中发布的任何邮件状态：当前
Field Name: Original-Rcpt-To Description: email address used in the RCPT TO portion of the original SMTP transaction Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：原始Rcpt To说明：原始SMTP事务的Rcpt To部分中使用的电子邮件地址多次出现：是相关的“反馈类型”：在：[RFC5965]中发布的任何邮件状态：当前
Field Name: Received-Date Description: date/time the original message was received (replaced by "Arrival-Date") Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: historic
字段名称：接收日期描述：接收原始邮件的日期/时间（替换为“到达日期”）多次出现：无相关“反馈类型”：在：[RFC5965]中发布的任何状态：历史
Field Name: Reported-Domain Description: a domain name the report generator considers to be key to the message about which a report is being generated Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：报告的域描述：报告生成器认为是生成报告的消息关键的域名多次出现：是相关的“反馈类型”：任何在：[RFC5965]中发布的状态：当前
Field Name: Reported-URI Description: a URI the report generator considers to be key to the message about which a report is being generated Multiple Appearances: Yes Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：报告的URI说明：报告生成器认为是生成报告的消息的关键URI多次出现：是相关的“反馈类型”：在：[RFC5965]中发布的任何URI状态：当前
Field Name: Reporting-MTA Description: MTA generating this report Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：报告MTA说明：生成此报告的MTA多次出现：无相关“反馈类型”：任何在：[RFC5965]中发布的状态：当前
Field Name: Source-IP Description: IPv4 or IPv6 address from which the original message was received Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：源IP描述：从中接收原始消息的IPv4或IPv6地址多次出现：无相关“反馈类型”：在[RFC5965]中发布的任何状态：当前
Field Name: User-Agent Description: name and version of the program generating the report Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：用户代理描述：生成报告的程序的名称和版本多次出现：无相关的“反馈类型”：在[RFC5965]中发布的任何状态：当前
Field Name: Version Description: version of specification used Multiple Appearances: No Related "Feedback-Type": any Published in: [RFC5965] Status: current
字段名称：版本描述：使用多个外观的规范版本：无相关“反馈类型”：在[RFC5965]中发布的任何版本状态：当前
IANA has created the "Feedback Report Type Values" registry. This registry contains feedback types for use in feedback reports, defined by this memo.
IANA已经创建了“反馈报告类型值”注册表。此注册表包含在此备忘录定义的反馈报告中使用的反馈类型。
New registrations or updates MUST be published in accordance with the "Specification Required" guidelines as described in [IANA]. Any new field thus registered is considered optional by this specification unless a new version of this memo is published.
新注册或更新必须按照[IANA]中所述的“所需规范”指南发布。除非发布了本备忘录的新版本，否则本规范认为任何新注册的字段都是可选的。
New registrations MUST contain the following information:
新注册必须包含以下信息：
1. Name of the feedback type being registered
1. 正在注册的反馈类型的名称
2. Short description of the feedback type
2. 反馈类型的简短描述
3. The document in which the specification of the field is published
3. 发布字段规范的文档
4. New or updated status, which MUST be one of:
4. 新状态或更新状态，必须是以下状态之一：
current: The field is in current use
当前：该字段处于当前使用状态
deprecated: The field is in current use but its use is discouraged
不推荐使用：该字段当前正在使用，但不鼓励使用
historic: The field is no longer in current use
历史：该字段不再处于当前使用状态
The initial registry contains these values:
初始注册表包含以下值：
Feedback Type Name: abuse Description: unsolicited email or some other kind of email abuse Published in: [RFC5965] Status: current
反馈类型名称：滥用描述：在[RFC5965]中发布的未经请求的电子邮件或其他类型的电子邮件滥用状态：当前
Feedback Type Name: fraud Description: indicates some kind of fraud or phishing activity Published in: [RFC5965] Status: current
反馈类型名称：欺诈描述：表示在[RFC5965]中发布的某种欺诈或网络钓鱼活动状态：当前
Feedback Type Name: other Description: any other feedback that does not fit into other registered types Published in: [RFC5965] Status: current
反馈类型名称：其他描述：不适合在[RFC5965]中发布的其他注册类型的任何其他反馈状态：当前
Feedback Type Name: virus Description: report of a virus found in the originating message Published in: [RFC5965] Status: current
反馈类型名称：病毒描述：在[RFC5965]中发布的原始邮件中发现病毒的报告状态：当前
The following security considerations apply when generating or processing a feedback report:
生成或处理反馈报告时，以下安全注意事项适用：
All of the Security Considerations from [REPORT] are inherited here.
[REPORT]中的所有安全注意事项都在此处继承。
This specification describes a report format. The authentication and validity of the content of the report SHOULD be established through other means. The content of an unvetted report could be wrong, incomplete or deliberately false, including the alleged abuse incident in the third part, derived data in the second part or the human-readable first part.
本规范描述了一种报告格式。报告内容的认证和有效性应通过其他方式确定。未录音报告的内容可能是错误的、不完整的或故意虚假的，包括第三部分中指称的虐待事件、第二部分中的衍生数据或人类可读的第一部分。
There will be some desire to perform some actions in an automated fashion in order to enact timely responses to common feedback reports. Caution must be taken, however, as there is no substantial security around the content of these reports. An attacker could craft a report meant to generate undesirable actions on the part of a report recipient.
人们希望以自动化的方式执行某些操作，以便对常见的反馈报告做出及时的响应。但是，必须谨慎，因为这些报告的内容没有实质性的安全性。攻击者可以精心编制一份报告，以便在报告收件人方面生成不需要的操作。
It is suggested that the origin of an ARF report be vetted, such as by using common message authentication schemes like [SMIME], [DKIM], [SPF], or [SENDERID], prior to the undertaking of any kind of automated action in response to receipt of the report. In particular, S/MIME offers the strongest authentication and the cost of key exchange is assumed in the process of establishing a bilateral reporting relationship that uses this specification; however, it is not as transparent as the others and thus will interfere with the parsing capabilities of code that is designed specifically to handle multipart/report messages.
建议对ARF报告的来源进行审查，例如在收到报告后采取任何类型的自动行动之前，使用[SMIME]、[DKIM]、[SPF]或[SENDERID]等通用消息验证方案。特别是，S/MIME提供了最强的身份验证，并且在建立使用该规范的双边报告关系的过程中假设了密钥交换的成本；但是，它不像其他代码那样透明，因此会干扰专门用于处理多部分/报告消息的代码的解析功能。
The details of the required validation to achieve this are a matter of local policy and are thus outside the scope of this specification.
实现这一点所需验证的细节是当地政策的问题，因此不在本规范的范围内。
If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this header field can be misleading. It follows that any attack against an authentication method that might be used to protect the authenticity of an abuse report is also a security consideration here.
如果已知针对身份验证方法的攻击，那么验证该方法的代理显然会被愚弄，认为不真实的消息是真实的，因此此头字段的值可能会产生误导。因此，对可能用于保护滥用报告真实性的身份验证方法的任何攻击在这里也是一个安全考虑因素。
It is possible for an attacker to generate an ARF message field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in recipient parsing code. Implementors SHOULD thoroughly verify all such messages and be robust against intentionally as well as unintentionally malformed messages.
攻击者有可能生成异常大或格式错误的ARF消息字段，以试图发现或利用收件人解析代码中的弱点。实现者应该彻底验证所有这些消息，并对有意或无意的错误消息保持健壮。
The sending of these reports can reveal possibly private information about the person sending the report. For example, such a report sent in response to a mailing list posting will reveal to the report recipient a valid email address on the list that might otherwise have remained hidden.
发送这些报告可能会泄露发送报告人的私人信息。例如，为响应邮件列表发布而发送的此类报告将向报告收件人显示列表上的有效电子邮件地址，否则该地址可能一直隐藏。
For this reason, report generators might wish to redact portions of the report to conceal private information. Doing so could be necessary where privacy trumps operational necessity, but, as mentioned in Section 2, it might impede a timely or meaningful response from the report recipient.
因此，报表生成器可能希望编辑报表的某些部分以隐藏私人信息。如果隐私高于运营需要，则有必要这样做，但如第2节所述，这可能会妨碍报告接收人及时或有意义的回应。
Systems have been implemented that generate ARF reports automatically in response to an event. For example, software monitoring a honeypot email address might generate an ARF report immediately upon delivery of any message to it. An attacker that becomes aware of such a configuration can exploit it to attack an ARF recipient with automatically generated ARF reports.
已经实施了自动生成ARF报告以响应事件的系统。例如，监控蜜罐电子邮件地址的软件可能会在向其发送任何消息后立即生成ARF报告。意识到此类配置的攻击者可以利用该配置利用自动生成的ARF报告攻击ARF收件人。
As this format is sometimes used to automatically report malware, ARF processors (human or otherwise) SHOULD ensure that attachments are processed in a manner appropriate for unverified and potentially hostile data.
由于此格式有时用于自动报告恶意软件，ARF处理器（人工或其他）应确保附件的处理方式适合未经验证和潜在恶意数据。
Further to Section 8.2, the User-Agent field is an assertion of the generating software and is neither specified in this memo nor derived from the message represented in the third part of the report. It is intended for documentation and debugging, and since it is trivially forged by a malicious agent, it SHOULD NOT be interpreted by recipients.
除第8.2节外，用户代理字段是生成软件的断言，未在本备忘录中指定，也未从报告第三部分中表示的消息中派生。它用于文档编制和调试，并且由于恶意代理可以轻易伪造它，因此收件人不应该对其进行解释。
Further to the discussion in Section 4, there might be cases where an ARF processing agent elects to accept messages not consistent with this specification, such as during transition periods where some fields are moving toward "historic" or "deprecated" status, or the introduction of new non-standard extension or experimental fields. Such choices need to be implemented with extreme caution; where two different fields have related meaning (e.g., "Received-Date", which is historic, and "Arrival-Date", which is current), an attacker could craft a report that makes a confusing claim in an attempt to exploit such liberal parsing logic.
除第4节中的讨论外，可能存在ARF处理代理选择接受与本规范不一致的消息的情况，例如在过渡期内，某些字段正在向“历史”或“不推荐”状态移动，或者引入新的非标准扩展或实验字段。这些选择需要极其谨慎地实施；如果两个不同的字段具有相关的含义（例如，“接收日期”是历史字段，“到达日期”是当前字段），攻击者可以编写一份报告，提出令人困惑的声明，试图利用这种自由的解析逻辑。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[AUTH-RESULTS] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[AUTH-RESULTS]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 54512009年4月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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月。
[HTTP] 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.
[HTTP]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[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-REG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[MIME-REG]Freed，N.和J.Klensin，“媒体类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[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] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[报告]Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[ASRG-ABUSE] Anti-Spam Research Group (ASRG) of the Internet Research Task Force (IRTF), "Abuse Reporting Standards Subgroup of the ASRG", May 2005.
互联网研究工作队（IRTF）反垃圾邮件研究小组（ASRG），“ASRG滥用报告标准分组”，2005年5月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月。
[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月。
[SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[SENDERID]Lyon，J.和M.Wong，“发件人ID:验证电子邮件”，RFC 4406，2006年4月。
[SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[SMIME]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，2010年1月。
[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月。
[STRADS-BCP] Crissman, G., "Proposed Spam Reporting BCP Document", May 2005.
[STRADS-BCP]Crisman，G.，“拟议的垃圾邮件报告BCP文件”，2005年5月。
The authors would like to thank many of the members of the email community who provided helpful comments and suggestions for this document including many of the participants in ASRG, IETF, and MAAWG activities, and all of the members of the abuse-feedback-report public mailing list.
作者要感谢电子邮件社区的许多成员，他们为本文件提供了有益的意见和建议，包括ASRG、IETF和MAAWG活动的许多参与者，以及滥用反馈报告公共邮件列表的所有成员。
This section presents some examples of the use of this message format to report feedback about an arriving message.
本节介绍了使用此消息格式报告有关到达消息的反馈的一些示例。
Simple report:
简单报告：
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information about this format please see http://www.mipassoc.org/arf/.
这是2005年3月8日星期四美国东部夏令时14:00:00从IP 192.0.2.1收到的电子邮件滥用报告。有关此格式的更多信息，请参阅http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary Content-Type: message/feedback-report
--第1部分\u 13d.2e68ed54 \u边界内容类型：消息/反馈报告
Feedback-Type: abuse User-Agent: SomeGenerator/1.0 Version: 1
反馈类型：滥用用户代理：SomeGenerator/1.0版本：1
--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline
--第1部分\u 13d.2e68ed54 \u边界内容类型：消息/rfc822内容处置：内联
Received: from mailserver.example.net (mailserver.example.net [192.0.2.1]) by example.com with ESMTP id M63d4137594e46; Thu, 08 Mar 2005 14:00:00 -0400
已接收：来自example.com的mailserver.example.net（mailserver.example.net[192.0.2.1]），ESMTP id为M63d4137594e46；2005年3月8日星期四14:00:00-0400
From: <somespammer@example.net>
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
From: <somespammer@example.net>
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam --part1_13d.2e68ed54_boundary--
垃圾邮件-第1部分\u 13d.2e68ed54 \u边界--
Example 1: Required fields only
示例1：仅限必填字段
Illustration of a feedback report generated according to this specification. Only the required fields are used.
根据本规范生成的反馈报告的图示。仅使用必填字段。
A full email abuse report:
完整的电子邮件滥用报告：
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
From: <abusedesk@example.com>
Date: Thu, 8 Mar 2005 17:40:36 EDT
Subject: FW: Earn money
To: <abuse@example.net>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
boundary="part1_13d.2e68ed54_boundary"
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
--part1_13d.2e68ed54_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
This is an email abuse report for an email message received from IP 192.0.2.1 on Thu, 8 Mar 2005 14:00:00 EDT. For more information about this format please see http://www.mipassoc.org/arf/.
这是2005年3月8日星期四美国东部夏令时14:00:00从IP 192.0.2.1收到的电子邮件滥用报告。有关此格式的更多信息，请参阅http://www.mipassoc.org/arf/.
--part1_13d.2e68ed54_boundary Content-Type: message/feedback-report
--第1部分\u 13d.2e68ed54 \u边界内容类型：消息/反馈报告
Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
spf=fail smtp.mail=somespammer@example.com
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
spf=fail smtp.mail=somespammer@example.com
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html
Reported-Uri: mailto:user@example.com
Removal-Recipient: user@example.com
--part1_13d.2e68ed54_boundary Content-Type: message/rfc822 Content-Disposition: inline
--第1部分\u 13d.2e68ed54 \u边界内容类型：消息/rfc822内容处置：内联
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
From: <somespammer@example.net>
Received: from mailserver.example.net (mailserver.example.net
[192.0.2.1]) by example.com with ESMTP id M63d4137594e46;
Thu, 08 Mar 2005 14:00:00 -0400
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
To: <Undisclosed Recipients>
Subject: Earn money
MIME-Version: 1.0
Content-type: text/plain
Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
Date: Thu, 02 Sep 2004 12:31:03 -0500
Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam Spam --part1_13d.2e68ed54_boundary--
垃圾邮件-第1部分\u 13d.2e68ed54 \u边界--
Example 1: Generic abuse report with maximum returned information
示例1：返回信息最多的通用滥用报告
A contrived example in which the report generator has returned all possible information about an abuse incident.
一个人为的示例，其中报告生成器已返回有关滥用事件的所有可能信息。
Authors' Addresses
作者地址
Yakov Shafranovich ShafTek Enterprises 4014 Labyrinth Rd. Baltimore, MD 21215 US
美国马里兰州巴尔的摩迷宫路4014号Yakov Shafranovich ShafTek Enterprises邮编：21115
EMail: ietf@shaftek.org
URI: http://www.shaftek.org
EMail: ietf@shaftek.org
URI: http://www.shaftek.org
John R. Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 US
美国纽约州杜鲁曼斯堡市约翰·R·莱文·陶根诺克网络公司邮政信箱727号，邮编14886
Phone: +1 831 480 2300
EMail: standards@taugh.com
Phone: +1 831 480 2300
EMail: standards@taugh.com
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: msk@cloudmark.com
Phone: +1 415 946 3800
EMail: msk@cloudmark.com