写一份会被读的注册商 abuse 通报 — 6 条让通报真正生效的设计

反钓鱼这件事里，检测只是容易的那一半。让注册商真的下手处理才是多数项目卡住的地方。典型剧本大家都熟悉：发现一个高仿域名，礼貌地给 abuse@{registrar} 发封邮件，然后两周过去杳无音讯。

注册商的 abuse 团队其实有一个粗暴但有效的过滤机制——他们在最初 30 秒内决定要不要读这封通报。被判定读的会处理；被判定不读的就堆在误分类 DMCA 抱怨和竞争对手骚扰的背后，直到陈旧性自我消解然后 close。

本文是避开那个过滤器的结构化指南，基于 OpenBait 生产环境中在用的模板 以及和若干大型注册商 abuse 团队打交道的经验总结。

先理解：abuse 团队那边的真实队列

写通报前，先理解对方的状况。

大型注册商的 abuse 团队每天处理几百到几千条通报。其中大量是噪声：

• 误分类——DMCA / 商标投诉进到了 abuse 通道
• 证据薄弱——只贴一个 URL，没有截图、没有 WHOIS
• 情绪化口吻——开头就"你们公司纵容诈骗"
• 恶意利用——竞争对手用 abuse 通道施压做下架

所以 abuse 团队默认对所有看起来像噪声的通报降级。你的通报必须一眼看起来就是真的，而且很快。

设计 1 — 在标题里声明 abuse 分类

每个注册商的 abuse 政策都有分类体系——Phishing / Malware / Spam / CSAM / Copyright / Trademark——而且队列往往按分类路由。用商标语气的标题提交 phishing 通报，可能会被转去错误的团队。

我们在用的标题模板：

Phishing Abuse Report — freee-login-help.com impersonating freee K.K.

要避免的套路：

• ❌ 「询问」「关于一个域名」——不可读，必被忽略
• ❌ 「版权和钓鱼」——双重分类让 ticket hold
• ❌ 标题空白 / 全角符号 / 非 ASCII 符号——触发 spam 启发

核心原则：商标纠纷走 UDRP，版权走 DMCA，credential 收集页走 abuse。绝对不能混。

设计 2 — 提交"可复现的证据"

abuse 分析师必然会复现你声称的情况。复现不了的就不 suspend。结构良好的证据块应当包含：

1. live 截图（headless 浏览器抓取，URL 可公开访问）
2. 视觉相似度指标——对正规登录页的 pHash distance、SSIM，用数字替代"看上去很像"
3. 行为证据——页面实际做什么？登录表单 action URL 是哪？credential 字段在不在？body 包含哪些品牌关键字？
4. WHOIS / RDAP 元数据——创建日期、registrar IANA ID、nameserver
5. 第三方威胁情报——Google Safe Browsing 状态、PhishTank ID 等

反面模式是**"只给 URL"**——强迫审核员自己打开浏览器调查。这种通报处理最靠后。

设计 3 — 明示为什么是 abuse 而非 DMCA / UDRP

abuse 团队经常看到"本应走 UDRP 的通报"。为他们省掉判断：

This domain hosts a credential-collection page designed to deceive {{victim_brand}}'s customers into entering their account credentials, which is consistent with {{registrar}}'s published abuse policy classification of "Phishing". This report is filed under the abuse category, not under DMCA (no copyrighted content claim) or UDRP (no trademark dispute claim).

这行字消除审核员"要不要转给法务"的分支决策。减少对方的决策面是提升回应率最直接的一招。

设计 4 — 明示代理品牌方的授权链

注册商每天都收到第三方钓鱼通报——安全研究员、威胁情报源、自动提交。明示你是代表受害品牌方提交的 给审核员一个优先级理由：

The legitimate brand owner ({{victim_brand_legal_name}}) has authorized OpenBait to submit takedown requests on their behalf as part of their anti-phishing program.

用完整法人名称（株式会社 / Inc. / Co., Ltd. / GmbH）——比非正式品牌名更严肃、更可验证。

设计 5 — 固定 reporter 身份

大型注册商明确要求这一点。他们的 abuse 团队按 reporter 邮箱维护信誉档案。散兵游勇式的投递看起来就像无协调的噪声。

• ✅ 全流程用一个固定 reporter 地址（例如 [email protected]）→ 信誉累积，3–6 个月后 abuse 团队开始预先高优先级处理你的来件
• ❌ 不同员工的个人邮箱各自发——每次从零验证，回应率上不去

多个主要注册商都有trusted reporter 程序——信誉累积够了之后可以从邮件升级到 API 批量提交。路径永远是：先用邮件挣，再移动。

设计 6 — 事先规划 escalation

发出去 72 小时没回音，你应该已经知道 后续选项。事先定义：

浏览器 blocklist（Safe Browsing、SmartScreen）是最被低估的并行路径——让终端用户直接受保护，不需要注册商动。默认和 abuse 通报并行发。

OpenBait 的自动化

上述各片段在 OpenBait 里被拼成一条自动化管道：

1. 候选检测（CT 日志 + NRD feed + dnstwist）
2. 证据采集（headless Chromium 截图、pHash / SSIM 计算）
3. 通报生成（模板自动填充、按 registrar 分支）
4. 投递（固定 reporter 地址、SMTP relay）
5. 状态跟踪（回件捕获、每条 ticket 状态机）

检测部分参考 仿冒域名检测实务指南；并行的浏览器 blocklist 路径参考 浏览器 blocklist 通报指南。想把整条管道跑在自己的域名上，用 免费额度。

真正的要义——设计的是"可持续"，不是"单次成功"

一条写得好的通报可能通、也可能不通。真正复利的是长期用同一结构、同一地址发送。abuse 团队会认出你的签名，你会从普通队列升到"高信号 reporter"队列，回应加速，trusted reporter API 接入变得可能。

失败模式是去体系化——写通报的那一个人被调到别的岗位，reporter 身份碎片化，信誉归零。中型安全团队的这个循环反复上演。

体系化流程，不是体系化个人。这正是 OpenBait 存在要做的产品。