电子邮件标头分析器

电子邮件标头能说明什么，又不能说明什么

互联网电子邮件由带名称的标头字段、一个空行和邮件正文组成。RFC 5322 定义了邮件格式，其中包括字段折行：以空白开头的行是上一字段的延续。分析器先展开这些续行，再解释数据。它会在第一个空行处停止，因此不会分析正文和附件。

邮件传输代理通常会在邮件每经过一台服务器时，把一条 Received 字段加到顶部。因此，原始源代码中的字段按从新到旧排列。报告会反转顺序，生成从源头开始的时间线。只有相邻两个时间戳均可成功解析时，才会显示时间差。负值会标记为可能存在时钟偏差，并停止计算总传输时间，绝不会悄悄改成零。

如何阅读身份验证部分

RFC 8601 定义了 Authentication-Results，由接收系统添加，用于记录 spf=pass、dkim=pass、dmarc=fail 等结果。邮件可能经过多个管理域，因此分析器会保留重复的 Authentication-Results 字段。smtp.mailfrom、header.d、header.from 等相关属性也会按原记录保留。

DKIM-Signature 包含签名域（d=）、选择器（s=）、算法（a=）、身份（i=）以及较大的加密值（b= 和 bh=）等元数据。报告会记录有用标签以及签名值是否存在，但会有意从 JSON 导出中排除签名数据块。工具不会查询 DNS，也不会进行加密验证。

RFC 8617 定义了 Authenticated Received Chain（ARC）。如果某个 ARC 实例包含 i= 值相同的 ARC-Seal、ARC-Message-Signature 和 ARC-Authentication-Results，则称其“结构完整”。这里的“完整”只说明三个成员齐全，并不表示链有效或可信。

路由示例

假设原始源代码包含两条 Received。下面一条显示源服务器在 10:00:03 +0000 将邮件交给中继服务器，上面一条显示中继服务器在 10:00:10 +0000 到达收件服务器。报告会先显示源头事件，并计算出观察到的间隔为 7 秒。工具会正确处理时区偏移：10:00:03 +0000 到 12:00:06 +0200 相隔 3 秒，而不是两小时。如果标准化后的第二个时间戳反而早五秒，报告会标记时钟偏差，并将总时间设为不可用。

信任边界与常见误区

RFC 5321 描述了 SMTP 传输和服务器添加的追踪信息。来自可信邮件系统之外的标头可以被捏造。应以您控制的接收系统作为信任起点，只在该系统的记录和策略能够支持的范围内向下追溯。显示的 From 域与 Return-Path 域不同，在邮件列表、转发服务和事务邮件平台中很常见；这只是一项观察，并非冒充的证据。

经过编码的主题和显示名称可能使用 RFC 2047 encoded-word。分析器可解码 UTF-8、ISO-8859-1 和 Windows-1252 中常见的 Base64 或 quoted-printable 格式；不支持的编码会原样保留并显示警告。字段或中转数量过多时会进行限制，以保持浏览器响应。处理安全事件时，请另行保留原始邮件：导出的是精简报告，有意不包含原始输入、正文、附件或 DKIM 签名数据块。

隐私与导出

解析、选择、复制和生成导出文件均在当前标签页中本地完成。漏斗步骤使用标签页范围的会话存储，而不是 URL，因此原始标头不会通过 Livewire 发送，也不会出现在导航参数中。输入上限为 512 KiB。时间线 CSV 使用带字节顺序标记的 UTF-8 和 CRLF 行，并会净化以电子表格公式字符开头的单元格。JSON 不含原始标头，而是包含解析后的观察结果和报告免责声明。