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]> 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://www.rfc-editor.org/info/rfc5598/#section-2.2.1> 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]> > *Inviato:* mercoledì 15 luglio 2026 22:51 > *A:* ietf-dkim <[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://mail2.mcnsrl.it/action/4h0pHY3dRtzH20H/report-as-bad> > > > Clicca qui per metterlo in blocklist > <https://mail2.mcnsrl.it/action/4h0pHY3dRtzH20H/blocklist> > _______________________________________________ > 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]
