邮件安全事件的证据保全应满足哪些技术与法律要求？

RFC 3227 于 2002 年 2 月发布，编号为 BCP 55，是 IETF 关于证据收集与归档的最佳当前实践。其「法律考量」部分指出，计算机证据须具备五项属性：可采纳（Admissible）——必须符合可在法庭上使用的规则；真实（Authentic）——能够将证据实质性地关联到事件；完整（Complete）——须讲述完整的故事，而不只是某一特定视角；可靠（Reliable）——收集与处理过程不得引起对证据真实性与可信性的怀疑；可信（Believable）——应对陪审团易于理解和相信。

这五项直接决定邮件证据的取舍：截图不满足「真实」与「完整」，因为无法承载信头且可被篡改；只取一封邮件而不取整个会话线程与相关日志，不满足「完整」；在生产邮箱中直接操作、边看边改，不满足「可靠」。

RFC 3227 的核心操作原则之一是按易失性顺序（Order of Volatility）采集：先采集易失程度高的数据，再采集持久数据。其给出的通用顺序依次为寄存器与缓存；路由表、ARP 缓存、进程表、内核统计与内存；临时文件系统；磁盘；与该系统相关的远程日志与监控数据；物理配置与网络拓扑；归档介质。映射到邮件事件：

• 最易失：攻击者控制的钓鱼落地页与 C2 基础设施（存活常以小时计，须立即抓取并存档 HTML、响应头与截图）；活动会话与令牌状态；MTA 队列中尚未投递的消息。
• 次易失：留存期较短的日志——邮件网关裁决日志、代理与 DNS 日志、身份平台登录日志、云邮箱审计日志（不同平台默认留存期差异极大，须先确认再排期）。
• 较持久：邮箱中的邮件本体、可恢复项目目录、终端上的本地邮件文件与附件。
• 最持久：归档系统与备份。

RFC 3227 同时列出「应避免的事项」，包括不要在受影响系统上运行会改变其状态的程序、不要关闭系统直至完成证据收集、以及不要信任受影响系统上的程序。对邮件事件的直接含义是：调查用的搜索与导出应走服务端合规工具，而非登录受影响用户的客户端逐封翻看。

RFC 3227 的归档程序部分明确要求清晰记录证据的保管链，需说明证据是如何被发现、如何被处理的，以及此后发生的一切；并应能详细描述以下内容：证据在何处、何时、由何人发现与收集；证据在何处、何时被处理或检查，由何人经手；证据在各时间段内由谁保管，如何存储；以及当保管权发生转移时，转移在何时发生、如何进行（含运输单号等）。

落到邮件证据的最小记录集：每份导出物的文件名与 SHA-256 校验值、来源系统与查询条件、导出时间（含时区）、操作人与其授权依据、存储位置与访问控制、每一次转交的时间与接收人。哈希须在获取的第一时间计算并独立留存，此后每次转交前后各校验一次并记录结果——这是证明「完整」与「可靠」的技术支点。

• 必须是原始 RFC 5322 报文：保留全部信头（Received 链、Message-ID、Authentication-Results）、完整 MIME 结构与原始附件。RFC 5322 定义的消息格式是解释一切链路与身份证据的基础，任何重新封装都会破坏它。
• 禁止内联转发取证：转发会重建信头，原始 trace 退化为正文引用。正确做法是「作为附件转发」或由服务端导出。
• 同时固定服务端日志：报文可被伪造，本方 MTA 与网关日志不可被外部伪造，二者相互印证才构成完整链条。
• 在副本上分析：原始导出物只读封存，全部检验与分析在工作副本上进行。
• 记录工具与版本：NIST SP 800-86 要求报告说明所采取的行动以及所用工具与流程，工具版本变更可能影响解析结果，必须可复现。

取证要求「不要动」，响应要求「立刻处置」，二者的冲突在邮箱失陷场景中最为尖锐：删除恶意转发规则会销毁攻击意图证据，清理钓鱼邮件会使范围统计失去原始依据。可行的化解方式是「先快照、后处置」——在执行任何清理前，先导出配置快照、规则清单与相关邮件，用几分钟换取完整证据，再执行遏制。

此外需注意三项治理要求：其一，法律保全（legal hold）优先于留存策略，一旦进入诉讼或监管调查预期，须立即暂停相关邮箱与日志的自动清理，否则可能构成证据灭失；其二，隐私与授权——RFC 3227 专门讨论隐私考量，提醒尊重被调查者的隐私准则与法律要求，对员工邮箱的调查性访问须有明确的内部授权与制度依据，涉及跨境数据时还需评估适用法律；其三，能力预置——NIST SP 800-61 Rev.3 与 SP 800-86 都强调准备工作的重要性，包括预先确定日志留存期、导出权限归属、证据存储位置与法律联络人。这些若等到事件发生时才现场决定，往往已错过最易失证据的采集窗口。