Pietro's reading is correct: EMail Parrot and similar services start a new
DKIM2 chain at i=1, and the spec handles that cleanly. No new protocol
mechanism is needed. The BCP question is narrower - whether receivers should
have normative guidance on evaluating that pattern as the category grows.
Mailing list managers currently performing From-munging (Mailman, Google
Groups, and similar) are already doing this at scale across tens of thousands
of lists - a direct legacy of the last time this class of service was left to
local policy. Privacy relays that strip tracking content before forwarding are
a more recent addition to the same broad category of privacy-preserving
intermediaries. These are not exotic edge cases; they are deployed today and
the pattern is expanding.
The DMARC parallel is the direct precedent - and the lesson is not that Yahoo
acted in bad faith. Yahoo was getting hammered with spoofed @yahoo.com phishing
and p=reject was the only tool the spec gave them. The BCP had not defined a
compliant path for mailing lists, so Yahoo had no option that protected their
users without breaking lists. They chose their users. From-munging has been the
workaround ever since. Better BCP guidance would have given both Yahoo and
lists a path forward. That is what is being proposed here for the next category
of intermediary before deployment forces the same choice.
If the answer is obvious, one sentence in the BCP costs nothing. If a future
receiver policy author reads Section 11.4's chain-of-custody language and
concludes that chain absence is a verification gap, the normative text is what
forecloses that reading before it hardens.
William Weiner
Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com)
From: MCN-IETF <[email protected]>
To: "Wei Chuang"<[email protected]>,
"IETF"<[email protected]>
Cc: "ietf-dkim"<[email protected]>, "Tobias
Herkula"<[email protected]>
Date: Mon, 27 Jul 2026 02:36:50 -0600
Subject: [Ietf-dkim] R: Re: R: Another question: introducing DKIM2 for
non-DKIM2 originators
Hi all,
After following the recent discussions on originators, re-originators and the
proposed f=reorigin flag, I realized that my understanding of the DKIM2 trust
model may have been
different from what is now being discussed.
When I first read the specification, I came away with a much simpler mental
model.
I assumed that a DKIM2 chain represents a complete chain of responsibility for
a message:
the first DKIM2 signature (i=1) always belongs to the originator;
every subsequent signature represents an intermediary that modified the message
and therefore takes responsibility for that modification;
intermediaries that do not modify the message simply relay it and do not add a
DKIM2 signature.
Under that interpretation, the receiver can always identify the originator as
the first signer in the chain, while every subsequent signer is simply another
accountable participant
in the message's history.
This is why I'm struggling a little with the recent discussions around
"re-originators".
If an intermediary modifies the message, why isn't it simply another signer in
the existing chain?
If it creates what is effectively a new message, shouldn't that start a new
DKIM2 chain instead?
In other words, I'm wondering whether introducing a distinct "re-originator"
concept is actually necessary at the protocol level, or whether the chain
itself already expresses
the sequence of responsibility.
Perhaps I'm missing an important deployment scenario, but I thought I'd ask
because my original reading of the specification led me to this simpler
interpretation.
Regards,
Pietro
Da: Wei Chuang <weihaw= mailto:[email protected] >
Inviato: venerdì 24 luglio 2026 08:07
A: IETF <ietf= mailto:[email protected] >
Cc: ietf-dkim < mailto:[email protected] >; Tobias Herkula <tobias.herkula=
mailto:[email protected] >
Oggetto: [Ietf-dkim] Re: R: Another question: introducing DKIM2 for non-DKIM2
originators
Apologies for missing this earlier and for the late post just right before
Vienna.
On Thu, Jul 16, 2026 at 6:26 AM IETF <ietf= mailto:[email protected] >
wrote:
Hi All, and Hi Tobias,
While reading both the current specification and the DKIM2 BCP draft, I came
away with the understanding that the
intended trust model is that a DKIM2 chain starts with a DKIM2 originator.
In particular, the current BCP seems to discourage a DKIM2-capable forwarder
from introducing a DKIM1-only message
into the DKIM2 ecosystem, unless I'm misunderstanding its intent.
I don't think the BCP text is necessarily discouraging introducing DKIM1 only
message to DKIM2. Rather it acknowledges that introducing a DKIM1 message to
DKIM2 makes subsequent DKIM2 receivers vulnerable to DKIM replay that DKIM2 is
meant
to prevent. The BCP text calls out that it is the forwarder introducing the
DKIM1 message's responsibility to prevent DKIM replay. How this is done is up
to local policy. If the forwarder fails to do that, as Richard says, the
forwarder causing the vulnerability
is identified by their DKIM2 signature.
But this does bring up a different point. The definition of "originator" needs
to be clear so we can tell if a DKIM1-only message was admitted into DKIM2 by a
forwarder or if it originated in DKIM2. The BCP and DKIM2 specs reference
"originator"
from
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5598%2F%23section-2.2.1&e=b336b1a5&h=16fd070f&f=n&p=y&m=4h5yFG6N28zJmkd
and there it is defined in SMTP mail architecture by
its function. However a receiver needs to identify whether an originator was
present based on the evidence in the message, particularly the header fields.
I propose that the BCP define "originator" based on From: header field
alignment with the i=1 DKIM2
signature. To me that is the most intuitive approach since it is the
signature closest to the message Author. There may be other later DKIM2
signatures that align with the From: header field, particularly if the >From
header was rewritten to support DMARC
which is likely interesting, but probably less important to the Receiver.
That's why your question caught my attention.
Is the current specification intentionally leaving this undefined for now, or
is the expectation that a DKIM1 message
should never become the starting point of a DKIM2 chain?
I think the DKIM2 spec is intentionally vague there, leaving such
considerations to the BCP for now. I agree that at some point we should think
about whether these interoperability considerations along with a specification
for DKIM2's
interaction with DMARC ought to go into another standard (or proposed
standard) track document.
-Wei
Regards,
Pietro Mauri
Da: Tobias Herkula
<tobias.herkula= mailto:[email protected] >
Inviato: mercoledì 15 luglio 2026 22:51
A: ietf-dkim < mailto:[email protected] >
Oggetto: [Ietf-dkim] Another question: introducing DKIM2 for non-DKIM2
originators
Questa è la prima volta che ricevi un'email da questo mittente. Assicurati che
sia qualcuno di cui ti fidi.
Hi all,
One more observation from my reading of the draft.
I noticed that I couldn't find any guidance on introducing DKIM2 for messages
originating from systems that are not DKIM2-aware.
The draft appears to assume that the trust chain starts at the originator,
which intuitively seems like the cleaner model to me. However, I could also
imagine deployments where the first DKIM2-capable MTA attempts to introduce an
existing message into the DKIM2 ecosystem.
If such a deployment is not intended, I think it might be worth stating that
explicitly. If it is intended, I would have expected the draft to discuss
the associated trust semantics and what exactly the first DKIM2 signature is
asserting in that situation.
I'm not advocating for introducing this capability—in fact, my expectation was
that the trust chain should begin with the originator. I was simply surprised
that I couldn't find any text confirming or rejecting this deployment model.
Regards,
Tobias
--
Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non
infetto.
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fmail2.mcnsrl.it%2Faction%2F4h0pHY3dRtzH20H%2Freport-as-bad&e=b336b1a5&h=f7b3375a&f=n&p=y&m=4h5yFG6N28zJmkd
https://urlsand.esvalabs.com/?u=https%3A%2F%2Fmail2.mcnsrl.it%2Faction%2F4h0pHY3dRtzH20H%2Fblocklist&e=b336b1a5&h=74f74d1e&f=n&p=y&m=4h5yFG6N28zJmkd
_______________________________________________
Ietf-dkim mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
--
Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non
infetto.
https://mail2.mcnsrl.it/action/4h5yFG6N28zJmkd/report-as-bad
https://mail2.mcnsrl.it/action/4h5yFG6N28zJmkd/blocklist
_______________________________________________
Ietf-dkim mailing list -- mailto:[email protected]
To unsubscribe send an email to mailto:[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
