I agree completely. This fixes a gap that I was worried about and prevents attackers from taking advantage of body recipes to introduce unrelated fromHeaders like irs.gov if they can’t back them up with authentication. I also think this belongs in the dkim2 spec itself.
Best, Emanuel On Thu, Sep 17, 2026 at 12:57 PM Tobias Herkula <tobias.herkula= [email protected]> wrote: > 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]> > 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] > To unsubscribe send an email to [email protected] > > _______________________________________________ > 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]
