【问题标题】:Why would I choose simple over relaxed canonicalization for DKIM?为什么我会为 DKIM 选择简单而不是宽松的规范化?
【发布时间】:2011-12-28 19:25:33
【问题描述】:

DKIM 支持两种规范化方案:轻松和简单。前者更为宽松,允许中间邮件者在有限程度上修改电子邮件。

我能找到的唯一数据是survey of implementations,它显示绝大多数电子邮件发件人对标题和正文都使用了宽松的规范化。 (明显较少使用放松身体,但仍占绝对多数。)

DKIM 规范指出,如果所有客户端都支持 DKIM,则它们必须同时支持这两种规范化形式,因此这似乎不是主要因素。两种方案都允许中介添加标头。我能说的唯一区别是处理标题名称(不是值)和标题 within 的情况。鉴于此,放松似乎总是至少具有同样好的可交付性,这是 DKIM 的目标。

(当然,如果我想真正签署我的电子邮件以证明其内容,我会使用 S/MIME 和证书。DKIM 严格要求可交付性,对吧?)

【问题讨论】:

    标签: email dkim


    【解决方案1】:

    我认为简单的规范化可以作为发送者的一种选择,他们希望拥有一种计算密集度较低的签名方法,但可能会牺牲一些可交付性。复杂性上的差异并没有那么大,但对于大批量发件人来说可能会产生明显的差异。

    【讨论】:

      【解决方案2】:

      “良好的可交付性,这是 DKIM 的目标...DKIM 严格地讲可交付性,对吧?”

      你似乎有一个错误的前提。 DKIM 并不严格关注可交付性。 DKIM 的目的是验证发件人的身份DKIM RFC 解释得很好:

      DomainKeys Identified Mail (DKIM) 定义了域级别 使用公钥加密的电子邮件认证框架和 关键服务器技术,以允许验证来源和 邮件传输代理 (MTA) 或邮件的邮件内容 用户代理 (MUA)。

      DKIM 消息通常不会比未签名的消息更多或更少可传递。例如,SpamAssassin 为有效的 DKIM 签名消息和未签名消息给出相同的分数。如果消息未通过 DKIM 验证,那么正如您所料,它的得分会更差。

      DKIM 提供的是可靠地确定声称来自美国银行的消息是否真实的能力。如果它声称是这样,但消息中的 DKIM 签名验证失败,那么我可以知道该消息是伪造的,或者是被篡改的合法消息。无论哪种情况,都不应交付。

      现在,我是否想接收来自该 DKIM 认证域的消息,以及消息中的内容是否合乎需要是完全不同的问题,这对可传递性的影响比 DKIM 更深远。

      【讨论】:

      • 字,字,字,但这根本不能解决问题!
      • 尝试重新阅读原始帖子,看看是否还有您遗漏的问题。也许这是我的回答专门针对的问题。
      • 您对“可交付性”这个词持迂腐和无益的看法。从提问者明确意图的意义上说,它的意思是“让我的邮件不那么容易被拒绝为虚假/垃圾邮件/等”。这是通过签署它来证明发件人是谁来实现的。那么问题是,“轻松”还是“简单”对这个目标有影响。
      【解决方案3】:

      我认为差异与 CPU 负载没有太大关系 - 与通过 SMTP 生成、签名和发送消息所需的时间相比,差异将微不足道,无论如何您都必须这样做;没有逃脱阿姆达尔定律。

      relaxed 规范化的巨大回报在于稳健性。使用simple 规范化,最微小的差异,即使是不影响内容的差异,也可能导致验证失败。例如:

      • 使用 LF 而不是 CRLF 的邮件客户端(例如,Linux 上 PHP 的 mail() 函数)通过​​另一台服务器将它们转换为 CRLF(应该如此)。
      • 一个中间邮件服务器,将标头重新折叠到不同的行长度
      • 垃圾邮件过滤器,可更改邮件标题标签的大小写,例如Content-Type -> content-type.

      这些都不会导致relaxed 规范化的验证问题。所以我想说角度不是使用simple规范化节省你所做的,而是你从做relaxed规范化所需的额外工作中获得的优势,这就是它更受欢迎的原因。

      【讨论】:

        猜你喜欢
        • 2010-10-20
        • 2011-02-21
        • 2012-10-24
        • 1970-01-01
        • 1970-01-01
        • 2014-12-27
        • 1970-01-01
        • 2021-01-12
        • 1970-01-01
        相关资源
        最近更新 更多