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. William From: Vittorio <[email protected]> To: "Ietf Dkim"<[email protected]> Date: Mon, 12 Oct 2026 17:00:57 -0600 Subject: [Ietf-dkim] Re: BCP: operator note on header size limits and Message-Instance growth > John, William, > > I think William is right on one point of fact and wrong on what follows > from it. > Of the four fields, References and In-Reply-To are written by the MUA, > so John’s rebuttal holds for those. The other two are not the same. List > software commonly rewrites Reply-To to point replies at the list, and > List-Id is written by the list server by definition. A reader of those > fields may well guess that a list was involved and the rebuttal above > does not reach them. > > A guess is all it is. Neither field is part of what DKIM2 authenticates. > The signature at i=1 covers List-Id, but it attests only that the > signing domain presents a message containing it and every earlier > signature was removed by the re-origination, so nothing in the message > is signed by whoever wrote that field. The signal my draft says a > receiver does not have is the chain itself: the absence of a prior chain > distinguishes nothing and that remains true whatever the content headers > happen to say. > > This is why I think the note would not help and might do harm. A BCP > cannot make a heuristic normative and cannot stop one. What it can do is > give the pattern a name and a named pattern is one that policy can be > conditioned on. Nothing would ensure that operators condition on it in > the direction the proposal intends. Its own second consequence says > receivers have no signal by which to treat re-originators favourably, > while the text supplies the vocabulary for treating them unfavourably. > > 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. > > Regards > Vittorio Moccia > > > Il 2026-10-12 22:17 John R Levine ha scritto: > > On Mon, 12 Oct 2026, William Weiner wrote: > >> The difference from DKIM1 (your current times comparison) is the i= > >> counter. > >> In DKIM1 a signature says “we signed this.” In DKIM2 i=1 is also a > >> chain position > >> assertion: the verifier is told this is the first hop. A message with > >> References > >> and In-Reply-To headers is not incongruous with a DKIM1 signature; in > >> DKIM2 a > >> verifier following chain logic has legitimate grounds to ask why a > >> message > >> presenting as first-hop has headers that suggest otherwise. . > > > > Whenever I send a reply to a list message, such as this one, it has > > References and In-Reply-To headers. They're created by the MUA, not by > > list software. When I add DKIM2 signatures, the i=1 signature will > > sign those headers. I am aware of a lot of MUAs that add those > > headers, and no list software that does. I am baffled how anyone who'd > > ever looked at the headers on inbound or outbound list mail would > > imagine otherwise. > > > > Once again, there is nothing special about reorigination and no reason > > to say anything about ir. > > > > Regards, > > John Levine, [email protected], Taughannock Networks, Trumansburg NY > > Please consider the environment before reading this e-mail. > > https://jl.ly > _______________________________________________ > 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]
