[ 诊断和资源 ]

标头分析器指南:识别可信结果

设计一个标头分析,保留原始结构并在分配信任之前识别每个身份和身份验证声明的提供者。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • 保留原始原件并标记每个带注释或编辑的衍生产品。
  • 在接受Authentication-Results之前识别受信任的接收环境。
  • 保持作者、信封、回复和签名身份清晰。
  • 不提供真正的带注释的标头、解析器演示或工作分析器。
在此页面上

将标题视为一组不同作者的声明

电子邮件标头分析器不应向包含单词 pass 的每个字段授予信任。标头结合了用户选择的身份、传输跟踪字段、不同系统添加的签名和断言。分析师的首要任务是确定谁可以提供每个声明以及读者准备接受哪个系统的权威。如果没有这个界限,简洁的摘要可能会使伪造的文本看起来像证据。

这是建议的分析器的指南,而不是有效的EmailAuth功能。没有访问客户标题、邮箱或消息。调试实现大门已显式打开:实现并测试承诺的功能。一篇文章、模型或规范本身并不是一个有效的工具。

保留原始原件和单独的显示视图

授权调查应从原始收到的消息或原始标头导出开始, 一个记录 其来源。保留字段顺序、重复字段、折叠和原始字节。用户界面屏幕截图或转发的报价可能会省略重要的结构。生成带注释或经过编辑的视图作为衍生视图,并在其存储合理时保留原始视图的受控链接。

RFC 5322定义了标头字段和折叠,但正确解析字段并不能验证其作者。对格式错误或不明确的输入保留解析器警告,而不是默默地将其修复为自信的结论。仅标头导入还缺少完整所需的消息正文 DKIM 确认。在呈现任何加密结果之前先说明该限制。 RFC 5322 和 RFC 6376.

建立接收环境的信任边界

Authentication-Results 包含认证服务标识符和方法结果。要使用它,请确定哪个服务是可信的,可以为此邮箱或消息路径生成断言,以及接收环境如何处理该字段的传入副本。看起来熟悉的 authserv-id 字符串并不能证明出处;它只是一个字符串。外部发件人可以键入相同的字符串。

RFC 8601使信任成为生产者到消费者上下文的属性,而不是受信任主机名的通用列表。工具无法仅从标题文本推断出该上下文。它应该接受单独建立的环境配置文件或使断言不受信任。如果消息离开并重新进入边界,或者出现在附加消息内,请勿假设外部接收者认可嵌入的结果。 RFC 8601.

跟踪字段可以帮助重建消息的传输位置,但它们也需要来源。在解释之前的接收条目之前,先确定受信任的接收基础设施添加的部分。不要仅将位置、反向主机名或长链视为所有先前系统都是真实的证据。如果时间戳不一致,请保留差异,而不是将其重写为精确的旅行时间线。

将身份保留在单独的列中

可见的 From 字段表示作者身份,而 Reply-To 是回复目的地,可能有所不同。用于的SMTP信封标识 SPF 是另一个值,并且 Return-Path 字段必须在其交付上下文中进行解释,而不是自动等同于可见的作者。 DKIM 'sd= 值标识签名域,s= 选择其密钥。外观相似的域名不可互换的身份。

拟议的注释应显示每个身份的原始字段、解析值、断言角色和证据来源。避免允许友好的显示名称隐藏实际的地址域。 SPF的评估输入和DKIM的签名字段来自各自的协议;两者都不会仅仅因为发件人地址与品牌匹配而成立。 RFC 7208 和 RFC 6376.

解释相互矛盾的结果而不选择最好的结果

多个Authentication-Results字段可以描述不同系统在不同阶段执行的检查。一个可能会报告上游通过,而最终接收者报告稍后的故障。保留这两个断言的来源和信任状态。请勿将来自一个不受信任领域的SPF与来自另一领域的DKIM相结合来生成最终结果 DMARC 判决。

当前的 RFC 9989 需要相关的成功身份验证才能与作者域保持一致。不相关身份的传递结果可能与DMARC失败共存。转发和消息修改也可以改变后来评估者观察到的内容。分析器应该将接收者报告的决定与它自己的解释性推论区分开来,并避免承诺标头揭示每个原因。 RFC 9989.

导入和共享时最大程度地减少暴露

标头可以公开地址、内部主机名、路由信息和消息标识符。仅导入用户有权检查的材料,应用声明的保留目的并在上传到外部分析仪之前获得批准。适合票证的经过编辑的屏幕截图不一定适合密码重新验证。将这些目的分开。

将导入的值呈现为不受信任的文本,而不是可执行的标记或指令。限制输入大小和字段计数,安全地拒绝不支持的结构,并且不会自动访问标头中找到的 URL。这些是提议的保护要求,而不是经过测试的功能。 OWASP 的文件上传指南支持分层验证和安全存储,而不是信任扩展或声明的内容类型。 OWASP 文件上传备忘单.

生成带注释的解释而不是判决徽章

预期的输出是源映射:受信任的接收者断言、不受信任的继承声明、用户控制的身份和未解析的出处。对于虚构的消息,伪造的Authentication-Results行表示dkim=pass将保持不可信状态,直到确定其来源为止。这个例子说明了一个决策规则;这里没有处理任何恶意消息。

确切的原始证据门仍然存在:带注释的原始标头,标记信任边界以及每个身份和判决的起源。没有提供真正的带注释的标头或经过测试的解析器。公共来源于 2026 年 11 月 8 日进行了审核,包括当前的DMARC指南。仍然需要独立检查、人工消息传递和隐私审查、实施装置、视觉验证和所有者发布批准。

[ 外卖 ]

身份验证断言仅在具有可信来源和路径的情况下才有用;其案文或立场本身无法建立这种信任。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

邮件管理员

定义接收信任上下文

解析器无法仅从字符串派生组织的可信身份验证服务。提供记录的边界,而不是让显示启发式成为策略。

后续步骤

  1. 识别可信的结果生成者以及如何处理外部副本。
  2. 将可信跟踪条目与早期不受支持的声明区分开来。
  3. 检查涉及转发、附加消息和边界重新进入的路径。

证券分析师

在使用每个判决之前先对其进行归因

保留相互矛盾的断言作为调查证据。通行证标签在某一阶段可能是真实的,在另一阶段可能是伪造的或与作者身份无关。

后续步骤

  1. 注释每个报告方法结果的来源和信任状态。
  2. 将原始字段、解析身份和分析推论明显分开。
  3. 使用经过批准的原始消息证据来解决除标头检查之外的加密问题。

隐私审查员

批准证据目的和受众

即使没有消息正文,标头数据也可能暴露人员和基础设施。编辑应该与接收者和任务相匹配,而不是暗示所有诊断实用程序都有效。

后续步骤

  1. 在任何实际导入或第三方上传之前检查字段和保留。
  2. 将票证安全衍生品与受控验证原件分开。
  3. 确保格式错误的输入和错误日志不会泄露不必要的消息内容。

[ 常见问题解答 ]

常见问题

熟悉的 authserv-id 可以单独识别可信的Authentication-Results字段吗?

不可以。标识符是外部发件人可以模仿的文本。信任取决于生产者到消费者的上下文以及接收环境对传入断言的处理,而不仅仅取决于字符串熟悉程度。

为什么要保留原始标头中的重复字段和折叠?

它们是消息结构的一部分,可能会影响解释或加密处理。解析的显示可以使呈现标准化,但它应该保留带有警告和受控原始链接的衍生物。

最上面的结果是否总是覆盖之前的结果?

没有普遍的立场规则可以建立信任或正确性。识别每个断言的生产者、评估阶段和可信边界。不要仅仅因为出现的位置而选择有利的结果。

Return-Path只是可见 From 地址的另一种拼写吗?

否。将与递送相关的信封身份和可见作者身份视为不同的。 SPF和DMARC使用特定的协议标识,在得出结论之前必须了解该字段的来源。

附加消息的身份验证结果可以继承其外部消息的信任吗?

不是自动的。 RFC 8601讨论了离开和重新进入信任边界,包括消息附件。外部交付并不能确定每个嵌入断言的可靠性。

编辑标头是否始终保留DKIM可验证性?

不会。更改签名标头字段可以更改验证输入,并且仅标头副本也会省略正文材料。经过编辑的解释和原始的密码验证有不同的目的。

标头分析器是否应该自动跟踪它找到的 URL?

拟议的设计不应该。导入的内容不受信任,URL 可能会触发不必要的泄露或访问。任何外部查找都需要单独定义的目的、目标和授权,而不是自动执行。

这个标题分析器委员会还缺少哪些证据?

一个真实的带注释的原始标头,用于标识每个判决的来源和信任边界,以及一个已实施和测试的分析器。虚构的伪造通行证示例不满足这两个要求。

[ 来源 ]

来源

  1. OWASP 文件上传备忘单
  2. RFC 5322 :互联网消息格式
  3. RFC 6376 :域名密钥识别邮件签名
  4. RFC 7208 :发件人策略框架
  5. RFC 8601 : Authentication-Results标头字段
  6. RFC 9989 :基于域的消息身份验证、报告和一致性

[ 词汇表 ]

词汇表

认证服务标识符
authserv-id 值命名断言身份验证结果的服务;它需要值得信赖的出处,而不仅仅是认可。
可信跟踪段
消息跟踪的一部分,其起源是在接收环境的可接受的权限边界内建立的。
标头导数
由保留的原始数据制成的带注释、标准化或编辑的视图,并进行标记,因此不会将其误认为是未更改的验证输入。
身份归属
解析的域或地址与其协议角色和源字段的显式关联,无需合并作者、信封、回复和签名者身份。
不可信的判决
一种身份验证声明,其生产者或交付路径尚未建立为可靠的,无论其文本是否显示通过。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库