PR, Taking that as an invitation to be specific.
dkim2wg/spec issue #2 (https://github.com/dkim2wg/spec/issues/2), filed in June, documents the same definitional gap. This proposal is intended to address it. Proposed addition to BCP Section 2 (Definitions), following the existing Forwarder and Reviser entries: Re-originating Intermediary: An intermediary that implements DKIM2, receives a message, terminates the inbound DKIM2 chain, and issues a new originating signature under its own domain and envelope address. Prior DKIM2 chain header fields are removed before signing; retaining them would present a newly originated message as the continuation of a chain that does not apply to it. Proposed addition near BCP Section 5.4, which already references a personal alias service in passing, or as a new subsection: A re-originating intermediary appears to the receiver as any other originating signer: a chain beginning at i=1 under its own domain, with no prior chain. A message re-originated in this way may nonetheless carry thread and context headers - References, In-Reply-To, Reply-To, List-Id and similar - that suggest the message is a reply or was distributed through a list server. This is not incongruous. Those headers describe the content of the message and its place in a conversation, not the origination path. A short DKIM2 chain alongside headers that indicate a longer handling history is the expected and correct output of re-origination. Two consequences follow. First, the absence of a prior DKIM2 chain must not be treated as a negative indicator, even when other message headers suggest the message passed through intermediary handling before re-origination. Second, receivers have no signal by which to extend preferential treatment to re-originating intermediaries as a class. It is evaluated as any other i=1 email would be based on the content and sender's reputation. The absence of a prior chain is consistent with re-origination and equally consistent with a message that was never part of a longer chain. Policy decisions conditioned on the presence or absence of a prior chain are not implementable for this reason. These two points are not separable: the first advises how receivers should not penalize the absence of a prior chain; the second limits what re-originators may claim in return. On documenting what the WG understands: email authentication has a pattern in which behavior that is clear to active participants but absent from adopted specifications tends to be filled by varied individual operator policies. These policies, without normative guidance, defaults to treating unfamiliar patterns as suspicious. The cost falls not on the operators who write the policy but on legitimate intermediary services and the users who depend on them. Thes inconsistencies reflect badly on the specification as well. Naming the behavior and stating its consequence in the BCP is how that outcome is avoided. Section 6.1.1 of draft-moccia-dkim2-deployment-profile contains the analysis underlying the terminology and accountability framing above. That analysis is the draft author’s work. The proposal to bring these consequences into the adopted BCP is this contribution alone; I am not speaking for the draft’s author. William Weiner From: Pete Resnick <[email protected]> To: "Vittorio"<[email protected]> Cc: "Ietf Dkim"<[email protected]> Date: Sun, 11 Oct 2026 14:04:05 -0600 Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and Message-Instance growth > Just on the process point: > > On 11 Oct 2026, at 13:43, Vittorio wrote: > > > 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. > > You and William are members of the WG. Nothing is going to happen > without a specific proposal. If you two think that there is text from > your draft (or something close to it) that should be added to the BCP, > please make a specific proposal about what to put in, and where. You > can't leave it to other participants or the document editors to divine > what part of your draft (which they may not be following) belongs in > some unspecified part of the BCP. Please make a specific proposal with > specific edits. > > pr > _______________________________________________ > 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]
