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]
