Vittorio, Thank you for the clarification - the three non-participating cases mapped against the re-originating intermediary makes the distinction cleaner than anything I had in mind.
I looked at Section 6.1.1 of your deployment profile draft. It covers the behavior accurately and the accountability consequence you state there - that the absence of a prior chain must not be treated as a negative indicator - is exactly the language that is missing from the WG-adopted documents. The BCP terminology section still names only Originator, Forwarder, Reviser, and Receiver. Your draft has the analysis; the BCP has the standing. I am glad the data was useful. William Weiner From: Vittorio <[email protected]> To: "Ietf Dkim"<[email protected]> Date: Sat, 10 Oct 2026 10:41:29 -0600 Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and Message-Instance growth > Hello William, > > Thanks for the figures. On the terminology question: in my draft a > non-participating node and a re-originating intermediary are different > things and non-participation itself divides into three cases that behave > differently. > > A node that does not participate in DKIM2 divides by what its passage > leaves behind and the divisions behave differently. > > One neither modifies the message nor alters the envelope. It leaves > nothing to see and the chain is unaffected. > > One modifies the message or rewrites the recipient and leaves no account > of it and no name. The chain fails at the hop that signed before it, the > node that caused the failure is not identified and nothing in the > message distinguishes it from an attacker. That is the case of an > antivirus engine, a DLP system, an encryption gateway or a content > filter that alters a message in transit while participating in no > authentication protocol. > > One modifies the message and is identifiable from it all the same, > because it adds a DKIM1 signature, an ARC set, List fields or a Received > field that names it. The chain fails just as it does above, but here the > failure can be localised by inspection instead of by inference. Your own > corpus measures that population: the 64 per cent carrying two > DKIM-Signature fields and the 46 per cent carrying an ARC hop are, for > DKIM2 purposes, non-participating nodes that left their names behind. > Section 5.3 covers this case and the one before it. > > A re-originating intermediary is none of those. It implements DKIM2 and > terminates the inbound chain deliberately, signing as a new i=1 under > its own domain and envelope. Section 5.3 states that a DKIM2-aware > intermediary that modifies a message is never a legacy node in that > sense, and that it must either declare its modifications or > re-originate. The behaviour you describe is Section 6.1.1, > re-origination by a privacy-preserving intermediary. It requires > removing all prior DKIM2 header fields before signing as the new i=1, > since retaining any of them would present a newly originated message as > the continuation of a chain that no longer applies, and it states the > accountability consequence: such a signer is indistinguishable from any > other first hop originator and a receiver has no signal to tell them > apart. The absence of a prior chain must not be treated as a negative > indicator. > The topology side of this is expanded in the revision I'm preparing. > > On the data, your figures bear on chain growth from a direction this > thread had not covered: re-origination truncates accumulation instead of > adding to it and it is the only behaviour discussed so far that does. > > Regards > Vittorio Moccia > > Il 2026-10-08 22:19 William Weiner ha scritto: > > A data point from the perspective of an operating re-originating relay > > - a service that rewrites the recipient address, terminates the inbound > > signing chain, and issues a fresh originating DKIM signature outbound > > rather than extending the chain. > > > > On a corpus of 6186 inbound messages: header section size at the 50th > > percentile is 5630 octets, 90th 11420, 99th 16821. 35% of messages > > arrive above 8KB. 64% carry 2 DKIM-Signature fields on arrival; 46% > > carry at least one ARC-Seal hop. In a DKIM2 deployment that overhead > > does not pass through - the relay re-originates from a clean slate. > > > > Re-orgininator behavior has come up in the archive under various > > descriptions - “re-originator,” “alias service,” Vittorio’s > > “non-participating node” framing, the BCP’s own “personal alias > > service” mention in Section 5.4 - but the terminology section names > > only Originator, Forwarder, Reviser, and Receiver. Whether that gap > > matters for a BCP note on chain growth is a question. However, the > > concept appears to be in active use, it just does not yet have a > > name/definition. > > > > William Weiner > > > > > > > > From: Vittorio <[email protected]> > > To: "Ietf Dkim"<[email protected]> > > Date: Wed, 07 Oct 2026 06:13:58 -0600 > > Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and > > Message-Instance growth > > > _______________________________________________ > 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]
