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

RFC 6650《邮件反馈报告（ARF）的应用》中文译本

IETF · RFC 6650 · 标准跟踪（Standards Track）· 2012 年 6 月

摘要

RFC 5965 定义了一种可扩展的、机器可读的格式，供邮件运营者向其他相关方报告关于所收到邮件的反馈。本适用性声明（applicability statement）描述了利用该格式报告滥用事件与认证失败事件的常见方法。任何规模的邮箱提供商（Mailbox Provider）、邮件发送实体以及最终用户，都可以把这些方法作为基础，制定最适合自身的处理流程。文中还讨论了一些相关的可选机制。

本备忘录还提示：本文档更新了 RFC 5965。

1. 引言

滥用报告格式（Abuse Reporting Format，ARF）最初是为两类非常具体的用例而开发的。首先，它被设想用于在大型邮件运营者之间、或由大型邮件运营者向最终用户的网络接入运营者传递反馈报告，这些参与方都可以被假定拥有自动化的滥用处置系统。其次，同样是这些大型邮件运营者，会使用它把同类报告发送给其他实体，其中包括那些出于商业目的进行批量邮件发送的实体。在上述两种情形中，报告都是由最终用户的直接操作所触发的，例如用户在其邮件客户端中点击「举报垃圾邮件」（report spam）按钮。

尽管人们也讨论过 [RFC5965] 所定义的 ARF 的其他用途（未来可能会以类似方式形成文档），但滥用报告仍然是其主要应用；此外，还有少量对相关扩展的采用，这些扩展使认证失败报告成为可能。

本适用性声明为在上述两类语境中使用 ARF 提供了指引。它还包含一些关于将 ARF 与其他电子邮件技术结合使用的说明。

报告滥用消息的目的在于制止其再次发生。本文档所描述的方法着眼于尽可能实际地把滥用报告自动化，从而将某个站点滥用处理团队的工作量降至最低。生成滥用反馈之所以有价值，还有更多其他原因，例如为邮件过滤器或声誉追踪系统提供训练输入，或者对某些特别恶劣的滥用行为启动调查。这些其他方面的应用不在本备忘录的讨论范围之内。

关于本主题的进一步介绍可参见 [RFC6449]，其中包含更多有关滥用报告这一总体议题的信息。本文档中许多具体的 ARF 指引，都取自 [RFC6449] 所提出的原则。

在本文档发布之时，共有五种反馈类型（feedback type）已完成注册。本文档只讨论其中的两种，即 "abuse"（滥用，[RFC5965]）与 "auth-failure"（认证失败，[RFC6591]），因为它们在实践中已获得足够程度的使用，从而可以对其作出适用性声明。其余几种，即 "fraud"（欺诈，[RFC5965]）、"other"（其他，[RFC5965]）以及 "not-spam"（非垃圾邮件，[RFC6430]），或者过于新近，或者使用得过少，因此未纳入本文讨论。

2. 定义

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [RFC2119] 中的描述进行解释，并且意在取代 [RFC2026] 第 3.3 节所描述的需求级别（Requirement Levels）。

本文档所使用的部分术语取自 [RFC5598]。

「邮箱提供商」（Mailbox Provider）指为最终用户接收、存储 [RFC5322] 消息（即「电子邮件消息」）并提供访问途径的组织。此类组织通常已实现了 SMTP [RFC5321]，并且可能通过 IMAP [RFC3501]、邮局协议（POP）[RFC1939]、为 HTTP [RFC2616] 设计的专有接口或某种专有协议来提供对消息的访问。

3. 主动约定的报告与非约定的报告

[RFC5965] 最初的、且迄今为止仍最为常见的应用场景，是两个邮件系统之间达成私下协议以交换滥用报告——这些报告通常源自收件人手工将消息举报为垃圾邮件。我们把这类报告称为「主动约定的报告」（solicited reports，即经请求的报告）。

ARF 的其他用途则涉及在彼此并不相识的双方之间发送此类报告。这些「非约定的报告」（unsolicited reports，即未经请求的报告）是在双方对报告的语境与含义并无事先安排的情况下发送的。因此，为使这类非约定报告有可能对接收方真正有用，对其结构所施加的各种约束条件——例如可以有效地发送到哪些地址、可以用来报告哪些问题、以及报告接收方可以如何处理它们——都与前一种情形大不相同。

后续各节将分别讨论这两种情形。

4. 生成与处理主动约定的滥用报告

4.1. 面向反馈提供方的一般性考虑

邮箱提供商会从其用户处收到关于滥用邮件或不受欢迎邮件的举报，最常见的方式是在 MUA（邮件用户代理，Mail User Agent）中提供一个「举报垃圾邮件」按钮（或类似名称的功能）。将这条消息及其任何关联元数据从 MUA 传送到邮箱提供商 ARF 处理系统的方法，并未由任何标准文档定义，但 [RFC6449] 第 3.2 节对此有进一步讨论。与收集此类数据相关的策略问题，则在 [RFC6449] 第 3.4 节中讨论。

为落实本备忘录的各项建议，报告需按 [RFC5965] 进行格式化，并作为电子邮件消息 [RFC5322]（通常使用 SMTP [RFC5321]）进行传输。

关于 ARF 处理系统的持续维护，[RFC6449] 第 3.6 节有相应讨论。

4.2. 将报告发往何处

邮箱提供商不应（SHOULD NOT）把报告发送到并未明确请求接收报告的地址。一种有效的偏离情形，可能来自本地策略（local policy）的指示。相关方请求获取这些报告的流程，在 [RFC6449] 第 3.5 节中有所讨论。

4.3. 报告中应包含什么

报告应当（SHOULD）使用 "Feedback-Type: abuse" 作为报告类型。虽然生成报告的邮箱提供商可以根据所报告滥用行为的性质选用其他类型，但接收报告的运营者未必会对不同的反馈类型作差异化处理。

以下字段在 [RFC5965] 中是可选的，但在本语境下，当其对应取值可获得时应当（SHOULD）予以使用：Original-Mail-From、Arrival-Date、Source-IP 以及 Original-Rcpt-To。实现者可以视情况认为合适而包含其他可选字段。

可识别用户身份的数据可以（MAY）按 [RFC6590] 所述方式加以遮蔽（obscure）。

4.4. 面向反馈消费方的一般性考虑

ARF 报告流（report stream）是由反馈提供方（Feedback Provider）与反馈消费方（Feedback Consumer）事先主动建立起来的。关于为请求反馈作准备的建议，见 [RFC6449] 第 4.1 节。

运营者必须（MUST）能够通过 SMTP [RFC5321] 以电子邮件消息 [RFC5322] 的形式接收 ARF [RFC5965] 报告。这些消息以及其他可能收到的邮件消息类型，在 [RFC6449] 第 4.2 节中有所讨论。

作为正式反馈安排一部分的反馈报告接收方，必须有能力处理大量报告。这可能需要按 [RFC6449] 第 4.4 节所讨论的方式实现报告处理的自动化。

4.5. 应当预期什么

合法的 Feedback-Type 取值清单由 [RFC5965] 定义，该文档为有效取值创建了一个 IANA 注册表，以便进行扩展。然而，为了能够处理尚未被支持的新类型，自动化的报告处理系统不得（MUST NOT）仅仅因为 Feedback-Type 未知就（在 SMTP 意义上）拒绝一份报告。自动化系统完全可以把未知类型的报告先搁置一旁，转由人工处理。不过，邮箱提供商也可能只会使用 "abuse" 这一种 Feedback-Type。因此，若报告接收方事先并不了解报告发送方的具体情况，就可能需要在收到报告后另行分析，以区分不同类型的滥用报告。

报告接收方必须（MUST）接受那些按 [RFC6590] 所述方式对可识别用户身份的数据作了遮蔽处理的报告。该文档同时也讨论了此类报告的处理方式。[RFC6449] 第 4.4 节亦对这一技术有所讨论。

4.6. 拿到报告后做什么

[RFC6449] 第 4.3 节讨论了邮件运营者在收到一份（或多份）报告后可能采取的各种行动。

5. 生成与处理非约定的滥用报告

5.1. 一般性考虑

对报告接收方而言，能够对发来的报告进行限流（throttling）以避免自身设施受损，是至关重要的。因此，反馈提供方必须（MUST）为报告接收方提供一种途径，使其能够要求不再向自己发送任何后续报告。遗憾的是，迄今为止尚不存在用于提出此类请求的标准化机制，所有满足这一要求的现有机制都是带外（out-of-band）的。

对消息进行认证通常都是个好主意，而对于非约定的报告而言，这一点尤为重要，因为它有助于提升报告的可信度，进而提高对方作出响应的可能性。因此，与任何其他消息一样，发送非约定报告的反馈提供方应当（SHOULD）发送那些其预期能够通过发件人策略框架（SPF）[RFC4408] 和／或域名密钥识别邮件（DKIM）[RFC6376] 检查的报告。

5.2. 何时生成报告

处理非约定报告会给报告接收方带来显著成本。非约定报告的发送方，尤其是那些自动大批量发送此类报告的一方，不应（SHOULD NOT）发送那些无法成为接收方采取行动之依据的报告——无论其原因在于所报告的事件本身与滥用无关、报告被发往了不会引发任何处理的电子邮件地址，还是报告的内容或格式令接收方难以阅读或使用。

反馈提供方不应（SHOULD NOT）仅仅因为某个发送方的部分邮件被判定为滥用，就把该发送方发出的全部邮件都报告出去。

对于那些仅凭内联内容分析工具的结果判定「看起来像」垃圾邮件的邮件，不应（SHOULD NOT）发送机械化生成的报告；因为这类判定具有主观性，它们不太可能为接收方采取行动提供依据。相比之下，由最终用户针对其自行判定为滥用的邮件所提出的投诉，或者投递到「垃圾邮件陷阱」（spam trap）或「蜜罐」（honeypot）地址的邮件，其准确性要高得多，可以（MAY）据此发送报告。

如果反馈提供方对到达的消息应用了 SPF [RFC4408]，那么当 SPF 评估产生 "Fail"、"SoftFail"、"TempError" 或 "PermError" 结果时，不应（SHOULD NOT）向 RFC5321.MailFrom 域名生成报告，因为此时无法就该域名的使用是否获得授权作出任何可靠的断言或假设。一种有效的例外情形是：已明确知悉在该情形下 SPF 结果对该域名并非决定性的（例如，该消息同时由同一域名以 DKIM [RFC6376] 签名，且该签名验证通过）。

5.3. 将报告发往何处

MUA 应当（SHOULD）创建滥用举报并将其回送给自己的邮箱提供商，由后者代表最终用户生成并发送 ARF 消息（参见 [RFC6449] 第 3.2 节），而不是由 MUA 自行生成反馈报告。这样做可以实现报告的集中处理与追踪，并为过滤系统提供训练输入。不过，目前尚不存在用于在 MUA 与邮箱提供商之间进行这种信令交互以触发滥用报告的标准机制。

反馈提供方不应（SHOULD NOT）把报告发送给与事件无关或仅有边缘关联的接收方。例如，它们不应（SHOULD NOT）把报告发送给从表面上的始发系统到生成该报告的运营者之间路径上每一个自治系统（Autonomous System）的运营者。相反，它们需要把报告发送给那些既对相关消息负有责任、又有能力对其采取措施的接收方。

决定把非约定报告发往何处，通常要依赖各种启发式方法（heuristics）。中转（relay）该主题消息的 IP 地址的 WHOIS [RFC3912] 记录中的滥用处理地址，和／或对该地址执行 PTR（「反向查询」）查询所得结果中的域名对应的滥用处理地址，都可能是合理的候选目标；相关域名的 abuse@domain 角色地址（参见 [RFC2142]）亦然。非约定报告不应（SHOULD NOT）被发送到那些显然并非用于处理滥用报告的电子邮件地址。合乎情理的候选地址包括：在 WHOIS 记录中或某个网站上找到的、被明确说明为滥用联系人（abuse contact）的地址，或者形如 "abuse@domain" 的地址。

当一条滥用消息经由 DKIM [RFC6376] 或 SPF [RFC4408] 之类的域级认证技术完成认证时，被该认证机制所验证的域名通常是接收该消息相关反馈的合理候选对象。不过就 DKIM 而言，虽然被认证的域名对所发出的邮件负有一定责任，但它可能并不是处理滥用问题的理想联络点（例如，它可能代表消息的作者而非其发送者，它可能标识出对该消息负责的恶意行为者，也可能指向一个根本无法接收邮件的域名）。

很多时候，把非约定报告发送到属于滥用方自身的滥用举报地址，是毫无意义的。事实上，此类报告甚至可能泄露关于投诉人的信息。若能事先识别出这类地址，则不应（SHOULD NOT）向其发送报告；除非已知该滥用方确实会对此类报告作出响应。

5.4. 报告中应包含什么

报告应当（SHOULD）使用 "Feedback-Type: abuse"，但也可以视情况使用其他类型。然而，生成报告的邮箱提供商不能假定接收报告的运营者会对不同的 Feedback-Type 作差异化处理。

只要以下可选字段的对应取值可获得且与该报告相关，报告就应当（SHOULD）包含它们：Original-Mail-From、Arrival-Date、Source-IP 以及 Original-Rcpt-To。实现者可以视情况认为合适而包含其他可选字段。

经验表明，在绝大多数语境下使用 ARF 都是可取的。自动化的接收方系统处理以 ARF 形式发送的滥用报告，至少不会逊于处理任何其他格式（例如附带或不附带原消息副本的纯文本）。即便对于那些并未请求 ARF 报告的系统而言也是如此——前提是这些报告在生成时已考虑到接收方可能并不使用自动化 ARF 解析这一可能性。任何以 ARF 形式发送非约定报告的一方，都可以合理地推定：某些接收方将只能访问报告中人类可读的部分（即第一个 text/plain 部分），因此应当（SHOULD）把所有必要信息也一并包含在这一部分中。此外，它们还应当（SHOULD）确保该报告在以纯文本方式查看时是可读的，从而尽可能为低端工单系统提供便利。在极端情况下，未能采取这些措施可能导致报告被丢弃或被忽略。

5.5. 拿到报告后做什么

非约定报告的接收方可以利用 ARF 中标准化的部分来实现处理自动化。无论报告的发送方是谁，它们都可以通过如下方式改进处理流程：例如，在被举报消息的副本中查找那些由接收方组织所负责的 IP 地址段、域名与邮箱的相关引用，以此将有效报告与无效报告区分开来；以及，通过关联多份针对相似消息的报告来识别批量邮件发送者。

依据 [RFC6449] 第 4.4 节，网络服务提供商可以（MAY）利用 ARF 数据，把反馈消息自动转发给始发的客户。

已公布的滥用处理邮箱地址不应（SHOULD NOT）仅仅基于格式就拒绝非 ARF 格式的消息，因为生成 ARF 消息的能力有时可能不可用或不适用。偏离这一要求的做法，可以基于关于其他消息判定标准的本地策略决定来实施。

尽管 [RFC6449] 提示对反馈进行回复通常并无用处，但在收到 ARF 报告而双方尚未建立任何反馈安排的情形下，一份非自动化的回复可能是可取的：它可以说明该投诉最终导致了何种处置，从而避免反馈提供方采取更为严厉的过滤措施。此外，使用一个无法接收回复的地址，会使任何索取补充信息的请求都无从提出，并增大后续报告被丢弃或被拦截的可能性。因此，发送非约定报告的反馈提供方不应（SHOULD NOT）生成那些无法接收回复的报告。当一份非约定报告促成了与某个负责任且有响应意愿的相关方建立联系时，这一数据可以保存下来，用于日后的投诉处置，并有可能据此建立正式的（主动约定的）反馈安排。关于建立反馈安排的讨论，参见 [RFC6449] 第 3.5 节。

6. 生成自动化的认证失败报告

在某些情形下，报告的生成是由自动化机制而非用户请求所引发的。一个具体的例子是：使用 ARF（或其扩展）报告那些未能通过特定消息认证检查的消息。[RFC6651] 与 [RFC6652] 即属此类。以下各项考虑适用于这些情形。

针对这一用例的适用性声明篇幅相对较小，因为与滥用报告相关的许多问题并不适用于关于认证失败的报告。

自动反馈生成器必须（MUST）依据由自愿接收报告的一方所提供的数据来选择实际的消息收件人。特别地，不得（MUST NOT）使用启发式方法来选择收件人。

如果验证方（Verifier）正在评估的消息本身就是一条 ARF [RFC5965] 消息，则不得（MUST NOT）自动生成报告。

经由 SMTP 发送的新报告，其消息必须（MUST）以避免放大攻击（amplification attack，无论是蓄意的还是无意的）的方式构造。报告的信封发件人地址（envelope sender address）必须（MUST）经过选择，以使这些报告不会引发邮件环路（mail loop）。与 [RFC3464] 第 2 节类似，报告的信封发件人地址必须（MUST）经过选择，以确保不会有任何反馈报告因该报告自身而被再次签发。因此，当使用 SMTP 事务发送报告时，MAIL FROM 命令应当（SHOULD）使用 NULL 反向路径（reverse-path），即 "MAIL FROM:<>"。一种例外情形是：所选用的反向路径能使针对该报告的 SPF 检查通过；在这种情况下，运营者需要通过其他手段作出安排，以避免放大攻击或邮件环路。

报告应当（SHOULD）使用 "Feedback-Type: auth-failure"，但也可以（MAY）视情况使用其他类型。然而，生成报告的邮箱提供商不能假定接收报告的运营者会对不同的 Feedback-Type 作差异化处理。

虽然以下字段在 [RFC5965] 中是可选的，但只要其对应取值可获得，这些报告就应当（SHOULD）包含它们：Original-Mail-From、Arrival-Date、Source-IP 以及 Original-Rcpt-To。实现者可以视情况认为合适而包含其他可选字段。

7. 安全考虑

7.1. 其他文档中的安全考虑

强烈建议实现者至少通读 [RFC5965] 与 [RFC6449] 的「安全考虑」章节。

7.2. 伪造

某些反馈提供方是直接转发用户投诉，而不是通过对已存储消息（例如经由 IMAP 或 POP 存取的消息）的引用来处理投诉；这类反馈提供方可能被诱骗去投诉一条投诉用户实际上从未收到过的消息，从而演变为针对该伪造消息表面始发者的一种攻击。反馈提供方需要对此类攻击手法具备抵御能力。

此外，这些报告与普通的 Internet 电子邮件一样容易被伪造。凡是希望自动利用各类报告的用户代理与自动邮件处理设施（例如邮件分发列表的分发器），都应采取适当的预防措施，以尽量减少拒绝服务攻击所可能造成的损害。

缓解这一威胁最简单的手段，或许是主张这些报告本身也应当使用 DKIM 之类的技术进行签名，和／或经由 SPF 之类的技术进行授权。但需要注意：如果收发两端任一侧的邮件基础设施存在问题，DKIM 和／或 SPF 反而可能导致报告不被其预期接收方信任、甚至不被接受，因此务必确保这些组件配置正确。将两种技术配合使用可以在一定程度上化解这一顾虑，因为它们的失效模式通常是互不重叠的。

7.3. 放大攻击

若未能遵循关于信封发件人选择的各项建议，可能导致放大式的拒绝服务攻击。第 6 节以及 [RFC3464] 中对此均有讨论。

7.4. 自动生成

从历史上看，ARF [RFC5965] 报告一直是因某种人工请求（例如有人在邮件阅读器中点击「举报滥用」按钮）而逐条生成的。与此形成对比的是，某些扩展文档（即 [RFC6651] 与 [RFC6652]）所描述的机制则以自动化报告为核心。显然，这意味着消息量可能大得多、频率可能高得多，从而带来更大的邮件系统负载（对反馈提供方与报告接收方而言皆是如此）。

这些机制主要用于在开发与调试期间生成报告，以帮助 DKIM [RFC6376]、作者域签名规范（ADSP）[RFC5617]、SPF [RFC4408] 及其他相关协议的实现者。它们通常并不适用于长期的取证用途，原因正是上述负载方面的顾虑。不过，希望对欺诈或基础设施问题保持密切监控的管理管理域（ADministrative Management Domain，ADMD）仍有可能长期使用它们。此时务必考虑这样做会对反馈提供方与提出请求的 ADMD 双方造成的影响。

请求获取这些报告的发送方，如果发出了签名因某种原因无法验证通过的已签名消息，就可能引发反馈提供方产生大量报告，从而使其自身的邮件服务器不堪重负。同样地，反馈提供方也可能被大量签名验证失败且要求生成报告的消息压垮，因为此时反馈提供方需要把报告回送给签名方（Signer）。

限制这类消息的生成速率也许是恰当的，但这样做有可能妨碍重要且可能具有时效性的信息的传递。

就一般的 ARF 反馈环路（feedback loop）而言，人们常建议反馈提供方仅在双方已达成带外安排之后，才创建这些（或任何）ARF 报告。这些扩展机制提供了对一条经授权的滥用报告反馈环路（该环路由私下协议配置并启用）的参数进行调整的途径。若不如此，而是仅凭消息中所发现的数据自动发送报告，则可能带来意料之外的后果。

7.5. 报告多起事件

如果已知某台主机会在特定事件发生时生成滥用报告，攻击者就可以伪造大量会触发此类报告的消息。这样一来，报告的接收方就可能被报告淹没。只要再找到若干台会生成报告的服务器，这种手法便可轻易扩展为分布式拒绝服务攻击。

ARF [RFC5965] 中所引用的事件计数（incident count）提供了一种有限的缓解方式。生成报告的主机可以选择只周期性地发送报告，每份报告代表若干起相同或近乎相同的事件。人们甚至可以采用某种反指数式的做法：对最初的十起事件逐一发送报告，此后每十起事件发送一次直至第 100 起，再此后每 100 起事件发送一次直至第 1000 起，依此类推，直到经历一段相对平静的时期之后，该限制重新归零。

不过，尤其是对「近乎相同」的事件采用这一技术时，会导致报告质量下降。举例来说，如果有大量垃圾邮件来自同一名攻击者，报告代理可能决定只就其中一部分消息发送报告。这虽然避免了让系统管理员被报告洪水淹没，但每起事件的具体细节同样也不会被送达。

还可以考虑其他限速措施，例如：检测到报告目的地返回临时失败响应后，在一段时间内停止向该目的地生成报告；或者干脆对在给定时间范围内发往某一特定接收方的报告数量施加硬性上限，或就该上限进行协商。

8. 致谢

作者与编者谨此感谢 Steve Atkins、John Levine、Shmuel Metz、S. Moonesamy 与 Alessandro Vesely 对本备忘录所作的贡献。

本文档所引用的全部最佳实践均见于 [RFC6449]，该文档由消息传递反滥用工作组（MAAWG）的协作委员会撰写。

最后，原作者谨此感谢德克萨斯大学 MD 安德森癌症中心的医生与工作人员所做的一切。

9. 参考文献

9.1. 规范性参考文献

9.2. 资料性参考文献

作者地址（Authors' Addresses）

J.D. Falk
Return Path
100 Mathilda Place, Suite 100
Sunnyvale, CA 94086
USA

URI: http://www.returnpath.net/

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

Email: superuser@gmail.com