DKIM2

Deliverability Case Study: "DKIM2"

Ali G(mail) returns to do something genuinely mad: rap an entire IETF Internet-Draft. This track is a verse-by-verse walkthrough of draft-ietf-dkim-dkim2-spec, the DKIM working group's proposal to rebuild email authentication around a per-hop signed chain of custody. As the intro admits, it is "still a draft, innit" — DKIM2 is an active work in progress and details may change before it becomes an RFC. Everything below reflects the draft as written at the time of recording.

Here is the technical breakdown of the deliverability concepts detailed in the song:

Verse 1: Why DKIM1 Needed a Sequel

"Add a footer to da body? Dat's your body hash / Touch da subject line? Header hash crash / Legit mail get binned in wid da trash"

• The Deliverability Context: DKIM (DomainKeys Identified Mail), defined in RFC 6376 — the "six-three-seven-six" of the opening bar — signs a hash of the message body and selected headers. That design is brittle in transit: a mailing list that appends an unsubscribe footer breaks the body hash, and one that prepends a [list-name] tag to the Subject breaks the header hash. Perfectly legitimate mail then arrives with a failed signature and, under a strict DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy, gets "binned in wid da trash."
• The Patch That Wasn't Enough: ARC (Authenticated Received Chain, RFC 8617) — the "arc turn up sayin' 'trust me, it was nice'" cameo — lets an intermediary assert what the authentication results were before it modified the message. But ARC is an Experimental RFC and fundamentally asks the receiver to trust the forwarder's word. "Experiment concluded" is the draft's verdict: DKIM2 replaces trust assertions with proof. Any hop that changes the message content or the envelope must sign what it did; only a fully transparent relay that changes nothing gets to skip adding its own signature.

Verse 2: The Chain of Custody and the Replay Contract

"Da live envelope gotta match da top one exact / Local part and all, dat's da replay contract"

• The Deliverability Context: Each hop adds a numbered DKIM2-Signature header field. The originator signs with i=1, and every subsequent handler adds a signature numbered one higher — "da numbers never stop." Each signature records the SMTP envelope it used: mf= carries the base64-encoded MAIL FROM and rt= the RCPT TO addresses, angle brackets included. The chorus's mandatory-tag roll call is straight from the spec: i=, m=, t=, d=, and s= MUST be present, plus either nd= or the mf=/rt= pair.
• The Replay Defense: This is the tag team that kills DKIM replay attacks. Under DKIM1, a spammer can take one legitimately signed message and blast it to a million new recipients — the signature still verifies, because DKIM1 never signed the envelope. Under DKIM2, a verifier MUST check that the live SMTP envelope exactly matches the mf= and rt= values in the highest-numbered signature — "local part and all." A replayed message either fails verification or carries the replayer's own signature in the chain, leaving the trail the chorus promises. The two bars before that describe the hop-to-hop check, which is looser by design: each signature's rt= must connect to the next signature's mf= — "last man's 'r-t' gotta carry da next man's 'm-f'" — but for these chain matches only the domain part is compared; the local part and the @ are ignored. The comparison uses the spec's relaxed domain match, stripping labels one at a time from the left until the names align, and the verifier applies the same relaxed match between each signature's d= domain and its mf= value. So: domain-only along the chain, exact match at the live edge.
• The Handoff: nd= ("next domain") covers the case where a system receives mail on one domain and re-emits it from another — an alias or forwarding service. When nd= is present, mf= and rt= are omitted, and the next signature in the chain MUST be signed by the named domain, or, as Ali puts it, "da chain go bare."

Verse 3: Message-Instance and the Reviser's Recipe

"You is a Reviser — 'r' hold da recipe / JSON, base sixty-four, tell 'em what it used to be"

• The Deliverability Context: The second new header field, Message-Instance, carries m= (the instance number) and h= (the hashes, formatted sha256:headerhash:bodyhash — exactly the "header hash, colon, body hash" mix in the lyric). A forwarder that changes nothing lets the existing hashes stand. One that modifies the message becomes a Reviser: it adds a new Message-Instance with new hashes and an r= tag holding a base64-encoded JSON recipe describing how to reverse its changes, so any later verifier can reconstruct the earlier instance and re-verify the earlier signatures.
• The Recipe Format: In the reversal data, c operations copy existing lines and d operations insert literal text — and the counting really is "opposite style": header field instances are numbered bottom-up while body lines are numbered top-down. If a hop mangles the body irreversibly (say, a lossy MIME re-encoding), it records a null instead of a body recipe — "put a null, own it" — which breaks re-verification of earlier hops but keeps the modification honestly declared.

Verse 4: What Gets Counted, and the Two Canonicalizations

"Cos da signature only sign da DKIM2 line / Everyting else ride inside da hash — dat's da design"

• The Deliverability Context: The header hash deliberately ignores fields that legitimately change in transit: trace fields (Received, Return-Path), locally-added fields (Delivered-To, Authentication-Results), old authentication artifacts (DKIM-Signature, anything starting ARC-), and anything starting X-. The DKIM2 fields themselves (Message-Instance, DKIM2-Signature) are also excluded from the header hash because they are signed separately — "don't count nuffink twice."
• The Two Canonicalizations: The verse correctly distinguishes them. The header-hash canonicalization lowercases field names, unfolds continuation lines, collapses whitespace runs to a single space, and sorts fields alphabetically ("A to Zed"). The signature canonicalization is stricter — it deletes all whitespace. The elegant part is the closing couplet: the cryptographic signature covers only the Message-Instance and DKIM2-Signature fields themselves. Since those fields contain the header and body hashes, the signature transitively covers the whole message — "everyting else ride inside da hash."
• A Side Effect Worth Noting: because DKIM-Signature and ARC-* fields are ignored entirely, DKIM1 and DKIM2 coexist peacefully on the same message. The outro's deployment advice — "run bofe, innit" — is exactly right for a transition period.

Bridge: Crypto and the Anti-Versioning Stance

"Ain't no 'v equals' — version numbers weren't heaven"

• The Deliverability Context: Hashing is SHA-256; verifiers MUST implement both RSA-SHA256 and Ed25519-SHA256. Public keys live where DKIM1 keys always have: a DNS TXT record at selector.domainkey.domain. One small precision note on the RSA bar: the draft says signers MUST use RSA keys of at least_ 1024 bits (with a public exponent of 65537) — 1024 is the floor, not the recommendation, and 2048-bit keys remain the sensible default.
• The Versioning Lesson: DKIM1's v= tag turned out to be dead weight — you cannot smoothly version a protocol whose old verifiers reject what they don't understand. The draft's answer: no version tag at all. If an incompatible change is ever needed, the header fields will simply be named DKIM3. "Dat's how it go."

Verse 5: Timestamps, Nonces, and Flags

"Ignore da request cos your policy say so? Fine — / But dat copy never leave your house. Dat's da line."

• The Deliverability Context: t= is a Unix timestamp ("seconds since seventy"), and verifiers should fail signatures more than 14 days old — hence "dat's a drop, generally." n= is an opaque nonce of at most 64 characters that only means something to the domain that signed it. The f= flags are all real: exploded (informational — this went to multiple recipients, e.g. a mailing list), donotmodify, donotexplode (requests), and feedback/feedhere (asking for delivery feedback, routed back through this hop).
• The Enforcement Line: The closing bars capture the draft's cleverest rule. A receiver may override a donotmodify or donotexplode request as local policy — but a system that does so MUST NOT forward the message on to any MTA (Mail Transfer Agent) outside its own administrative control. Modify it and it stays inside your house.

Verse 6: Bounces That Go Home

"No more backscatter on a geezer who never knew"

• The Deliverability Context: This verse is the operational payoff. DKIM2 reroutes DSNs (Delivery Status Notifications, i.e. bounces) one hop backwards — to the mf= address of the MTA that handed you the message — instead of firing them at whatever address sits in the Return-Path. If mf= is the null reverse path (<>), no DSN is sent at all. That structurally eliminates backscatter: the misdirected bounce spam innocent people receive when spammers forge their address as the sender.
• The Four Verdicts and the SMTP Discipline: Verification yields PASS, FAIL, PERMERROR, or TEMPERROR — "dem is da four." When an inbound message fails its checks, no DSN may be generated afterwards; an MTA that wants to reject should do it with a 550/5.7.x reply while the SMTP session is still open. A temporary failure to fetch the key gets a 451/4.7.5 so the sender retries — but a cryptographic verification failure must never draw a 4xx, because retrying won't fix bad math. "Crypto fail? Dat's done."