如何对邮件信头做取证分析、还原真实的 Received 投递链路？

NIST SP 800-86 发布于 2006 年 8 月，其核心是一个与介质类型无关的四阶段取证流程：收集（Collection）——识别、标记、记录并获取数据，同时保持数据完整性；检验（Examination）——用自动与手动方法处理收集到的数据，提取出与案件相关的部分并保留其完整性；分析（Analysis）——用合法、可论证的方法与技术，从检验结果中导出可回答提出问题的信息；报告（Reporting）——报告分析结果，包括所采取的行动、所用工具与流程的说明，以及需改进的建议。

该指南明确强调：取证不只是技术操作，还必须考虑法律与政策层面，并且过程必须可重复、可解释。邮件信头分析套用这一框架，意味着分析人不能只交出一句「这封是伪造的」，而应交出：原始报文出处与哈希、逐跳解析表、伪造点的判定依据、以及所用工具与版本。

可用于取证的只有完整原始报文（RFC 5322 消息，通常存为 .eml/.msg 或 Maildir 单文件），来源优先级从高到低为：邮件服务器侧的日志与消息存档、邮箱后台的合规导出（content search / export）、客户端的「显示原始邮件」另存。

• 禁止使用转发副本：普通转发会重建信头、可能改写字符集与 MIME 结构，原始 Received 链退化为正文引用，Authentication-Results 也会被本域重新覆盖。
• 禁止使用截图：截图无法承载信头、无法计算哈希、无法复核。
• 立刻做完整性锚定：获取后立即计算 SHA-256 并记录时间、操作人、来源系统，后续所有分析在副本上进行。
• 同步固定服务器日志：MTA 投递日志（queue id、连接 IP、TLS 参数、SMTP 响应码）是验证信头真伪的唯一外部参照，须与报文同时保全。

RFC 5321 §4.4 规定，SMTP 服务器在接收消息时必须在消息头部最前面插入一行 Received 字段，且不得改变此前已有的 Received 行。这一「只前插、不修改」的规则，决定了 Received 链的时间顺序是自下而上：最底部的一条由最早接收该消息的 MTA 写入，最顶部的一条由最后一跳（通常是本组织的边界或投递服务器）写入。

RFC 5322 §3.6.7 把 Received 与 Return-Path 一同定义为 trace 字段，并规定其内容由若干带标记的子句加一个分号后的日期时间构成，常见子句包括：from（发送方在 HELO/EHLO 中自报的名称，以及接收方观察到的实际主机名与 IP）、by（本跳接收服务器）、via（物理链路）、with（使用的协议，如 ESMTP、ESMTPS、ESMTPSA）、id（本跳的队列/消息标识）、for（本跳的信封收件人）。

关键取证原则：括号内由接收方观察记录的 IP 与反向解析结果可信度最高，from 后由发送方自报的名称可信度最低——后者完全由客户端控制，可任意伪造。

把每一跳拆解为结构化行，是发现异常的前提。建议列：跳序（自下而上编号）、时间戳（含时区，统一换算为 UTC）、自报 HELO 名、观察到的对端 IP、对端 PTR、by 主机、with 协议、queue id、for 收件人。

随后叠加外部数据：对每个 IP 查询其归属 ASN 与地理区域、是否在信誉黑名单中、其 PTR 与正向解析是否互相印证（forward-confirmed reverse DNS）。同时提取并解析同一封邮件中的 Authentication-Results 头：RFC 8601 定义了该字段用于承载消息认证状态，其内容包括执行认证的服务器标识（authserv-id）与各方法的结果。只有本组织可信边界写入的那一条 Authentication-Results 才有证据价值，外部服务器写入的同名字段可被伪造，必须依据 authserv-id 加以甄别，对不可信来源的该字段应在入站时剥离。

• 时间倒流或巨幅跳变：自下而上时间戳非单调递增，或相邻跳之间出现数小时的负向偏移（需先排除时区书写差异与 NTP 漂移）。
• 链路断裂：第 N 跳声称由主机 X 接收，第 N+1 跳却声称从与 X 无关的主机接收，by 与下一跳的 from 无法衔接。
• 凭空出现的顶部之下：伪造者通常在真实链路下方预置若干伪造 Received 行以制造「来自可信内网」的假象；因为真实 MTA 只会前插，故凡是位于最早真实跳之下的内容都应被视为不可验证。
• 格式指纹不一致：同一声称的 MTA 在不同跳中书写风格、id 格式、协议标识不一致。
• 与服务器日志矛盾：报文中的 queue id 或连接 IP 在本域 MTA 日志中不存在——这是最有力的证据，因为攻击者无法伪造受害方自有日志。
• 与认证结果矛盾：链路声称来自本域内网，但边界写入的 SPF 结果为 fail 或 none、DKIM 无签名。

结论须遵循 SP 800-86 的报告要求：区分观察事实（信头原文、日志记录）与推断（伪造判定），并对每项推断标注置信度与支撑证据；无法验证的部分应明确写为「不可验证」，而不是省略。