Hello Richard,
There is no b= in DKIM2
I was referring to my own implementation proposal; the i=1 Message-Instance body hash serves the same role. The logic is unchanged.
that's "local policy" ... go ahead
No. This is interoperability between nodes and coexistence with the protocols already deployed - the subject of this thread, not local policy. Local policy decides what a receiver tells its own users; it cannot decide whether two implementations interoperate across a path neither of them fully controls.
the DKIM2 spec says it should be rejected [...] then DKIM2 becomes useless
Recognisable DKIM2 failures are rejected - structural failure, proven dishonesty - in transit and at delivery alike. What passes is the ambiguous case: a failure that cannot be told apart from a break caused by a non-DKIM2 node - which, as you confirmed, is indistinguishable from the message alone. During coexistence, rejecting that case means rejecting every legitimate message that has crossed a legacy hop, in transit and not only at the final node, across the whole internet. That is not enforcement; it is the catastrophe.
DKIM2 does not become useless by letting the ambiguous case pass, flagged. It stays fully enforced against everything it can recognise and withholds rejection only where recognition is impossible, closing that gap as adoption rises, until full rejection is safe. The failure is declared, not hidden: a node states the outcome of its own verification, asserts nothing upstream and reconstructs nothing.
There is also adoption itself. An all-or-nothing rejection model is one a large receiver can hardly switch on, because the day it does, it rejects every legitimate message still crossing a legacy hop. A graduated model can be switched on early, in observation, and tightened as its own traffic becomes DKIM2, on the criterion you named, the proportion of mail that is DKIM2-signed. Gradual enforcement is not what weakens adoption; it is what makes adoption *possible*, because no receiver has to accept mass breakage on day one to begin.
Regards, Vittorio Moccia _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
