Vittorio, Both points are well taken and I accept them. The combination is not specific to re-origination during transition, and narrowing the sentence to a named category would reintroduce the heuristic dependency it is meant to remove. I should not have framed it that way.
The general principle as you have stated it - that absence of a prior chain must not be treated as a negative indicator for an i=1 signature, whoever produced it - is the right language and I support seeing it in adopted text. I was not at the September meeting and do not have full visibility on where things stand or what you have in mind for this language. Is there a way I can usefully support your proposal beyond the statement above? William From: Vittorio <[email protected]> To: "Ietf Dkim"<[email protected]> Date: Tue, 13 Oct 2026 04:57:17 -0600 Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and Message-Instance growth > Hello William, > > Two things. > > The combination is not specific to re-origination. During the transition > a message can cross a list that does not implement DKIM2, which adds the > RFC 2369 headers and signs nothing, and then reach a DKIM2 signer that > admits it into a chain at i=1. The end receiver sees the same thing: the > full list header set, signed at i=1, with no prior chain. My draft makes > that point in its accountability section, where a signer that introduces > previously unsigned or DKIM1-only mail is indistinguishable from any > other i=1 signer. It will not become specific later either, since > full-path participation is never guaranteed. > > On the sentence itself, its value lies precisely in its generality: the > absence of a prior chain does not permit a decision about an i=1 > signature, whoever produced it. I would not write it as a provision > concerning re-originating intermediaries, because that narrows it to one > category of sender. A category is something the receiver would have to > identify and it can do so only by heuristic means. That framing would > reintroduce the very dependency the sentence exists to remove. So I > would not mention the re-origination mechanism at all. It is one case > among the wider set that i=1 covers, and that is the reason I have not > suggested a change. > > Regards, > Vittorio Moccia > > > Il 2026-10-13 01:59 William Weiner ha scritto: > > Vittorio, John, > > > > This exchange has sharpened the argument and I think it lands somewhere > > useful. > > > > John is right on References and In-Reply-To - those are MUA-generated > > and appear on any reply. I should not have included them in the > > original framing. > > > > Vittorio is right that List-Id is different: it is written by the list > > server, along with the family of RFC 2369 headers - List-Unsubscribe, > > List-Post, List-Archive, and the rest - none of which a MUA produces. > > In a DKIM2-aware deployment, a list functioning as a Reviser adds its > > own chain entry, and the receiver sees those headers covered by the > > list domain at i=2. A re-originator receiving that same list-processed > > message terminates the chain before forwarding. What arrives at the end > > receiver is a message carrying the full RFC 2369 header set - signed at > > i=1 by the re-originator. That combination is specific to > > re-origination in a DKIM2 deployment and is not produced by an > > individual reply. > > > > Vittorio then makes the point that matters most: “the one sentence that > > does operate, that the absence of a prior chain must not be treated as > > a negative indicator, needs none of this. It applies to every i=1 > > signature, whoever produced it.” That is correct. It is also the > > sentence that exists in Vittorio’s individual draft and not in BCP-01. > > The proposal is simply to move that protection into the adopted > > document, with whatever minimum framing it requires to stand on its > > own. > > > _______________________________________________ > 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]
