非官方中文译本声明：本页为 IETF RFC 5965《An Extensible Format for Email Feedback Reports》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc5965。

RFC 5965《可扩展的邮件反馈报告格式（ARF）》中文译本

IETF · RFC 5965 · 标准跟踪（Standards Track）· 2010 年 8 月

摘要

本文档定义了一种可扩展的格式与 MIME 类型，邮件运营方可以使用它，向其他方通报关于所收到邮件的反馈。该格式旨在作为一种机器可读的替代方案，用以取代目前在 Internet 邮件中使用的各种既有报告格式。

1. 引言

随着垃圾邮件问题持续扩大、各种可能的解决方案不断演进，邮件运营方之间以及与其他各方之间交换滥用报告的情况日益增多。然而，不同的运营方各自定义了自己的格式，因而这些报告的接收方被迫为每一种格式编写定制软件来解析。此外，许多运营方还使用各式各样的其他报告格式，来提供与滥用无关的、关于已处理邮件的反馈。本备忘录使用 [REPORT] 中定义的 "multipart/report" 内容类型，并在此语境下通过为这类报告创建 "message/feedback-report" [MIME] 类型，定义一种标准的可扩展格式。

尽管此前在该领域已有一些工作（例如 [STRADS-BCP] 与 [ASRG-ABUSE]），但它们都尚未取得成功。希望本文档能有更好的命运。

本格式主要用作报告邮件滥用的滥用报告格式（Abuse Reporting Format，ARF），但同时也支持经由最终用户邮件客户端提供的直接反馈、某些类型的病毒活动报告，以及一些类似的问题。本备忘录还为将来可能需要的其他特定类型报告预留了扩展机制。

本文档仅定义用于这类报告的格式与 [MIME] 内容类型。至于这些报告应当发往何处、如何校验其内容，以及报告生成方与报告接收方之间的信任如何建立，均不在本文档范围之内。可以预期，最佳实践将随时间演进，并在未来的文档中被规范化。

1.1. 目的

本文档所定义的报告，意在向邮件运营方通报以下事项：

源自其网络的邮件滥用行为；
出站邮件在外界感知质量方面可能存在的问题，例如某电子邮件服务提供商所发出的邮件引起了自动化滥用检测系统的注意。

请注意，虽然 [REPORT] 中定义的父级 "multipart/report" 内容类型可用于各类管理性报文，但本格式专门用于服务提供方之间就邮件滥用及相关问题进行的通信，不应（SHOULD NOT）用于其他类型的报告。

1.2. 需求

反馈报告需要满足以下需求（实际的规范定义在本文档后续部分给出）：

它们必须同时可供人阅读和机器解析；
必须附上原始邮件报文的副本（包括主体与信头）或该报文的信头，以便接收方能够妥善处理该报告；
机器可读的部分必须为报告生成方提供与接收方共享元数据的能力；
该格式必须是可扩展的。

1.3. 定义

本节定义本文档中通篇使用的各种术语。

1.3.1. 通用

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [KEYWORDS] 中的描述进行解释。

1.3.2. 邮件相关

[EMAIL-ARCH] 引入了若干在本备忘录中使用的术语与概念，因此建议读者一并熟悉该文档。

2. 邮件反馈报告的格式

为满足上述需求，一份邮件反馈报告被定义为一个顶层 MIME 内容类型为 "multipart/report"（如 [REPORT] 所定义）的 [MIME] 报文。以下各项适用：

"multipart/report" 类型的 "report-type" 参数设为 "feedback-report"；
报文的第一个 MIME 部分包含对该报告的人类可读描述，并且必须（MUST）被包含在内。
报文的第二个 MIME 部分是一个机器可读区段，其内容类型为 "message/feedback-report"（在本备忘录后文定义），并且必须（MUST）被包含在内。该区段用于传达与所涉报告有关、且未必能从所附邮件报文本身直接获取的元数据。
报文的第三个 MIME 部分，要么是 "message/rfc822" 类型（如 [MIME-TYPES] 所定义）并完整包含原始报文，要么是 "text/rfc822-headers" 类型（如 [REPORT] 所定义）并包含原始报文完整信头块的副本。该部分必须（MUST）被包含在内（这与 [REPORT] 的规定相反）。虽然某些运营方可能出于隐私或法律原因选择修改或涂抹（redact）这一部分，但推荐（RECOMMENDED）不加任何修改地包含完整的原始邮件报文，因为此类修改会妨碍本报告接收方开展取证工作。进一步的讨论参见第 8 节。
除下文讨论的情形外，每一份反馈报告必须（MUST）只与单一一封邮件报文相关。汇总与聚合格式不在本规范范围之内。
反馈报告的 Subject 信头字段应当（SHOULD）与所附的、正被报告的那封邮件报文相同。若有差异，该差异必须（MUST）仅限于邮件用户代理（MUA）常用的转发前缀，如 "FW:"。（许多规模较小、使用 MUA 处理滥用事务的运营方依赖主题行来进行处理。）
所报告滥用行为的首要证据位于报告的第三部分，即包含原始报文的那一部分。第二部分包含可能对接收方有帮助的额外衍生数据；但就选取可据以采取行动的报告数据而言，报告接收方应当（SHOULD）首先使用第三部分的内容，其次才是第二部分的数据。第一部分意在容纳供人阅读的说明性文字，其本身并不构成报告的一部分；若它与其他部分相冲突，则不应（SHOULD NOT）被采用。

3. "message/feedback-report" 内容类型

本文档定义了一种名为 "message/feedback-report" 的新 [MIME] 内容类型。该内容类型提供一个机器可读区段，用于让报告生成方向报告接收方传达元数据。该区段的目的在于传递那些不够显而易见、或难以从原始邮件报文主体或信头中提取的信息。

该内容类型的主体由多个「字段」构成，这些字段按照 [MAIL] 信头字段的 ABNF 进行格式化。本节定义本规范所提供的初始字段集合。可以按照本备忘录后文所述的流程注册额外字段。尽管这些字段的语法与邮件报文信头字段相似，但它们在语义上是截然不同的；因此，它们不应（SHOULD NOT）在承载该报告的报文的信头字段中重复出现。请注意，这些字段所表示的是接收方就所涉报告作出的断言，但未必是可验证的。报告接收方不得（MUST NOT）假定这些断言总是准确的。

请注意，上述限制绝不妨碍使用那些以相同字段名注册在 IANA 信头字段注册表中的报文信头字段。

3.1. 必需字段

以下报告信头字段必须（MUST）恰好出现一次：

"Feedback-Type" 包含反馈报告的类型（如对应的 IANA 注册表以及本备忘录后文所定义）。该字段用于让报告解析器区分不同类型的报告。
"User-Agent" 指明生成该报告的软件程序的名称与版本。该字段的格式必须（MUST）遵循 [HTTP] 的 14.43 节。此字段仅用于记录说明；不存在用户代理名称或版本的注册表，报告接收方不应（SHOULD NOT）期望用户代理名称属于某个已知集合。
"Version" 指明报告生成方在生成该报告时所依据的规范版本。本规范中的版本号设为 "1"。

3.2. 只出现一次的可选字段

以下信头字段是可选的，并且不得（MUST NOT）出现一次以上：

"Original-Envelope-Id" 包含原始 [SMTP] 事务中所使用的信封 ID 字符串（参见 [DSN] 的 2.2.1 节）。
"Original-Mail-From" 包含原始 SMTP 事务 MAIL FROM 部分中所使用的邮件地址的副本。该字段的格式在 [SMTP] 的 4.1.2 节中定义为 "Reverse-path"。
"Arrival-Date" 指明原始报文被生成方 ADMD（管理管理域，Administrative Management Domain）的邮件传输代理（MTA）接收的日期与时间。该字段必须（MUST）按照 [MAIL] 的 3.3 节进行格式化。
"Reporting-MTA" 指明生成该反馈报告的 MTA 的名称。该字段在 [DSN] 的 2.2.2 节中定义，区别在于它在本报告中是一个可选字段。
"Source-IP" 包含接收到原始报文的来源 MTA 的 IPv4 或 IPv6 地址。地址必须（MUST）按照 [SMTP] 的 4.1.3 节进行格式化。
"Incidents" 包含一个无符号 32 位整数，指明该报告所代表的事件数量。该字段缺失即意味着该报告涵盖单一一起事件。

历史遗留字段 "Received-Date" 也应当（SHOULD）被接受，并按与 "Arrival-Date" 完全相同的方式解释。然而，若二者同时出现，则该报告即为格式错误，应当（SHOULD）按第 4 节所述方式处理。

3.3. 可多次出现的可选字段

以下这组信头字段是可选的，并且可以视需要出现任意多次：

"Authentication-Results" 指明报告生成方所执行的一项或多项认证检查的结果。该字段的格式在 [AUTH-RESULTS] 中定义。报告接收方应注意，该字段仅表示报告生成方所作出的一项断言。
"Original-Rcpt-To" 包含原始 [SMTP] 事务 RCPT TO 部分中所使用的邮件地址的副本。该字段的格式是该备忘录 4.1.2 节中定义的 "Reverse-path"。对于报告生成方所见的每一个 SMTP 收件人，该字段都应当（SHOULD）重复出现一次。
"Reported-Domain" 包含报告生成方认为与该报告相关的域名，例如其表面行为引发了该报告生成的那个域名。报告生成方如何确定这一信息并未作出规定，因此报告接收方无法确知它是如何被选定的。它常被用作向报告接收方建议应如何处理该报告的一种手段。在其推导过程不够明显的情况下，鼓励报告生成方在报告的文本区段中加以说明。域名格式在 [DNS] 的 2.3.1 节中定义。
"Reported-URI" 指明报告生成方认为与该报告相关的 URI，例如在引发该报告生成的报文中发现的某个可疑 URI。关于 "Reported-Domain" 取值来源的相同注意事项同样适用于该字段。URI 格式在 [URI] 中定义。

3.4. 关于 URI 的说明

实现者应当意识到，Reported-URI 字段可以携带许多不同类型的数据，具体取决于所使用的 URI 方案（scheme）。更多信息请查阅 IANA 维护的 "URI Schemes" 注册表。

此外，该字段所携带的数据是否隐含任何附加信息，不在本标准的范围之内。实现者可以就这些数据的解释方式自行协商各自的约定。

3.5. 形式化定义

使用 [ABNF] 表述的 "message/feedback-report" 媒体类型内容的形式化定义如下：

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

user-agent = "User-Agent:" [CFWS] product *( CFWS product )
             [CFWS] CRLF

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 ]

arrival-date = "Arrival-Date:" [CFWS] date-time CRLF

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

original-mail-from = "Original-Mail-From:" [CFWS]
                     reverse-path [CFWS] CRLF

reporting-mta = "Reporting-MTA:" [CFWS] mta-name-type [CFWS] ";"
                [CFWS] mta-name [CFWS] CRLF

source-ip = "Source-IP:" [CFWS]
            ( IPv4-address-literal /
              IPv6-address-literal ) [CFWS] CRLF

opt-fields-many = [ authres-header ]
                  [ original-rcpt-to ]
                  [ reported-domain ]
                  [ reported-uri ]

original-rcpt-to = "Original-Rcpt-To:" [CFWS]
                   forward-path [CFWS] CRLF

reported-domain = "Reported-Domain:" [CFWS]
                  domain [CFWS] CRLF

reported-uri = "Reported-URI:" [CFWS] URI [CFWS] CRLF

ext-field = field-name ":" unstructured

满足该 ABNF 的一组字段，可以以任意顺序出现在所传输的报文中。

各语法元素的来源如下：

"CRLF" 与 "DIGIT" 引自 [ABNF]。
"token" 引自 [MIME]。
"product" 引自 [HTTP]。
"field-name"、"unstructured"、"CFWS"、"date-time" 与 "domain" 引自 [MAIL]。
"envelope-id"、"mta-name-type" 与 "mta-name" 引自 [DSN]。
"reverse-path"、"forward-path"、"local-part"、"IPv4-address-literal" 与 "IPv6-address-literal" 引自 [SMTP]。
"URI" 引自 [URI]。
"authres-header" 引自 [AUTH-RESULTS]。

"ext-field" 指的是扩展字段，相关内容在第 6 节讨论。

4. 处理格式错误的报告

当一个接受并处理 ARF 报文的代理，收到一封（按 MIME 类型）自称是 ARF 报文、但在语法上偏离本规范的报文时，该代理应当（SHOULD）忽略或拒绝该报文。在执行拒绝的场合，拒绝通知（无论是通过 [SMTP] 应答还是生成 [DSN]）应当（SHOULD）指明拒绝的具体原因。

进一步的讨论参见 8.9 节。

5. 传输考虑

[DSN] 要求其报告以空的 [SMTP] 信封发件人发送，以避免退信环路。本规范曾考虑过类似的要求，但似乎不太可能出现为响应收到一份 ARF 报告而再生成一份 ARF 报告的情形；而且，这样的要求还会使 ARF 生成方永远无法判断某份 ARF 报告实际上并未被收到。

另一方面，如果一份 ARF 报告在生成时未使用空的信封发件人，而又被发往一个实际上并不可用的地址，那么生成方的地址也可能被大量 DSN 淹没，形成拒绝服务攻击（参见 8.6 节）。

因此，本规范对所生成报告的信封发件人不作任何要求。运营方需要结合各自部署环境的具体情况，自行考虑应使用何种信封发件人。

6. 可扩展性

与许多其他格式和协议一样，本格式可能需要随时间推移而扩展，以适应 Internet 不断变化的格局。为此，可扩展性通过两个 IANA 注册表来提供：一个用于反馈类型，另一个用于报告信头字段。反馈类型注册表配合上文的 "Feedback-Type" 字段使用。信头名称注册表则用于注册新的元数据字段，供本格式的机器可读部分（第 2 部分）使用。请注意，除非本格式发布了新的规范版本，否则版本号不会因新字段的注册而变更。另请注意，所有新字段的注册都只能注册为可选字段。任何新的必需字段都需要（REQUIRE）发布本规范的新版本。

为了促进本格式的可扩展性与互操作性，实现者必须（MUST）忽略其未明确支持的任何字段或报告类型。

额外的报告类型（扩展报告类型）或报告信头字段，将来可能由本规范的后续修订版定义，或通过上述方式注册来定义。此类类型与字段必须（MUST）按上述方式注册，并在诸如 RFC 之类的开放规范（Open Specification）中发布。

实验性的报告类型与报告信头字段必须（MUST）仅在已明确同意使用它们的各 ADMD 之间使用。这些名称及与之关联的参数并未在 RFC 中形成文档。因此，它们随时可能变更，不适合一般性使用。

7. IANA 考虑

IANA 已注册一个新的 [MIME] 类型，并创建了两个新的注册表，具体如下。

7.1. "message/feedback-report" 的 MIME 类型注册

本节给出依据 [MIME-REG] 提交给 IANA 处理的媒体类型注册申请：

To:  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.

Security considerations:  See Section 8 of [RFC5965].

Interoperability considerations:  Implementors MUST ignore any fields
   they do not support.

Published specification:  [RFC5965]

Applications that use this media type:  Abuse helpdesk software for
   ISPs, mail service bureaus, mail certifiers, and similar
   organizations

Additional information:  none

Person and email address to contact for further information:

      Yakov Shafranovich <ietf@shaftek.org>

      Murray S. Kucherawy <msk@cloudmark.com>

Intended usage:  COMMON

Author:

      Yakov Shafranovich

      John R. Levine

      Murray S. Kucherawy

Change controller:  IESG

上述注册申请各项的中文含义为：媒体类型名为 message、子类型名为 feedback-report；无必需参数、亦无可选参数；编码方面 "7bit" 编码即已足够，并必须（MUST）采用该编码，以便在非 MIME 邮件阅读器中查看时仍保持可读性；安全考虑参见 [RFC5965] 第 8 节；互操作性方面，实现者必须（MUST）忽略其不支持的任何字段；已发布规范为 [RFC5965]；使用该媒体类型的应用为面向 ISP、邮件服务代理机构、邮件认证机构及类似组织的滥用服务台软件；预期用途为 COMMON（通用）；变更控制方为 IESG。

7.2. 反馈报告信头字段

IANA 已创建 "Feedback Report Header Fields"（反馈报告信头字段）注册表。该注册表收录由本备忘录所定义、用于反馈报告中的信头字段。

新的注册或更新必须（MUST）按照 [IANA] 中所述的 "Specification Required"（需要规范）准则来发布。除非本备忘录发布了新版本，否则任何据此注册的新字段均被本规范视为可选字段。

新的注册与更新必须（MUST）包含以下信息：

所注册或更新字段的名称；
该字段的简短描述；
该字段是否可以出现一次以上；
该字段适用于哪一种（或哪几种）反馈类型（或填写 "any"，即任意）；
发布该字段规范的文档；
新的或更新后的状态，其取值必须（MUST）是下列之一：
- current（当前）：该字段正在使用中；
- deprecated（已弃用）：该字段仍在使用中，但不鼓励使用；
- historic（历史遗留）：该字段已不再使用。

一次更新可以在既有注册项上加注说明，以在适当情况下标明某个已注册字段属于 historic 或 deprecated。

该注册表的初始内容包含以下取值：

字段名（Field Name）	描述	可多次出现	关联 Feedback-Type	发布于	状态
Arrival-Date	原始报文被接收的日期/时间	否	any	[RFC5965]	current
Authentication-Results	认证检查的结果	是	any	[RFC5965]	current
Feedback-Type	已注册的反馈报告类型	否	N/A	[RFC5965]	current
Incidents	表示该报告所代表的同类事件数量	否	any	[RFC5965]	current
Original-Mail-From	原始 SMTP 事务 MAIL FROM 部分所用的邮件地址	否	any	[RFC5965]	current
Original-Rcpt-To	原始 SMTP 事务 RCPT TO 部分所用的邮件地址	是	any	[RFC5965]	current
Received-Date	原始报文被接收的日期/时间（已由 "Arrival-Date" 取代）	否	any	[RFC5965]	historic
Reported-Domain	报告生成方认为对所报告报文而言具有关键意义的域名	是	any	[RFC5965]	current
Reported-URI	报告生成方认为对所报告报文而言具有关键意义的 URI	是	any	[RFC5965]	current
Reporting-MTA	生成该报告的 MTA	否	any	[RFC5965]	current
Source-IP	接收到原始报文的来源 IPv4 或 IPv6 地址	否	any	[RFC5965]	current
User-Agent	生成该报告的程序的名称与版本	否	any	[RFC5965]	current
Version	所使用规范的版本	否	any	[RFC5965]	current

7.3. 反馈报告类型取值

IANA 已创建 "Feedback Report Type Values"（反馈报告类型取值）注册表。该注册表收录由本备忘录所定义、用于反馈报告中的反馈类型。

新的注册必须（MUST）包含以下信息：

所注册反馈类型的名称；
该反馈类型的简短描述；
发布该字段规范的文档；
新的或更新后的状态，其取值必须（MUST）是下列之一：
- current（当前）：该字段正在使用中；
- deprecated（已弃用）：该字段仍在使用中，但不鼓励使用；
- historic（历史遗留）：该字段已不再使用。

该注册表的初始内容包含以下取值：

反馈类型名（Feedback Type Name）	描述	发布于	状态
abuse	未经请求的邮件或其他某种形式的邮件滥用	[RFC5965]	current
fraud	表示某种欺诈或钓鱼活动	[RFC5965]	current
other	不属于其他已注册类型的任何其他反馈	[RFC5965]	current
virus	在原始报文中发现病毒的报告	[RFC5965]	current

8. 安全考虑

在生成或处理反馈报告时，以下安全考虑适用：

8.1. 继承自 RFC 3462

[REPORT] 中的全部安全考虑在此一并继承。

8.2. 解读

本规范描述的是一种报告格式。报告内容的认证与有效性应当（SHOULD）通过其他途径来确立。未经核实的报告，其内容可能是错误的、不完整的，或是蓄意伪造的——这包括第三部分中所指称的滥用事件、第二部分中的衍生数据，以及人类可读的第一部分。

为了对常见的反馈报告作出及时响应，人们会有以自动化方式执行某些动作的需求。然而必须谨慎行事，因为围绕这些报告的内容并不存在实质性的安全保障。攻击者可以精心构造一份报告，意图促使报告接收方采取不良的动作。

建议在针对收到的报告采取任何形式的自动化动作之前，先对 ARF 报告的来源加以核实，例如使用 [SMIME]、[DKIM]、[SPF] 或 [SENDERID] 等常见的报文认证机制。其中，S/MIME 提供了最强的认证能力，而且在建立使用本规范的双边报告关系的过程中，密钥交换的成本已被计入其中；然而它不如其他机制那样透明，因而会干扰那些专门用于处理 multipart/report 报文的代码的解析能力。

为达成上述目标所需的具体校验细节属于本地策略事项，因此不在本规范范围之内。

8.3. 针对认证方法的攻击

如果某种认证方法出现了已知的攻击手段，那么显然，验证该方法的代理就可能被欺骗，将不真实的报文误判为真实；因而该信头字段的取值也就可能具有误导性。由此可见，任何针对某种认证方法（该方法可能被用于保护滥用报告真实性）的攻击，同样构成此处的一项安全考虑。

8.4. 蓄意构造的格式错误报告

攻击者有可能生成一个异常巨大或以其他方式格式错误的 ARF 报文字段，试图借此发现或利用接收方解析代码中的弱点。实现者应当（SHOULD）对所有此类报文进行彻底校验，并对蓄意构造以及无意形成的格式错误报文都保持健壮性。

8.5. 从 ARF 报告中省略数据

发送这类报告可能会泄露关于报告发送者的私密信息。例如，针对一封邮件列表投递而发出的此类报告，会向报告接收方暴露列表上一个本可保持隐藏的有效邮件地址。

出于这一原因，报告生成方可能希望对报告的部分内容进行涂抹，以隐藏私密信息。在隐私优先于运营必要性的场合，这样做可能是必要的；但正如第 2 节所提及的，它可能会妨碍报告接收方作出及时或有意义的响应。

8.6. 自动生成的 ARF 报告

已有系统被实现为能够响应某一事件而自动生成 ARF 报告。例如，监控某个蜜罐邮件地址的软件，可能会在任何报文投递至该地址时立即生成一份 ARF 报告。若攻击者获知了这样的配置，便可加以利用，用自动生成的 ARF 报告去攻击某个 ARF 接收方。

8.7. 附件中的恶意软件

由于本格式有时被用于自动报告恶意软件，ARF 处理方（无论是人还是程序）应当（SHOULD）确保以适合处理未经验证且可能怀有敌意的数据的方式来处理附件。

8.8. User-Agent 字段

承 8.2 节所述，User-Agent 字段是生成方软件所作出的一项断言，它既未在本备忘录中作出规定，也并非从报告第三部分所呈现的报文中推导得出。该字段意在用于记录说明与调试；并且由于恶意代理可以轻易伪造它，接收方不应（SHOULD NOT）对其进行解读。

8.9. 格式错误的报文

承第 4 节的讨论，某些情况下 ARF 处理代理可能会选择接受与本规范不一致的报文，例如在某些字段正转向 "historic" 或 "deprecated" 状态的过渡期，或者在引入新的非标准扩展字段或实验性字段时。此类选择需要以极其谨慎的方式实现；当两个不同字段具有相关含义时（例如属于 historic 的 "Received-Date" 与属于 current 的 "Arrival-Date"），攻击者可能构造一份作出令人混淆的声称的报告，试图利用这种宽松的解析逻辑。

9. 参考文献

9.1. 规范性参考文献

[ABNF]　Crocker, D. 与 P. Overell，《Augmented BNF for Syntax Specifications: ABNF》（语法规范的增强型 BNF），STD 68，RFC 5234，2008 年 1 月。
[AUTH-RESULTS]　Kucherawy, M.，《Message Header Field for Indicating Message Authentication Status》（用于指示报文认证状态的报文信头字段），RFC 5451，2009 年 4 月。
[DNS]　Mockapetris, P.，《Domain names - implementation and specification》（域名——实现与规范），STD 13，RFC 1035，1987 年 11 月。
[DSN]　Moore, K. 与 G. Vaudreuil，《An Extensible Message Format for Delivery Status Notifications》（投递状态通知的可扩展报文格式），RFC 3464，2003 年 1 月。
[HTTP]　Fielding, R.、Gettys, J.、Mogul, J.、Frystyk, H.、Masinter, L.、Leach, P. 与 T. Berners-Lee，《Hypertext Transfer Protocol -- HTTP/1.1》（超文本传输协议 HTTP/1.1），RFC 2616，1999 年 6 月。
[KEYWORDS]　Bradner, S.，《Key words for use in RFCs to Indicate Requirement Levels》（RFC 中用以指示需求级别的关键词），BCP 14，RFC 2119，1997 年 3 月。
[MAIL]　Resnick, P.（编），《Internet Message Format》（Internet 报文格式），RFC 5322，2008 年 10 月。
[MIME]　Freed, N. 与 N. Borenstein，《Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies》（MIME 第一部分：Internet 报文主体的格式），RFC 2045，1996 年 11 月。
[MIME-REG]　Freed, N. 与 J. Klensin，《Media Type Specifications and Registration Procedures》（媒体类型规范与注册流程），BCP 13，RFC 4288，2005 年 12 月。
[MIME-TYPES]　Freed, N. 与 N. Borenstein，《Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types》（MIME 第二部分：媒体类型），RFC 2046，1996 年 11 月。
[REPORT]　Vaudreuil, G.，《The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages》（用于报告邮件系统管理性消息的 Multipart/Report 内容类型），RFC 3462，2003 年 1 月。
[SMTP]　Klensin, J.，《Simple Mail Transfer Protocol》（简单邮件传输协议），RFC 5321，2008 年 10 月。
[URI]　Berners-Lee, T.、Fielding, R. 与 L. Masinter，《Uniform Resource Identifier (URI): Generic Syntax》（统一资源标识符（URI）：通用语法），STD 66，RFC 3986，2005 年 1 月。

9.2. 资料性参考文献

[ASRG-ABUSE]　Internet 研究任务组（IRTF）反垃圾邮件研究组（ASRG），《Abuse Reporting Standards Subgroup of the ASRG》（ASRG 滥用报告标准子组），2005 年 5 月。
[DKIM]　Allman, E.、Callas, J.、Delany, M.、Libbey, M.、Fenton, J. 与 M. Thomas，《DomainKeys Identified Mail (DKIM) Signatures》（域名密钥识别邮件（DKIM）签名），RFC 4871，2007 年 5 月。
[EMAIL-ARCH]　Crocker, D.，《Internet Mail Architecture》（Internet 邮件体系结构），RFC 5598，2009 年 7 月。
[IANA]　Narten, T. 与 H. Alvestrand，《Guidelines for Writing an IANA Considerations Section in RFCs》（在 RFC 中撰写 IANA 考虑章节的指南），BCP 26，RFC 5226，2008 年 5 月。
[SENDERID]　Lyon, J. 与 M. Wong，《Sender ID: Authenticating E-Mail》（Sender ID：邮件认证），RFC 4406，2006 年 4 月。
[SMIME]　Ramsdell, B. 与 S. Turner，《Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification》（S/MIME 3.2 版报文规范），RFC 5751，2010 年 1 月。
[SPF]　Wong, M. 与 W. Schlitt，《Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1》（用于授权在邮件中使用域名的发件人策略框架（SPF）第 1 版），RFC 4408，2006 年 4 月。
[STRADS-BCP]　Crissman, G.，《Proposed Spam Reporting BCP Document》（垃圾邮件报告 BCP 文档提案），2005 年 5 月。

附录 A. 致谢（Acknowledgements）

作者们谨此感谢邮件社区中为本文档提供了有益意见与建议的众多成员，包括参与 ASRG、IETF 与 MAAWG 相关活动的许多参与者，以及 abuse-feedback-report 公开邮件列表的全体成员。

附录 B. 反馈报告示例

本节给出若干使用该报文格式来报告某封到达报文相关反馈的示例。

B.1. 不含可选信头的简单邮件滥用报告

简单报告：

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

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/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

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>
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：仅含必需字段。

这是按照本规范生成的一份反馈报告的示例，其中仅使用了必需字段。

B.2. 含全部信头的完整邮件滥用报告

一份完整的邮件滥用报告：

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

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/.

--part1_13d.2e68ed54_boundary
Content-Type: message/feedback-report

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

--part1_13d.2e68ed54_boundary
Content-Type: message/rfc822
Content-Disposition: inline

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

Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
Spam Spam Spam
--part1_13d.2e68ed54_boundary--

示例 1：返回信息最完整的通用滥用报告。

这是一个人为构造的示例，其中报告生成方返回了关于某起滥用事件的所有可能信息。

作者地址（Authors' Addresses）

Yakov Shafranovich
ShafTek Enterprises
4014 Labyrinth Rd.
Baltimore, MD 21215
US

EMail: ietf@shaftek.org
URI: http://www.shaftek.org

John R. Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
US

Phone: +1 831 480 2300
EMail: standards@taugh.com

Murray S. Kucherawy
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
US

Phone: +1 415 946 3800
EMail: msk@cloudmark.com