Why would I choose simple over relaxed canonicalization for DKIM?

Question

DKIM supports two canonicalization schemes: relaxed and simple. The former is more lenient and allows for intermediary mailers to modify the email to a limited degree.

The only data I could find is a survey of implementations that shows the vast majority of email senders using relaxed canonicalization both for headers and body. (Noticeable fewer use relaxed for the body, but it's still a definite majority.)

The DKIM specification says that all clients have to support both canonicalization forms if they support DKIM, so that doesn't seem like a major factor. Both schemes allow intermediaries to add headers. The only distinction I can tell is in the handling of the case of header names (not values) and the whitespace within a header. Given that, it seems like relaxed will always have at least as good deliverability, which is the aim of DKIM.

(Of course, if I want to actually sign my emails to attest to their contents, I'd use S/MIME and certificates. DKIM is strictly about deliverability, right?)

Answer 1

I suppose that simple canonicalization is available as a choice for senders who wish to have a less computationally intensive signing method, at the possible cost of some deliverability. The difference in complexity isn't that much, but it might make an appreciable difference for large bulk senders.

Answer 2

I don't think the difference has much to do with CPU load – the differences will insignificant compared to the time required to generate, sign, and send a message over SMTP, which you're going to have to do anyway; there's no escaping Amdahl's law.

The big payoff for relaxed canonicalization is in robustness. With simple canonicalization, the very tiniest difference, even ones which do not affect the contents, can cause validation to fail. For example:

• A mail client that uses LF instead of CRLF (e.g. as PHP's mail() function on Linux does) goes through another server that converts them to CRLF (as it should).
• An intermediate mail server which re-folds headers to a different line length
• A spam filter that changes the case of a message header label, e.g. Content-Type -> content-type.

None of these will cause validation problems with relaxed canonicalization. So I'd say the angle is not what using simple canonicalization saves you from doing, it's what advantages you gain from doing the additional work required by relaxed canonicalization, and that's why it is more popular.

Answer 3

"good deliverability, which is the aim of DKIM...DKIM is strictly about deliverability, right?"

You seem to have a faulty premise. DKIM is not strictly about deliverability. The purpose of DKIM is to authenticate who a sender is. The DKIM RFC explains it quite well:

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs).

A DKIM message is generally no more or less deliverable than an unsigned message. For example, SpamAssassin gives a message an identical score for a valid DKIM signed message as for an unsigned message. If the message fails DKIM validation, then as you'd expect, it gets a worse score.

What DKIM provides is the ability to reliably determine if a message purporting to be from Bank of America truly is. If it claims so, but the DKIM signature in the message fails validation, then I can know the message is a forgery, or a legit message that's been tampered with. In either case, it should not be delivered.

Now, whether or not I want to receive messages from that DKIM authenticated domain, and whether or not the content in the message is desirable is a whole different issue, and that has a much more profound impact upon deliverability than DKIM.