RFC 5965：ARF — 滥用报告格式

Current Standard Abuse Reporting & Feedback Published March 2026

ELI5: 当某人在电子邮件客户端中点击"举报垃圾邮件"时，邮箱提供商需要一种方式将其通知给发件人。ARF是该投诉的标准化格式——一条结构化消息，表示"此收件人将您的电子邮件标记为垃圾邮件"，并附带违规消息的副本。

为什么存在

邮箱供应商（Gmail、Yahoo、Outlook等）允许用户将不需要的电子邮件举报为垃圾邮件。负责任的发件人需要此反馈来将举报者从列表中删除并识别发送问题。没有标准格式，每个供应商都会使用不同的举报格式，使自动处理不可能。

ARF提供了标准。邮箱供应商使用它发送反馈循环（FBL）报告，发件人解析这些报告以：

立即抑制举报的收件人
按活动、IP或发送域跟踪举报率
检测被入侵的帐户或意外发送
报告身份验证失败和其他滥用类型

工作原理

ARF报告是一条multipart/report MIME消息，其中report-type=feedback-report。它包含三个部分：

人类可读的描述（text/plain）— 为人类审阅者提供摘要。
机器可读的报告（message/feedback-report）— 由本RFC定义的结构化字段。
原始消息（message/rfc822或text/rfc822-headers）— 被举报的电子邮件。

ARF报告示例

From: feedback@isp.example.com
To: abuse@sender.example.com
Subject: FBL report - complaint from user
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is an abuse report for a message received
from IP 203.0.113.10 on Wed, 11 Mar 2026 09:15:00 -0500.

--ARF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: ISP-FBL/1.0
Version: 1
Original-Mail-From: campaign@sender.example.com
Arrival-Date: Wed, 11 Mar 2026 09:15:00 -0500
Source-IP: 203.0.113.10
Reported-Domain: sender.example.com
Authentication-Results: isp.example.com;
    dkim=pass header.d=sender.example.com;
    spf=pass smtp.mailfrom=sender.example.com

--ARF-BOUNDARY-001
Content-Type: message/rfc822

From: campaign@sender.example.com
To: user@isp.example.com
Subject: Weekly Newsletter #42
Message-ID: <news-42@sender.example.com>
List-Unsubscribe: <https://sender.example.com/unsub?id=xyz>
[original message body]

--ARF-BOUNDARY-001--

关键技术细节

反馈类型值

类型	含义
`abuse`	用户将消息举报为垃圾邮件（最常见的类型）
`fraud`	消息似乎是网络钓鱼或诈骗
`virus`	消息包含恶意软件
`other`	不适合其他类别的报告的通用类别
`not-spam`	用户表示这不是垃圾邮件（误报修正）
`auth-failure`	身份验证检查失败（RFC 6591扩展了此项）

必需字段和可选字段

字段	必需	描述
`Feedback-Type`	是	报告的类型（见上文）
`User-Agent`	是	生成软件的名称和版本
`Version`	是	本RFC始终为`1`
`Original-Mail-From`	否	被举报消息的信封发件人（MAIL FROM）
`Arrival-Date`	否	被举报消息到达的时间
`Source-IP`	否	发送被举报消息的IP
`Reported-Domain`	否	与被举报消息关联的域
`Authentication-Results`	否	按RFC 8601的身份验证结果
`Reported-URI`	否	在被举报消息中找到的URI（可重复）
`Original-Rcpt-To`	否	被举报消息的信封收件人

隐私考虑

许多邮箱供应商从包含的原始消息中隐去收件人地址以保护用户隐私。举报可能仅包含标题，不包含完整正文。某些供应商（特别是Yahoo）包含完整的原始消息；其他供应商（如Microsoft）仅发送标题。您的ARF解析器必须处理这两种情况。

常见错误

未注册反馈循环。大多数主要邮箱供应商要求您为其FBL计划注册发送IP或域。没有注册，您将永远不会收到ARF报告。
忽略举报率。邮箱供应商跟踪举报率（举报/发送到收件箱的消息）。超过0.1%是警告；超过0.3%通常会触发过滤或阻止。解析ARF报告并快速采取行动。
未立即抑制举报者。当您收到Feedback-Type: abuse的ARF报告时，立即抑制该收件人。继续向举报过的人发送邮件是快速进入黑名单的途径。
仅解析特定FBL格式。不同供应商可能包含不同的可选字段或改变原始消息内容。构建一个健壮的解析器，能够优雅地处理缺失的字段。
将ARF与DSN混淆。DSN（RFC 3464）报告传递状态（退回/延迟/成功）。ARF报告用户举报。它们使用类似的multipart/report结构，但report-type值和用途不同。

可投递性影响

举报率是顶级信誉信号。Gmail、Yahoo和Microsoft都使用举报率来决定是否将您的邮件投递到收件箱、垃圾邮件文件夹或直接拒绝。对于任何严肃的发件人，ARF处理都不是可选的。
FBL数据驱动列表卫生。ARF报告准确告诉您哪些收件人不想要您的邮件。这比退回更可操作，因为该地址有效 — 人类只是不想要您的消息。
活动诊断。通过将ARF报告与原始消息中的Message-ID或自定义标题关联，您可以识别哪些活动、主题行或内容引发了举报。
帐户入侵检测。ARF报告中的突然激增可能表明客户的帐户或API密钥已被入侵并被用于发送垃圾邮件。