Mail systems rewrap headers, change case and adjust whitespace as a matter of course, and none of it alters the message a human reads. Canonicalisation is the rule that decides whether those changes destroy a signature. c= names two algorithms, one for headers and one for the body.
Header canonicalisation
| simple | relaxed | |
|---|---|---|
| Header names | Unchanged | Lowercased |
| Whitespace within a value | Unchanged | Runs collapsed to one space |
| Leading/trailing whitespace | Unchanged | Removed |
| Folding (line continuation) | Unchanged | Unfolded to a single line |
simple tolerates nothing at all. A single mail server that unfolds a long Subject line — an entirely legitimate thing to do — invalidates the signature.
Body canonicalisation
| simple | relaxed | |
|---|---|---|
| Trailing whitespace on a line | Significant | Removed |
| Runs of whitespace within a line | Significant | Collapsed to one space |
| Empty lines at the end of the body | All but one removed | All removed |
| Everything else | Byte-exact | Byte-exact |
Note what both treat as significant: every non-whitespace byte. Neither canonicalisation forgives a footer, a rewritten link, a changed character encoding or an inserted disclaimer. Relaxed buys tolerance of whitespace, and nothing more.
Which to use
c=relaxed/relaxed headers relaxed, body relaxed <- use this c=relaxed/simple headers relaxed, body byte-exact c=simple/simple both byte-exact <- the default, per RFC c=simple/relaxed headers byte-exact, body relaxed
RFC 6376 §3.4 makes simple/simple the default when c= is absent, which is a specification decision rather than an operational recommendation. Real signers overwhelmingly set relaxed/relaxed, and should: it survives the normal handling of mail without weakening what the signature actually protects.
The l= tag, and why not
l= signs only the first N octets of the body, so anything appended afterwards does not break the hash. It exists to tolerate mailing-list footers.
- It also lets anyone append arbitrary content to a validly signed message — including a complete second message, visible to the reader and covered by your signature.
- The content that survives verification is the part a reader is least likely to have scrolled to.
Do not publish l=
It converts a signature that authenticates a message into one that authenticates a prefix. If footers are the problem, the answer is ARC-aware receivers and lists that rewrite the From header — not a signature that stops covering the body halfway down.