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 <[email protected]> Inviato: venerdì 24 luglio 2026 08:07 A: IETF <[email protected]> Cc: ietf-dkim <[email protected]>; Tobias Herkula <[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 <[email protected]<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 RFC5598<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 <[email protected]<mailto:[email protected]>> Inviato: mercoledì 15 luglio 2026 22:51 A: ietf-dkim <[email protected]<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. Clicca qui per segnalarlo come spam.<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> Clicca qui per metterlo in blocklist<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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Clicca qui per segnalarlo come spam.<https://mail2.mcnsrl.it/action/4h5yFG6N28zJmkd/report-as-bad> Clicca qui per metterlo in blocklist<https://mail2.mcnsrl.it/action/4h5yFG6N28zJmkd/blocklist>
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
