Hi Wei, I'm still very concerned about the security and safety risks being introduced by allowing a DMARC pass for body changes even if they don't munge the From. I think it introduces serious phishing and spear phishing risks for sensitive domains that should not be the default spec behavior. A DKIM2 intermediary that legitimately received a message could replace the body with a phishing message, record a Recipe that restores the original, and deliver it with a DMARC pass for the author's domain. With donotmodify removed in -07, the domain owner has no way to prevent this. I think a DMARC pass should keep meaning what it means with DKIM today: the From domain signed the content as delivered.
I made some specific changes below to how sections 2.1 and 2.2.2 choose the >From header field and signature used for DMARC alignment. I think any of them would be reasonable. Section 2.1: replace the text about the From recovered at i=1 (and the sentence in 2.2.2 that refers back to it) with: The Author Domain is taken from the RFC5322 From header field of the message as delivered, as in [RFC9989]. Section 2.2.2: replace "the DKIM2 signature d= domain at the Originator (i=1)" with: the Signing Domain of the highest numbered DKIM2-Signature header field, without an nd= tag, whose Signing Domain is a relaxed domain match for the Author Domain. Alignment holds only if the message has not been modified since that DKIM2-Signature header field was created. What follows is three different ways to define "not modified", from loosest to strictest (all seem reasonable to me): 1. Body only (the From is Body-Authentic, as proposed in https://github.com/dkim2wg/spec/pull/13): the body hash recorded in the Message-Instance header field identified by its m= tag equals the body hash of the message as delivered. 2. Body and Subject: as in (1), and no Message-Instance header field with an m= value higher than that DKIM2-Signature header field's m= tag contains a Header Recipe for the Subject header field. 3. Body and signed header fields, as DKIM treats them: as in (1); every header field that was present when that DKIM2-Signature header field was created is still present and unchanged; and no From, Reply-To, Subject, Date, To or Cc header field has been added since. Option (3) is how DKIM behaves today for a signer that signs the header fields present and over-signs the core fields, as RFC 6376 sections 5.4.2 and 8.15 recommend. A header field the author signed cannot be changed or removed. New header fields such as List-Id can be added, but the core fields cannot. Verifiers already reconstruct the earlier state of the message when checking the chain, so the check is a comparison of two sets of header fields. For mailing lists that do not rewrite From, all three options keep the pass when the list only adds List-* header fields, and lose it when the list adds a footer. (2) also catches Subject tags, but would let other signed fields such as Reply-To or To be changed. (1) lets Subject tags through as well. Thanks, Emanuel On Mon, Sep 21, 2026 at 12:13 AM Wei Chuang <[email protected]> wrote: > Some more bug fixes in -03: > https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/03/ > > -Wei > > On Sun, Sep 20, 2026 at 4:44 PM Wei Chuang <[email protected]> wrote: > >> I've updated the document to -02: >> >> https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/02/ >> >> This strips out mention of support for policy lookup or alignment >> requirements at i=n. This also strips out mention of From header field >> rewriting. Various subsection headers have been clarified. >> -Wei >> >> On Sun, Sep 20, 2026 at 1:22 PM Wei Chuang <[email protected]> wrote: >> >>> >>> >>> On Sun, Sep 20, 2026 at 8:24 AM Richard Clayton <[email protected]> >>> wrote: >>> >>>> >>>> >It's possible I'm overreading the relationship >>>> >between draft-ietf-dkim-dkim2-spec and this proposal, and if fact what >>>> you >>>> >are proposing is to support i=1. If so, as Pietro points out, >>>> evaluating >>>> >DMARC at i=1 can simplify this proposal. >>>> >>>> I am in favour of the "enhanced-for-DKIM2 DMARC" and relevant MUAs using >>>> the i=1 value of the RFC5322 header field. >>>> >>>> But whatever we decide, the notion that every hop rewrites the RFC5322 >>>> - From header field is nonsense. Your draft says that. If you think my >>>> - -spec document says that then please cite the paragraph and will >>>> ensure >>>> that the text is modified appropriately >>>> >>>> >>> My document says this, and I'm stripping that text out. >>> -Wei >>> >>> >> _______________________________________________ > 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]
