[ 转发和ARC ]

电子邮件签名服务和DKIM损坏

将可见签名插入与DKIM签名分开,然后检查最终消息的集成路径、 MIME更改和域对齐。

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

[ 要点 ]

  • 联系人页脚和DKIM签名是不同的机制。
  • 客户端和服务器端插入可以位于传送路径中的不同点。
  • 提供者签名可以在不与可见作者域对齐的情况下进行验证。
  • 外观、重复插入和验证需要单独的验收检查。
在此页面上

将可见签名与加密签名分开

电子邮件签名服务通常会添加可见材料,例如个人的联系方式、公司徽标或法律措辞。 DKIM 添加一个加密标头,将选定的消息内容绑定到签名域。共享词“签名”并不使这些操作可以互换。关键问题是可见内容是插入在之前还是之后 DKIM签名 接收者评估。

此处未检查签名服务帐户、连接器或原始客户消息。本文提供了一个诊断计划和一个虚构的订购示例。原始证据门保持开放:原始和修改后的原始消息、签名者放置以及前后验证测试。在将事件归因于服务之前收集这些信息。

找到插入可见材料的位置

用户的邮件应用程序可以在撰写期间插入签名。服务器端服务可以接收提交的消息、添加内容并继续发送。其他工作流程将客户端插入与服务器回退结合起来。这些是可能的设计,而不是通用的产品行为。询问具体支持的集成以及受影响的发件人实际使用的路由。

Microsoft 的文档将用户应用的签名与添加签名、页脚或标题的组织范围的邮件流规则区分开来。它表明即使在熟悉的平台内插入位置也可能不同。它不建立未知第三方服务和组织的DKIM签名者的相对顺序。保留提供商适用的集成指南并单独验证部署顺序。 微软消息添加

读取实际失败的签名

记录DKIM签名域, 选择器, 规范化 以及每个签名的签名标头列表。一条消息可能携带来自多个处理阶段的签名,并且每个处理阶段都必须独立评估。请勿将一个失败的原始签名和一个有效的提供商签名总结为单个无法解释的“ DKIM问题”。保留与每个检查相关的结果和域。 RFC 6376第 3.5 节和 4.2 节

对于正文,比较所选规范化后的字节,而不仅仅是电子邮件的外观。宽松的正文规范化规范了指定的空白;它不会删除徽标、新的 HTML 表或更改的链接。相反,仅由允许的空格组成的更改不需要使该签名无效。在描述覆盖范围时检查任何 l= 正文长度限制,但不建议将新附加的业务内容保留为未签名作为默认修复。 RFC 6376第 3.4 和 8.2 节

比较MIME形式和路由变体

消息可以包含纯文本和 HTML 替代项、嵌入图像和附件。服务器端的添加可能会改变比一个邮件客户端显示的部分更多的内容。在相关边界捕获未更改的原始消息,并比较MIME结构、编码和生成的规范化正文。在屏幕上看起来相同的图像仍然可以伴随不同的序列化消息。

包括对组织重要的路由:桌面组合、移动发送、共享地址回复和自动化应用程序(如果适用)。他们的路径可能不同。一条桌面消息的传递不能证明移动消息使用相同的签名者或避免了第二次插入。将未知路由记录为空白,而不是发明提供商默认值来填补它们。

完成虚构的双重插入

想象一下虚构的example.com准备一条包含用户添加的文本签名的消息。其出站签名者应用带有d=example.com.完整DKIM签名。稍后的服务会在外部交付之前附加集中管理的 HTML 签名。假设输入签名已验证并且添加的材料更改了规范化主体。然后,原始签名无法对修改后的表示进行验证。这是一个构建的示例,而不是执行的试验。

假设服务也使用d=signature-service.example进行签名,而可见的 From 仍然是person@example.com 。该新签名可以在不与作者域对齐的情况下有效。 DMARC 评估对齐的经过身份验证的标识符,而不是最近添加的任何签名。单独对齐 SPF 结果仍然可以提供通过路径,因此仅失败的原始DKIM签名并不是完整的DMARC诊断。 RFC 9989第 3.2.10 和 5.3 节

审查签署命令而不授予新的权限

对于合法的example.com出站邮件,建议的集成可能会在授权的example.com签名者处理最终邮件之前完成可见内容插入。另一种受支持的体系结构可能具有适当授权的服务,在其添加后执行对齐签名。哪个选项可用取决于记录的产品行为和实际租户设计;本文尚未对两者进行配置。 RFC 6376第 5.1 节

更改签名顺序与向供应商提供私钥材料或广泛的中继权限不同。在提议部署之前确定负责域、批准的身份和凭证边界。将供应商添加到SPF不会修复更改的DKIM 正文哈希,并且它不会自动使不相关的信封标识对齐。将信封授权和消息签名完整性视为不同的任务。 RFC 7208第 2.4 节 RFC 9989第 3.2.4 节

验证外观和身份验证

验收计划应包括预期的品牌、无重复添加、正确的链接和可读的纯文本输出以及加密检查。视觉上有吸引力的结果可能会导致身份验证失败,而有效的签名可能会覆盖错误的公司页脚。为内容审批和邮件身份验证分配单独的所有者,以便这两个标准都不会默默地替代另一个标准。

经过单独授权的测试后,保留原始和最终的原始样本、路由证据、相关公钥上下文和每个签名验证者结果。使用 Authentication-Results 仅来自已确定的可信评估员;复制的字段并不能证明最终消息的完整性。该包不包含此类操作示例或已完成的特定于帐户的验证。 RFC 8601第 7 节

[ 外卖 ]

当支持的体系结构允许时,在授权的最终签名者之前完成预期的可见内容更改,并验证实际路径而不是假设供应商行为。

[ 按角色 ]

这对您意味着什么

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

品牌拥有者

定义预期的最终内容

加密通行证并不能证明出现了正确的联系方式和法律措辞。

后续步骤

  1. 分别批准纯文本和 HTML 外观。
  2. 检查客户端和服务器插入之间的重复签名。
  3. 将内容接受与身份验证结果分开。

邮件集成工程师

找到插入和最终签名

集成图必须描述部署的路线,而不仅仅是通用的供应商设置。

后续步骤

  1. 识别范围内的发送者和客户端路由。
  2. 合法更改后验证任何受支持的最终一致签名者。
  3. 保持明确的域授权和凭证保管。

电子邮件可靠性分析师

保留每个签名的证据

多个签名可以对同一修改后的消息产生不同的结果。

后续步骤

  1. 记录每个签名域和验证者结果。
  2. 比较相关边界处的规范化MIME内容。
  3. 避免在一次成功的桌面测试中宣布所有客户端均已准备就绪。

[ 常见问题解答 ]

常见问题

用户看到的签名与DKIM签名相同吗?

不。可见的签名是消息内容,例如联系方式或品牌。 DKIM是覆盖选定消息输入的加密标头。它们的交互取决于内容插入是发生在评估的DKIM签名之前还是之后。

桌面和移动消息必须采用相同的签名服务路径吗?

这里没有这样的假设是合理的。客户端组成、服务器回退和集成设置可能有所不同。在概括之前建立支持的设计并捕获每个相关发送者和客户端的实际路由。

轻松的身体规范化是否会忽略新插入的徽标?

不会。它标准化了特定的空白模式,而不是任意的 HTML、图像或新措辞。比较规范化的序列化主体(包括MIME结构),以确定此签名所覆盖的输入是否发生更改。

相同的屏幕渲染能否隐藏与 DKIM 相关的更改?

是的。渲染视图不会完全暴露MIME边界、编码或原始表示。保留原始消息并评估所选的规范化输入,而不是仅根据外观来确定完整性。

为什么服务的DKIM通行证仍然无法留下对齐的DKIM路径?

它的 d= 域可能与 From 中的作者域无关。 DMARC需要有效的签名身份才能在适用的模式下进行对齐。最新的签名不会自动成为相关的对齐签名。

将签名供应商添加到SPF是否可以修复正文哈希不匹配问题?

否SPF授权信封身份的发送连接;它不会重新计算DKIM正文签名。通过的SPF结果还必须与作者域保持一致,以提供正在讨论的DMARC路径。

修复是否应该让新附加的内容落在DKIM正文覆盖范围之外?

不作为默认解决方法。减少身体覆盖可能会使附加材料未经验证。优先审查支持的插入和授权签名顺序,同时保留预期内容和安全要求。

在批准此整合之前必须证明什么?

保留原始和修改后的原始消息、实际签名者位置和前后验证测试,以及相关路由的外观和重复插入检查。本草案中不存在这些针对租户的特定意见。

[ 来源 ]

来源

  1. Microsoft Exchange Online :免责声明、签名、页脚和页眉
  2. RFC 6376 :域名密钥识别邮件 ( DKIM ) 签名
  3. RFC 7208 :用于授权在电子邮件中使用域的发件人策略框架 ( SPF ),版本 1
  4. RFC 8601 :用于指示消息认证状态的消息头字段
  5. RFC 9989 :基于域的消息身份验证、报告和一致性 ( DMARC )

[ 词汇表 ]

词汇表

可见的电子邮件签名
面向用户的内容,例如插入邮件中的联系方式或品牌,与DKIM-Signature头不同。
服务器端插入
提交后通过服务添加可见内容,而不仅仅是在撰写邮件应用程序中添加可见内容;实际放置取决于集成。
MIME表示
序列化的消息结构和编码部分可能与邮件应用程序直观显示的内容不同。
对齐的签名域
来自验证签名的DKIM d= 域,与适用DMARC模式下的作者域一致。
双插
一种工作流程,其中多个步骤添加可见签名内容,需要外观和身份验证审核。

企业出处

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

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

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

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

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

知识库