一封钓鱼邮件已经投进了收件箱，隔离、召回、通告该按什么顺序做？

接到用户报告后最强烈的冲动是立刻把邮件删掉。这个动作会让后面所有工作失去依据。删除之后，你无法回答「这封邮件的 DKIM 签名域是什么」「附件的哈希是多少」「它是从哪个 IP 进来的」，而这些恰恰是确定影响面所必需的。

RFC 3227 给出的证据收集通行做法中，两条原则直接适用：按易失性从高到低收集，并完整记录每一步操作与时间以维持保管链。邮件场景里易失性最高的通常不是报文本身（它在归档里），而是用户邮箱中的状态——是否已读、是否已回复、是否已转发、是否已被用户自己删除。这些一旦被处置动作覆盖就找不回来了。

所以正确的第一步是三个并行的固化动作：

1. 导出完整原始报文。符合 RFC 5322 的完整形态，包含全部信头与完整 MIME 结构。不要用「转发给我一份」的方式取样本——转发会重构报文，信头会变，附件可能被重新编码，取到的不是原件。正确做法是从归档或邮箱以原始格式导出。
2. 导出投递日志。接收时间、连接源地址、信封发件人与收件人、认证判定结果、当时的策略处置结论。
3. 快照用户侧状态。该批邮件在各收件箱中的已读、回复、转发状态。

把这三份东西落到一个事件目录里，再开始处置。这一步通常只需要几分钟，而跳过它的代价是整个事件都在猜。

用户报告的那一封几乎从不是唯一的一封。确定影响面的本质是找出这一批邮件共同拥有、而攻击者又不容易在同一批次内改变的特征，也就是不变量。

常见特征按可靠性排序：

• 高可靠（优先使用）：DKIM 签名域（d= 标签，见 RFC 6376）、发送 IP 或其所属网段、附件的哈希值、正文中链接的主机名或注册域。
• 中等可靠：信封发件人域、Message-ID 的构造模式、Received 链中倒数第二跳的特征、特定的信头组合或信头顺序。
• 低可靠（不要作为主检索条件）：主题、显示名、正文措辞。这些是同一批次内也会随机变化的部分，用它们检索必然漏。

实操上，用高可靠特征做首轮检索确定基本盘，再用检索结果反推是否存在新的共同特征，迭代一到两轮。检索的时间范围要往前放宽——用户报告的时间不是投递时间，同一批次可能已经断续投递了若干天。

影响面的输出应当是一份明确的清单：哪些收件人、收到了哪几封、当前状态是什么。这份清单是后续所有分档处置的输入。

同一批邮件对不同用户的风险完全不同，处置强度也应当不同。按状态分四档：

1. 未读。直接移入隔离区。移入而不是删除，理由有二：可逆（误判时能释放），以及保留了后续核查的能力。这一档不需要单独通知用户，纳入统一通告即可。
2. 已读但无交互迹象。隔离，并单独通知。通知的目的不是提醒风险，而是要求用户确认是否点击或输入过信息——日志不一定能覆盖所有交互，用户自述是必要的补充。
3. 已点击链接。按凭据可能已泄露处理：强制重认证、检查该账号的登录审计与转发规则、检查是否有新增的应用授权。点击行为本身不必然意味着凭据泄露，但在没有反证之前应当按泄露处理。
4. 已回复、已提交信息或已执行附件。升级为账号接管或终端失陷事件，进入对应的响应流程。邮件侧的处置到此为止，不要试图在邮件层面「解决」一个已经变成终端或账号问题的事件。

另外要单独看被转发出去的情况：用户出于好意把钓鱼邮件转给同事「提醒一下」，会造成第二轮扩散，且转发件的特征与原件不同，首轮检索通常抓不到。影响面清单里必须包含转发追踪。

批量处置工具很强大，也很容易造成二次损伤。几个必须提前想清楚的点：

• 批量删除会破坏取证基础。如果工具只提供「删除」而不提供「隔离」，那么必须在执行前完成导出。这一点应当写进操作规程，而不是依赖执行人当时记得。
• 隔离区的保留期要覆盖复核周期。如果隔离区七天后自动清空，而误判申诉平均在两周后到达，那么隔离等同于删除。
• 处置动作本身要留审计。谁在什么时候对哪些邮件执行了什么操作，必须可追溯。一个能被无痕批量删除邮件的权限，本身就是重大风险。
• 对高管与法务邮箱的处置要额外谨慎。这些邮箱可能涉及保密或诉讼保全要求，批量操作前应当确认是否存在保留义务。
• 不要在处置的同时修改检测策略。两件事一起做，事后无法判断效果来自哪一个，也无法回滚。先处置，稳定后再调策略。

安全通告失效的典型原因是它只传达了情绪而没有传达动作。「近期出现钓鱼邮件，请大家提高警惕」这类通告，用户读完之后不知道要做任何事，因此不会做任何事。

英国 NCSC《Phishing attacks: defending your organisation》指南集 在组织防护的建议中反复强调一点：要建立让用户敢于上报的机制，包括上报已经点击的情形。如果用户担心上报会被追责，最有价值的那一类信息（已经上当的人）就永远拿不到。这一条对通告的措辞有直接影响。

一份可用的通告包含四段，且应当很短：

1. 特征识别。用一两句话描述这批邮件的可见特征，让用户能对上号。不要贴完整截图或可点击的链接。
2. 已经做了什么。「我们已将相关邮件移入隔离区」——让用户知道系统在工作，减少重复上报。
3. 需要用户做什么。明确、可执行、有限。例如「如果你点击过链接或输入过账号密码，请立即通过某某入口告知，我们会协助处理，不会因此追究责任」。
4. 误判怎么办。如果你发现某封正常邮件被误隔离，通过某某入口申请释放。这一段不能省——省了就会有人绕过隔离机制自己想办法。

通告渠道要注意一个细节：如果事件涉及邮件系统本身可能不可信，通告就不能只走邮件。准备一条带外通道（即时通讯、公告栏、电话树）是预案的一部分。

处置完成不等于事件结束。真正决定下次能不能更快的是闭环的两个方向。

向外：

• 向被冒用品牌方、发送源所属服务商、以及托管恶意内容的服务商报告。RFC 2142 定义了 abuse@ 这一标准职能邮箱，多数服务商据此接收滥用报告。
• 如果需要以结构化格式提交，RFC 5965 定义了滥用反馈报告的可扩展格式（ARF），它把原始报文与报告元数据封装在一起，便于对方自动化处理。结构化的报告被处理的概率明显高于一段自然语言描述。
• 涉及资金诈骗或大规模事件时，按属地要求向执法机构报案；FBI IC3 互联网犯罪投诉中心 提供了面向公众的举报入口。

向内：

• 把不变量沉淀成检测规则，但要给规则设有效期与复核点，否则规则库会持续膨胀直到无人敢动。
• 回答「它为什么能进来」。这是复盘里唯一真正重要的问题。可能的答案通常落在几处：本域或被冒用域的 DMARC 处置策略不足（见 RFC 7489）、附件类型策略过宽、链接检测未覆盖该形态、或者它确实是一封在技术上无懈可击的邮件（这种情况下要承认检测的边界，把资源投到用户上报与快速处置上）。
• 记录本次的处置耗时，分解为发现、确认、隔离三段。NIST SP 800-61 Rev. 3《Incident Response Recommendations and Considerations for Cybersecurity Risk Management》 强调响应能力需要持续度量与改进；这三个数字是最朴素也最有用的度量。