DKIM支持两种规范化方案:轻松规范化和简单规范化。前者更宽松，允许中间邮件发送者在有限程度上修改电子邮件。
我能找到的唯一数据是对实现的调查，显示绝大多数电子邮件发送者对标题和正文都使用宽松的规范化。(很明显，用relax来表示身体的人少了，但仍然是大多数。)
DKIM规范指出，如果支持DKIM，那么所有客户端都必须支持两种规范化形式，因此这似乎不是一个主要因素。这两种方案都允许中介体添加标头。我能说的唯一区别是在处理标题名称(不是值)和标题中的空白的情况。考虑到这一点，放松似乎总是具有至少同样好的可交付性，这是DKIM的目标。
(当然，如果我想真正签署我的电子邮件来证明它们的内容，我将使用S/MIME和证书。
我认为，对于那些希望拥有计算强度较低的签名方法的发送者来说，简单的规范化是一种选择，但可能会牺牲一些可交付性。复杂度上的差异并不大，但对于大量发送者来说可能会产生明显的差异。
"良好的交付性，这是DKIM的目标……DKIM严格讲的是可交付性，对吧?"
你似乎有一个错误的前提。DKIM并不是严格意义上的可交付性。DKIM的目的是验证发送方是谁。DKIM RFC解释得很好:
DomainKeys Identified Mail (DKIM)定义了域级别使用公钥加密的电子邮件身份验证框架密钥服务器技术允许验证源和邮件传输代理(mta)或邮件的内容用户代理(mua).
DKIM消息通常不会比未签名消息更容易传递。例如，SpamAssassin对有效DKIM签名的消息给出与未签名消息相同的分数。如果消息没有通过DKIM验证，那么正如您所期望的那样，它会得到一个更差的分数。
DKIM提供的是可靠地确定声称来自美国银行的消息是否真实的能力。如果它声称是这样，但是消息中的DKIM签名没有通过验证，那么我就可以知道该消息是伪造的，或者是被篡改的合法消息。无论哪种情况，它都不应该被交付。
现在，我是否想要从DKIM认证域接收消息，以及消息中的内容是否可取是完全不同的问题，这对可交付性的影响比DKIM要深远得多。
我不认为这种差异与CPU负载有多大关系——与生成、签名和通过SMTP发送消息所需的时间相比，这种差异是微不足道的，无论如何您都必须这样做;没有人能逃脱阿姆达尔定律。
relaxed规范化的最大回报是鲁棒性。对于simple规范化，非常微小的差异，即使不影响内容，也可能导致验证失败。例如:
- 使用LF而不是CRLF的邮件客户端(例如，Linux上PHP的
mail()函数)通过另一个服务器将它们转换为CRLF(正如它应该的那样)。 - 一个中间邮件服务器，它将标头重新折叠成不同的行长度
- 垃圾邮件过滤器，改变消息头标签的大小写，例如
Content-Type->content-type。
这些都不会导致relaxed规范化的验证问题。所以我想说的角度不是使用simple规范化为节省了什么，而是您从做relaxed规范化所需的额外工作中获得的优势，这就是为什么它更受欢迎。
简介:
我花了不少时间来分析"简单和""关于(2)项措施的规范化方法:
-
测量1:兼容性。交换邮件服务器以接收&比较以标准化格式呈现的数据，不需要"修正";收货后……
-
措施2:安全。该安全性不会因措施1的选择而降低到任何程度。
RFC 6376对放宽"给出了明确的指导。,简单的""依次为HEADER和BODY选择。
需要注意的是，对header或body格式的任何更改都是在提交签名之前进行的。
更重要的是，在考虑这个问题时，我们对哈希如何工作的理解是一致的:在发送邮件服务器签名后对消息的任何更改都会导致在接收邮件服务器测试时重新计算哈希，导致它失败。否则，如果后续更改不能更改哈希值，那么对消息进行签名就没有意义了。
标题:
RFC 6376 section 3.4明确指示:
3.4.1。简单的""标头规范化算法…不以任何方式改变报头字段。
然而，第3.4.2节是否对放宽"并规定在对消息进行签名之前如何以及以何种顺序进行格式化。
身体:
3.4.3……"simple"正文规范化算法转换"CRLF"
在正文的末尾添加一个"CRLF"
然而，再一次，放松"方法要求与"simple"方法，但会附加以下附加要求:
忽略行尾的所有空白。实现绝对不能删除行尾的CRLF。
将一行内的所有WSP序列减少为单个SP字符。
分析:
措施1:兼容性:
如果所有邮件服务器都使用"relax /relax 他们都可以期望收到带有正文和正文的标准化格式的邮件;头。我认为这是件"好事"。除非有人能提供RFC有缺陷的理由。
措施二安全性:
一旦消息被签名，并且发送者对消息头和/或正文的格式所做的任何更改都是在他们签署消息之前进行的，任何后续的修改都会导致哈希计算不同，并且在接收邮件服务器测试时不匹配。
因此,是否"放松"简单或""选择作为规范化方法，一旦消息离开发送者的邮件服务器，接收方或中间的任何转发邮件服务器对头和/或正文的任何更改都会导致哈希匹配失败。
现在消息传递的唯一方式"DKIM"验证将简单地忽略哈希值在离开发送方后发生的变化。
结论:
认为"放松"可以允许在签名并离开发送者的邮件服务器后更改的消息被误解:要么哈希匹配，要么不匹配。它不允许有任何差异:"或以其他方式。哈希正在被测试，这是一个二进制测试:是或否:比较哈希没有灰色阴影。
从RFC 6376来看，如果DKIM发送者都使用"relax /relax "，我们都将收到具有标准化、统一格式的消息，这在兼容性/互操作性方面似乎是一个很大的优势。由于在消息离开发送服务器后，在任何规范化方法下对消息的任何更改都应该无法通过测试，因此我可以看到使用"relax /relax "如果它增强了不同系统之间数据交换的一致性