Hello William,
on where that language belongs I will leave the judgement to the working
group. My draft is an individual submission and it makes the argument in
the place available to it. Whether the BCP should carry an equivalent
statement, and in what terms, is a question for the people editing it.
Two scopes are worth keeping in view if it goes that way, so that the
statement does not carry more than it does.
The sentence you are citing is bounded to enforcement policy: the
absence of a prior chain must not be treated as a negative indicator
there. It does not oblige a receiver to accept anything. DKIM1, DMARC,
reputation, content and local policy are untouched. A message whose
chain begins at the current hop can still be refused on any of those
grounds. What the signature at i=1 establishes is accountability of the
signing domain, not that the message is wanted.
The same paragraph states the other half: requests for special receiver
treatment of re-originating services, such as a normative preference
based on the absence of a prior chain, are not implementable, because
the receiver has no signal to act on. I would want both halves to travel
together wherever that language goes.
Regards,
Vittorio Moccia
Il 2026-10-11 01:07 William Weiner ha scritto:
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
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
