Hi Vittorio, That is well said and a good example of the value that DKIM2 is adding! I don't think that changes the risk from a targeted phishing perspective since similar to ARC you don't know anything for certain about what the original content was. But I agree knowing cryptographically the path the mail took absolutely reduces the risk of spam and provides much stronger ingredients for a risk engine to make improved decisions and track reputation on.
Just to spell out the scale example for spam that it prevents because I think it is useful to have specific scenarios to discuss: 1) attacker receives a UPS.com email. 2) They rewrite the content to spam and auto-forward it to 1000 different servers, each with a different domain. 3) Each of those servers then auto-forwards 1000 different copies to their spam lists. Those will all be DKIM2 passing with NULL_PASS. It is relatively easy to see the suspicious paths since you know the path taken and can model which domains / pairs are suspicious or benign (and all messages have the same messageId). But there are still pitfalls and it is critical that the spam system does not mix statistics from NULL_PASS and PASS. Best, Emanuel On Thu, Apr 30, 2026 at 1:22 PM Vittorio <[email protected]> wrote: > Hello Emanuel, > > the PASS / MODIFIED_PASS / NULL_PASS taxonomy is useful, but the > equivalence between NULL_PASS and ARC pass requires a qualification. > > ARC pass establishes that a chain of intermediaries asserts the message > was authenticated at the origin. It does not bind the SMTP envelope > cryptographically. MAIL FROM can change along the path without breaking > the chain. The message can be replayed to arbitrary recipients. There is > no way to verify that the envelope at any hop corresponds to what the > previous hop actually transmitted. > > DKIM2 NULL_PASS with envelope binding is fundamentally stronger. Without > a body recipe, mf= binds MAIL FROM to d= at each hop and rt= binds RCPT > TO to the signing domain. The message cannot be replayed to different > recipients because rt= would not match. The envelope sender cannot be > changed without breaking the signature. You lose visibility into what > changed in the body (not useful for delivery decisions), but you retain > cryptographic proof of who handled the message, where it was supposed to > go and where it came from at every hop. > This is the difference between a chain of assertions (ARC) and a chain > of cryptographic bindings (DKIM2 with envelope binding). These > properties alone represent a qualitative advance over ARC that should > not be conflated with it. > > Regards > Vittorio Moccia > > Il 2026-04-30 20:14 Emanuel Schorsch ha scritto: > > Thanks Todd and Wei for some interesting thoughts! > > > > To start with some clarifications and terms. > > > > RFC5322.From: > > As far as I can see DKIM2 says nothing about the RFC5322.From which > > seems like an omission if the intention is to replace DMARC. Todd, > > where do you envision the guidance and policies around RFC5322.From > > sitting in the long term future? > > > > DKIM1 vs DKIM2 pass semantics: > > DKIM1 pass has clear semantics for a pass, the message content is > > unmodified from the original message. This is more ambiguous in the > > DKIM2 world. It can mean: > > 1) Content is unmodified. Chain of custody is just added. > > 2) Content has reversible modifications that are recorded and can be > > verified. > > 3) Null recipe. Equivalent to an ARC pass today where all you can > > verify is the most recent hop and the rest is that hop's assertion. > > > > I think it is important that these are clearly recorded as different > > and that we have consistent terms to refer to them. The idea that 2 > > and 3 are equally a pass as 1 is makes me hesitant and concerned. I'm > > bad at naming but for the sake of this email I'll call them PASS, > > MODIFIED_PASS, NULL_PASS. > [...] > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
