On Thu, 27 Aug 2026, Vittorio wrote:
> Case one: intentional re-origination. [...] The absence of a prior
> chain is the normal state of any message entering DKIM2 for the first
> time and treating it as suspicious is not implementable in any case:
> the receiver has no reliable signal to act on.
The two-case separation is useful and I think correct. On Case 1, the "not
implementable" observation deserves more weight than it might appear.
The signals a receiver might reach for are all unreliable for this purpose.
Received headers are mutable, as you note. A long References chain tells the
receiver only that prior messages existed in a thread - not that any of them
passed through a domain that would have DKIM2-signed the current message.
Mailing-list-style headers are often absent from privacy relays by design;
their presence or absence is not a reliable indicator that a prior DKIM2 chain
should exist. None of these signals survives at scale without producing false
positives on ordinary mail.
If heuristics on these signals cannot reliably distinguish a legitimate
re-originator from a replay, that is also an argument that the BCP cannot defer
the question to receiver heuristics - which is what the current text does by
omission. A receiver following the BCP needs a positive statement: for
intentional re-originators, i=1 is the correct and expected state; evaluate the
i=1 signer's reputation directly. The re-originator takes full accountability
for the message it presents at i=1 - there is no prior chain to hide behind,
only its own domain reputation standing for what it delivers.
Without that, the "local policy" gap you named in your opening message is where
this lands.
Proposed definitional text for this is at GitHub Issue #2 on dkim2wg/spec,
filed June 2026 with no WG response to date:
https://github.com/dkim2wg/spec/issues/2
William Weiner
Weiner Advanced Development LLC / EMail Parrot (emparrot.com)
From: Vittorio <[email protected]>
To: "MCN-IETF"<[email protected]>, "Ietf Dkim"<[email protected]>
Date: Thu, 27 Aug 2026 14:59:17 -0600
Subject: [Ietf-dkim] Re: R: Re: Non-participating nodes in the chain: an
interoperability gap, not a local-policy question
> Hello Pietro,
>
> your questions are good and I think they become clearer once two cases
> that this thread has run together are separated, because they have
> different answers.
>
> Case one: intentional re-origination. An intermediary deliberately
> terminates the inbound chain, discards the prior DKIM2 headers and signs
> afresh as i=1. Here the loss of history is not a failure; it is the
> point. A privacy-preserving relay, an alias service, exists precisely to
> not carry the prior state forward. The resulting i=1 is
> indistinguishable from any other first-hop origination and that is
> correct, not a gap. The receiver does not need to recover the prior
> history, because responsibility attaches to the act of signing at i=1:
> whoever signs takes full accountability for the message they present,
> whether they composed it, generated it or admitted it from a DKIM1
> source.
> So to your question: i=1 does not assert 'the genuine origin of this
> message'; it asserts that whoever signs there takes responsibility from
> that point on. What preceded it is not represented because no one
> carried it forward and for this case that is the correct outcome, not a
> missing capability. The absence of a prior chain is the normal state of
> any message entering DKIM2 for the first time and treating it as
> suspicious is not implementable in any case: the receiver has no
> reliable signal to act on. Received headers are not one, they are
> mutable and vary legitimately in countless ways, so a heuristic built on
> them could reject a great deal of ordinary mail.
>
> Case two: a non-participating node in the path. This is the case I
> raised and it is a different situation. Here no one intentionally
> re-originates. A node that is not DKIM2-aware - a forwarder performing
> SRS, a list, a DLP gateway - alters the message in transit and breaks
> the chain without declaring anything, because by definition it cannot.
> There is no deliberate restart, only an incidental break. And here the
> receiver's position is genuinely different from case one: the failure it
> sees is indistinguishable from an attacker who altered the same content
> after signing. From the message alone, a legitimate legacy transit and a
> malicious alteration produce the identical signal.
> This is where a per-hop result record matters, and it is worth being
> precise about what it does and does not claim. It does not ask the
> receiver to trust an assertion about history: that was ARC's model and I
> understand the reservations about it. It makes a narrower statement: "at
> my hop, verification of the prior signature failed". That is an
> attestation a node makes about its own act of verification, not a claim
> about what some other party did upstream. The receiver need not believe
> anyone's account of the message's past; it only learns that the break
> was already present at a given hop. During the transition that is enough
> to do the one thing that matters: carry the message forward flagged
> rather than reject it blind, because the cause of the failure, a broken
> DKIM2 participant versus a legacy non-participant, cannot be determined
> from the message and rejecting on an undeterminable cause discards
> legitimate mail along with the rest.
>
> So to your underlying question - where does cryptographically verifiable
> history begin - it begins at i=1 in both cases. The difference is that
> in case one the absence of anything before i=1 is deliberate and
> unremarkable, while in case two something was there and was broken by a
> node that never participated and the receiver benefits from knowing that
> much, without needing to know more.
>
> Regards,
> Vittorio Moccia
>
> Il 2026-08-27 12:32 MCN-IETF ha scritto:
> > Hi,
> >
> > As I understand the recent discussion, if an intermediary receives a
> > message for which the existing DKIM2 chain can no longer be continued,
> > it may remove the previous DKIM2 information and start a new chain with
> > m=1, i=1.
> > If that is correct, I am wondering what the final receiver can actually
> > know about the history before the new i=1.
> >
> > For example:
> >
> > A (i=1) -> B (i=2) -> legacy intermediary -> C
> > |
> > DKIM2 chain lost
> >
> > C -> new DKIM2 chain (i=1) -> D -> Receiver
> >
> > When the Receiver verifies the second chain, can it determine in any
> > way that this message previously had a DKIM2 chain which was
> > interrupted or discarded?
> > Or, from the Receiver's point of view, is this indistinguishable from a
> > message whose DKIM2 history genuinely started at C?
> > In other words, does i=1 only mean:
> >
> > "this is the beginning of the DKIM2 chain that I can verify"
> >
> > rather than:
> >
> > "this is the original DKIM2 origin of this message"?
> >
> > If the previous chain is completely removed, I assume the Receiver
> > cannot distinguish between a legitimate restart after a legacy
> > intermediary and someone simply removing an existing DKIM2 chain and
> > starting a new one. Is that correct?
> > There is also a related identity question. If a DKIM2 intermediary
> > discards an existing chain and starts a new one at i=1, what
> > authenticated identity, if any, can a Receiver associate with the
> > original message, as opposed to the identity represented by the new i=1
> > signer?
> > I am mainly trying to understand exactly where the cryptographically
> > verifiable history starts and, equally importantly, whether DKIM2 gives
> > the Receiver any indication that some history existed before that
> > point.
> >
> > Best,
> > Pietro Mauri
> >
> > -----Messaggio originale-----
> > Da: William Weiner <[email protected]>
> > Inviato: giovedì 27 agosto 2026 00:36
> > A: vmoccia <[email protected]>
> > Cc: Ietf Dkim <[email protected]>
> > Oggetto: [Ietf-dkim] Re: Non-participating nodes in the chain: an
> > interoperability gap, not a local-policy question
> >
> > On Wed, 26 Aug 2026, Vittorio wrote:
> >
> >> [...] Delegating that to local policy does not resolve the
> >> interoperability question; it declares that the specification will not
> >> address it.
> >
> > The point about layer is well-stated. Local policy cannot govern
> > whether two implementations interoperate across a path they do not both
> > control.
> >
> > Re-originating services are a related sub-case worth naming alongside
> > the non-participating-node case. Unlike a non-participating node that
> > breaks the chain incidentally, a re-originator - alias service,
> > privacy-preserving mailing list, and similar - terminates the inbound
> > message and originates a new one intentionally. The result at the final
> > receiver is the same: a valid single-hop DKIM2 signature with no prior
> > chain. From the message alone, the receiver cannot distinguish
> > legitimate re-origination from a stripped one.
> >
> > The "I dunno" third state you and Bron describe is the right shape for
> > both cases. What is missing from the BCP is the definition that tells a
> > receiver when "I dunno" is the correct verdict for a legitimate reason,
> > versus when it should be treated as suspicious. Without that
> > definition, local policy fills the gap - which, as you note, is the
> > wrong layer.
> >
> > Proposed definitional text for the re-originator case is at GitHub
> > Issue #2 on dkim2wg/spec, filed June 2026 with no WG response to date:
> >
> >
> > https://urlsand.esvalabs.com/?u=https%3A%2F%2Fgithub.com%2Fdkim2wg%2Fspec%2Fissues%2F2&e=b336b1a5&h=32f539b0&f=n&p=y&m=4hVfdD47YfzH1pc
> >
> >
> > William Weiner
> > Weiner Advanced Development LLC / EMail Parrot (emparrot.com)
> >
> >
> >
>
> _______________________________________________
> 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]
