Sorry for the slight necro-bump here. Richard's original mail arrived while I was on vacation, and I only came across it this week.
I support Richard's approach and would very much like to see this added directly to the DKIM2 specification. For me, this is not primarily a DMARC interaction or policy question. It is a property DKIM2 itself should provide: whenever an RFC5322.From field is introduced or changed, there should be a required domain match between the domain in that field and the d= domain of the DKIM2 signature added at that point. So for the initial message, the RFC5322.From domain would need to match the d= domain of the i=1 signature. If an intermediary later changes the RFC5322.From field, the new domain would need to match the d= domain of the DKIM2 signature added by that intermediary. If the From field is not changed, there is no need to establish that match again at every subsequent hop. I would also prefer to avoid the term "alignment" here, simply because it already carries a lot of DMARC-specific meaning. "Domain match" seems to describe what we need without importing terminology from another protocol. I would prefer this to be a normative part of the DKIM2 specification rather than something defined in a separate DMARC-related document. Otherwise DKIM2 can authenticate the handling chain while still leaving the relationship between the visible author domain and the signer responsible for introducing or changing that author identity undefined. In practice this relationship is already expected by the major mailbox providers through today's DKIM and DMARC requirements. Making the domain match an explicit DKIM2 property therefore seems both useful and consistent with current deployment reality. -- Best regards, Tobias Herkula Head of Mail Transfer Development Mail Backend Development 1&1 Mail & Media Development & Technology GmbH www.mail-and-media.com Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr. Verena Patzelt Member of United Internet This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. ________________________________ From: Wei Chuang <[email protected]> Sent: 02 September 2026 15:55 To: Richard Clayton <[email protected]> Cc: [email protected] <[email protected]> Subject: [Ietf-dkim] Re: Insisting that From is authentic I propose that defining DKIM2 interactions for the RFC5322 From header field become a separate document along with defining DMARC interactions. I do like the current draft-ietf-dkim-dkim2-spec's intentional separation of policy from authentication. In fact a separate document can better make that separation more distinct and clear. -Wei On Mon, Aug 31, 2026 at 7:34 AM Richard Clayton <[email protected]<mailto:[email protected]>> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Several people have spoken up about the interaction between DMARC and DKIM2 -- and the issues that arise when the RFC5322 From header field is changed by an intermediary. There is a straightforward way to address this -- which I would commend to the working group. We update the spec to say that when a From field is first placed into a message (ie it sits alongside an i=1 DKIM2-Signature) or when it is changed by an intermediary (there is a recipe that shows that it has been changed at a particular hop) then DKIM2 will insist that there is match between the d= domain being used to sign and the domain in the RFC5322 From header field. The appropriate match would seem to be the "relaxed" match described in #9.4 .. viz if d= and the domain in the RFC5322 From header field are not identical then remove labels until the values are identical or until there are no labels remaining in which case there is no match. Since in the real world no-one can sign for .com (or whatever your publicly used TLD may be) this is just as safe as the MAIL FROM match already required (and we don't need to wander into the world of tree- walks or the PSL). Since this fits with what a number of people have been asking for, unless there is outrage (or an important use case where this would be impossible) I will put appropriate text into spec-07 so that the detail of the wording (rather than just the concept) can be considered by the Working Group. - -- richard @ highwayman . com "Nothing seems the same Still you never see the change from day to day And no-one notices the customs slip away" -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBapWQgmHfC/FfW545EQIf0wCgjNlZqZ19T/R52pHjBh5PXsXeBSQAn1ya ypqXc1AYxPSFiM+YIThRE5Dq =iOeT -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
