On Wed, 26 Aug 2026, Vittorio wrote: > [...] Delegating that to local policy does not resolve the interoperability > question; it declares that the specification will not address it.
The point about layer is well-stated. Local policy cannot govern whether two implementations interoperate across a path they do not both control. Re-originating services are a related sub-case worth naming alongside the non-participating-node case. Unlike a non-participating node that breaks the chain incidentally, a re-originator - alias service, privacy-preserving mailing list, and similar - terminates the inbound message and originates a new one intentionally. The result at the final receiver is the same: a valid single-hop DKIM2 signature with no prior chain. From the message alone, the receiver cannot distinguish legitimate re-origination from a stripped one. The "I dunno" third state you and Bron describe is the right shape for both cases. What is missing from the BCP is the definition that tells a receiver when "I dunno" is the correct verdict for a legitimate reason, versus when it should be treated as suspicious. Without that definition, local policy fills the gap - which, as you note, is the wrong layer. Proposed definitional text for the re-originator case is at GitHub Issue #2 on dkim2wg/spec, filed June 2026 with no WG response to date: https://github.com/dkim2wg/spec/issues/2 William Weiner Weiner Advanced Development LLC / EMail Parrot (emparrot.com) > From: Vittorio <[email protected]> > To: "Ietf Dkim"<[email protected]> > Date: Wed, 26 Aug 2026 08:15:29 -0600 > Subject: [Ietf-dkim] Non-participating nodes in the chain: an > interoperability gap, not a local-policy question > > Hello. > > The chain-of-custody model in draft-05 shares a property with any DKIM2 > design built on the same foundation: it assumes the modifying parties on > a path participate in the chain. Section 7 addresses the transparent > case explicitly - an MTA that changes nothing "need not be made DKIM2 > aware." That is correct and welcome. What is not addressed is the other > case: a node that is not DKIM2-aware and does modify the message - a > list rewriting a Subject and appending a footer, a gateway altering the > body. This breaks the chain and it is not an edge case; during > coexistence it is the common case, for as long as any non-participating > node sits on ordinary delivery paths. > > When this was raised earlier, the response was that such a message falls > to local policy. I want to be precise about why that answer does not fit > the problem. Local policy governs what a receiver does with a message - > accept, reject, flag. It cannot govern whether two implementations > interoperate across a path that includes a node neither of them > controls. A chain broken by a non-participating node produces, at the > next hop, a verification failure whose cause cannot be determined from > the message alone: it is indistinguishable from an attacker who altered > the same content after signing. Delegating that to local policy does not > resolve the interoperability question; it declares that the > specification will not address it. For a problem that is, at its root, > about interoperability during a multi-year transition, that is the wrong > layer to leave it at. > > Bron has just raised the adjacent case - a signature that verifies but > uses an algorithm a downstream verifier does not understand - and asked > for a way to signal that failure explicitly rather than let mail > disappear silently. John's reply already sketches the shape of the > answer: a feedback mechanism reporting, per signature, "good, bad, or I > dunno." The non-participating-node case is the same shape in a more > severe form and it needs exactly that third value. When a prior seal is > broken by a node that never entered the chain, the downstream hop cannot > determine the cause from the message alone - "I dunno" is the honest and > only correct verdict - yet it still needs to record that the break > predates its own handling and carry the message forward flagged, rather > than reject it blind or accept it without record. The mechanism Bron and > John are converging on for the algorithm case answers this one too. > > I raise this now because draft-05 has closed several open points but not > this one and because it is structural: it sits in the foundation both > the base specification and any conforming profile share, not in any > optional layer where the two differ. > > Regards, > Vittorio Moccia > > _______________________________________________ > 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]
