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]
