M3AAWG 滥用反馈报告推荐实践

在互联网的反滥用斗争中，将滥用行为举报给行为的源头，长期以来都是主要手段。向网络或域名的所有者出示证据，证明其网络中可能存在被攻陷的主机或账号正在发送滥用流量（如垃圾邮件、钓鱼邮件、病毒等），使所有者能够采取必要措施阻断问题流量。如同使用共同的语言能让两人有效沟通一样，既定义滥用报告格式、又定义报告目标地址的标准，能够有效提升网络所有者对抗滥用流量的能力。

本文引用来源：M3AAWG Feedback Reporting Recommendation, February 2014, © Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG)。

一、核心推荐

M3AAWG 认可滥用报告格式（ARF）已获得广泛采用，并提出以下核心推荐：

• 滥用邮箱地址应支持无条件接收以 ARF 格式发送的报告。
• 报告方应在其能力范围内使用 ARF 格式报告消息滥用。
• 所有拥有域名的组织、或对公网任何网段负有管理责任的机构，均应维护一个符合 RFC 2142 的滥用报告接收邮箱（abuse@domain），并对发送至该邮箱的报告进行监控和处置。该地址应在 WHOIS 中公开发布。

为支持更广泛的滥用报告场景，M3AAWG 呼吁实施者在报告邮件之外的滥用类型时，也支持扩展滥用报告格式（X-ARF）。

本文档不会重复陈述 RFC 2142、3912、5965、6449、6650 以及各区域互联网注册机构（RIR）关于滥用联系点政策的全部内容。读者应已熟悉或随后研读上述文档，以充分理解本推荐文件的上下文背景。

二、ARF 的优势

可重复流程的自动化能带来效率提升，而 ARF 标准正是为自动化处理滥用报告而设计的。它定义了一种报告滥用消息的格式，可通过机器解析轻松处理。同时，它将任何潜在危险的有效载荷封装在附件中，确保即使邮件落到典型的邮件客户端，也不会被自动加载和执行。

ARF 标准基于 RFC 5965（An Extensible Format for Email Feedback Reports），采用 Content-Type: multipart/report 的 MIME 结构，由三个部分组成：

• 第一部分（text/plain 或 text/rfc822-headers）：人类可读的摘要
• 第二部分（message/feedback-report）：机器可解析的反馈报告（包含 feedback-type、user-agent、version、original-mail-from、original-rcpt-to 等字段）
• 第三部分（message/rfc822 或 text/rfc822-headers）：原始消息或消息头

三、谁应发送（以及不应发送）ARF 报告

M3AAWG 强烈建议，任何发送自动化滥用报告的组织都应使用 ARF 格式报告邮件滥用，使用 X-ARF 格式报告其他类型的网络滥用事件。这里所谓的"自动化滥用报告"指的是邮箱提供商的用户通过邮件客户端界面的"报告为垃圾邮件"按钮触发生成的报告。此类动作应自动触发报告机制——将所投诉的消息正确封装为 ARF 报告，并路由到正确的接收地址，全程无需用户进一步操作。

然而，M3AAWG 也认识到并非所有站点都有资源部署此类系统；小型机构（如仅为少数用户提供邮件服务）不太可能具备这样的能力。M3AAWG 进一步理解，并非所有报告都适合以 ARF（或 X-ARF）格式提交。不适宜的报告可能包括涉及骚扰、版权侵权、IP 和域名封禁通知等内容。因此，M3AAWG 建议各方根据自身能力和条件，在可行范围内采用 ARF 格式。

四、ARF 报告的发送目标

ARF 报告应发送给对生成投诉的消息负有责任、且愿意针对投诉采取行动的实体。在很多情况下，这种责任关系是通过双方之间的私下协议建立的——通常是某一方注册另一方的反馈循环（FBL），遵循 RFC 6449 的规范。FBL 注册者通常会指定一个不同于其 RFC 2142 abuse@domain 的专门地址用于接收 ARF 报告，M3AAWG 强烈建议这样做。为 ARF 报告设置专用邮箱，既可以实现对邮箱流量的完全控制（仅允许已知发送者），也能实现邮箱处理的完全自动化（因为进入该邮箱的全部消息都应是 ARF 格式）。

此类安排有一个明显的局限性：双方必须存在某种预先建立的关系才能建立反馈循环。在撰写本文档时，尚未有标准化的方法用于发布专门接收和处理 ARF 报告的地址。此前曾存在一个定义了此类方法的过期 RFC 文档（draft-ietf-marf-reporting-discovery-01），但除非该工作被重新启动，否则预先安排仍是建立此类地址的唯一途径。

如果不存在此类安排，但能够可靠地识别出域名（例如通过 DKIM 认证确认流量来自该域名），则应将 ARF 报告发送到该域名的 RFC 2142 abuse@domain 地址。此外，无论域名是否被可靠识别，ARF 报告都可以发送到与连接接收 MTA 的末段服务器 IP 地址相关联的滥用地址。这些地址可以通过 WHOIS（RFC 3912）查询获取，已有自动化方法可执行 WHOIS 查询来做出报告路由决策。对于需要自动查询或高频查询的场景，存在商业化的滥用联系信息数据库，可通过互联网搜索"abuse contact database"找到。

为进一步增强报告的可信度、强化反馈循环建立的信任关系，M3AAWG 建议生成 ARF 报告的组织考虑使用 SPF、DKIM 或其他类似协议对报告本身进行身份认证。

五、接收和处理 ARF 报告

M3AAWG 期望注册了 FBL 的组织拥有专门用于接收入站 ARF 报告的地址。如前所述，这样的邮箱可以完全控制入站流量，并实现邮箱处理的完全自动化。ARF 天然设计为机器可解析格式，ARF 报告的接收者必须充分利用这一特性。

M3AAWG 认识到，ARF 报告可能到达组织公开发布的滥用地址，而非已建立的专用 ARF 邮箱，因此建议安装相应的工具来处理这种可能性。由于 ARF 报告采用可识别、可机器解析的格式，可以部署预处理器对接入滥用地址的入站邮件进行预处理，将 ARF 格式的报告与非 ARF 格式的消息区分路由。一些供应商提供专门的滥用邮件处理产品，也可以自行开发此类工具。如果滥用处理团队从已知方收到大量 ARF 报告，则可以考虑与该方建立私下协议，将其报告定向到专门的 ARF 邮箱。

无论是否设有专用 ARF 邮箱或相关处理工具，M3AAWG 强烈建议，所有发送到组织滥用地址的入站消息，都应根据其内容和格式进行恰当处理。

六、I-A-R：识别—告知—修复 三步骤

M3AAWG 推荐的滥用反馈报告流程可归纳为 I-A-R（Identify-Apprise-Remediate）三步骤方法论：

步骤一：识别（Identify）

报告方（如邮箱提供商）识别出疑似滥用行为——可能来自垃圾邮件投诉、蜜罐（honeypot）捕获、流量分析告警或用户主动举报。此阶段的关键是：

• 确认滥用行为的可验证性
• 收集足够的技术证据（消息头、IP 地址、时间戳等）
• 判断是否属于自动化报告处理的范畴

步骤二：告知（Apprise）

报告方将识别到的滥用行为以 ARF（或 X-ARF）格式封装后发送给责任方。此阶段的关键是：

• 确定正确的报告地址：优先使用 FBL 专用地址，其次使用 abuse@domain，最后通过 WHOIS 查询 IP 所属网段的滥用联系地址
• 确保报告格式符合 ARF 标准，包含必要的反馈字段
• 尽可能对报告本身进行 DKIM/SPF 签名认证，增强可信度
• 遵循速率控制原则，避免过量发送压垮接收方的处理能力

步骤三：修复（Remediate）

收到滥用报告的实体针对报告内容采取行动。此阶段的关键是：

• 及时确认接收并评估报告内容
• 调查并定位问题根源——是用户账号被攻陷、服务器配置漏误、还是第三方插件引入的恶意行为
• 采取修复措施：封禁被攻陷账号、修复安全漏洞、调整发送策略等
• 必要时向报告方反馈处理结果（如通过 ARF 的 feedback-type 字段中的"abuse"或"auth-failure"类型）

I-A-R 形成一个完整的闭环：识别是发现问题，告知是传递信息，修复是解决问题。三步骤缺一不可，仅接收而不处置的报告链路没有实际意义。

七、ARF 的速率控制

自动化滥用报告系统可能产生大量报告流量。如果一份报告针对同一域名或同一 IP 网段反复发送却未见响应，不仅会造成带宽浪费，还可能被接收方视为攻击行为。M3AAWG 建议报告方实施适当的速率控制策略：

• 对同一目标地址，设定单位时间内的最大报告发送量
• 对未响应的目标实施降频或暂停发送，直到收到响应或经过合理冷却时间
• 对已处理的报告进行去重，避免重复报告相同事件
• 与主要报告接收方事先协调可接受的报告频率

八、与 DNSBL 和 ISP 的协作

滥用反馈报告不应孤立运作。M3AAWG 建议将 ARF 报告机制与现有的反滥用生态系统集成：

• DNSBL 集成：将 ARF 报告数据作为 DNSBL 列出的参考信息来源之一，但不应仅凭单一报告即列入黑名单；应结合投诉量、来源可信度和历史行为综合判断。
• ISP 协作：ISP 可以通过 FBL 向发件人提供 ARF 报告，发件人据此调整发送行为。双方共同目标是降低整体投诉率，而非单纯的惩罚性封禁。
• 共享威胁情报：在信任框架内共享 ARF 报告的聚合数据（脱敏后），帮助社区识别大规模的滥用模式和新兴威胁。

九、国内场景补充

以上内容基于 M3AAWG 2014 年的全球推荐框架。结合国内邮件滥用举报生态，还需关注以下补充要点：

9.1 国内反馈回路运营现状

国内主流邮箱厂商在 Feedback Loop 建设方面与 Google/Yahoo/Microsoft 存在显著差距：

• 163 邮箱（网易）：网易未提供公开的 FBL 注册机制。发件人可通过网易邮箱开放平台（open.mail.163.com）申请反垃圾数据查询接口，但该接口主要是聚合分析而非实时投诉数据。自建邮件系统的运营商若需反馈，通常需要通过网易的企业邮箱商业合作渠道沟通。
• QQ 邮箱（腾讯）：腾讯提供腾讯云邮件推送服务中的投诉反馈链路，但该机制与腾讯云平台绑定。对于第三方发件人通过 QQ 邮箱个人账号的投诉，QQ 邮箱未开放标准的 ARF 格式 FBL。腾讯邮箱管理员可通过腾讯企业邮后台查看部分发送统计，但不包含细粒度的 ARF 投诉报告。
• Coremail 邮件系统：作为国内最大的邮件系统厂商，Coremail 提供了反馈循环功能——发件人可申请注册 Coremail FBL，注册后可在发件人平台上获取收件人的投诉反馈数据，部分支持 ARF 格式。

9.2 国内滥用举报渠道

除了各邮箱厂商自有的投诉机制，国内主要的滥用举报渠道包括：

• 12321 网络不良与垃圾信息举报受理中心（www.12321.cn）：由中国互联网协会运行，是国内最权威的垃圾邮件、垃圾短信和不良信息举报平台。12321 的举报数据会通报至工信部及相关运营商，具有行政监管效力。发件人应主动关注 12321 公布的被举报 IP/域名清单。
• 中国反垃圾邮件联盟（CASA）：运营有国内知名的 DNSBL（如 CBL 黑名单），部分数据来源于接受投诉反馈。
• 运营商级举报通道：电信、联通、移动三大运营商也设有各自的垃圾邮件处理渠道，严重的情况下可能直接在骨干网层面封禁 SMTP 端口。

9.3 国内发件人的落地建议

基于上述现状，国内发件人应采取以下措施：

• 在邮件头中完整部署 SPF、DKIM 和 DMARC 认证，这是邮箱厂商识别发件人身份、进行 FBL 关联的基础
• 设置并公布 abuse@ 和 postmaster@ 邮箱地址，作为接受滥用报告的标准通道
• 主动注册主要平台（Coremail FBL、腾讯云推送服务等）的反馈数据接口
• 关注 12321 的各类通报，定期自查 IP 和域名是否出现在黑名单中
• 为国内营销邮件单独设立发送子域，以便隔离声誉，同时利用阿里云邮件推送等国内 ESP 的 FBL 能力
• 保持内容合规——国内的垃圾邮件判定标准更为严格，涉及违法营销、虚假宣传类邮件一经举报会被快速处置

十、总结

ARF 是一个成熟且已广泛建立的滥用报告标准，能够帮助各类组织以自动化方式处理现今体量的滥用投诉。M3AAWG 参与并推动了该标准的编纂，认为它是当前最可行的可扩展滥用报告交换框架。

从更宏观的视角来看，ARF 和 FBL 共同构成了一个完整的反馈回路：收件人投诉→邮箱提供商生成 ARF 报告→发件人接收并处置→防止后续同类投诉。这个回路运转得越好，整个邮件生态的滥用水平就越低。M3AAWG 鼓励其成员组织及整个互联网社区遵循本文档及对应 RFC 中的滥用报告推荐。