On Fri, Oct 23, 2026 at 10:56 AM Emanuel Schorsch <[email protected]> wrote:
> 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 think that position outlines the crux of the difference. While I understand your perspective, I think that human recipients can better make security decisions using the author's identity of the originating message than the forwarder's identity. Users typically have some sort of relationships with the message author, and much less so with the forwarders. The forwarder acts as a service provider, e.g., distributing messages or performing security scanning. The sender's identity is important so users can decide what to do with the message, e.g., read or delete it. Using forwarder identities muddles that decision making. Think about a mailing list or compliance security gateways that add footers. As a user, I would find the author of a message sent to the mailing list or that has to go through a security gateway more meaningful to me. Further, DKIM2 makes it possible for a mail client to display the authenticated forwarder's email address instead, if it chooses to do so. If we don't require From header munging, we lose the display name part of the RFC5322 >From header but since that's not authenticated, I don't think we're losing anything. If the forwarder is malicious and introduces phishing or malware, keep in mind that the originator who sent the message through that malicious forwarder shares some responsibility for that malicious traffic. The other reason the draft-chuang-dkim2-sender-policy <https://datatracker.ietf.org/doc/draft-chuang-dkim2-sender-policy/> draft chooses an i=1 originator domain DMARC policy is that DMARC reports should go there. The author sent the message down that path and if the message has a delivery issue due to authentication, presumably they should be able to find out via reports. The originator should control the enforcement action if any to prevent spoofing of their domain as well as any other domain level policy. At the risk of weakening my position, let's take your irs.gov example. I do agree there is a risk that malicious forwarders will introduce phishing and malware into irs.gov traffic with the above DMARC and DKIM2 handling policy. I think the difference is that as a user I would like to easily distinguish [email protected] from [email protected] even if it goes through some mailing-list [email protected]. That's different from [email protected] which I don't expect to go through any forwarder to me. If it does, I would like to know who made this change and what changed. I propose we create a lightweight "donotmodify" flag. That flag can be specified by the originator to tell forwarding relays with RECOMMENDED to not modify the message body or the Subject, To, Cc, or Reply-To header fields. If forwarders do so, they MUST rewrite the RFC5322 From header field and it MUST align with the current DKIM2 signature d= domain. This permits forwarders obligated to modify messages to continue to do so, but ensures they are identified. Receivers observing this change can still choose to reject such messages according to their local policy or accept them. If the receiver presents the message to the user, this proposal says with RECOMMENDED that there be a UI notification describing the change. In this proposal Date and Message-id can never be rewritten legitimately and such modifications MUST be rejected by receivers. Taking that irs.gov example again. If they send with the "donotmodify" flag, and that traffic sent through a mailing-list, then. the From header field identity becomes [email protected] instead of [email protected]. That's probably the appropriate level of friction since it would be pretty surprising if tax information went through a mailing list to get to me. Similarly I would not expect traffic from irs.gov to go through a DLP filter to reach me. On the other hand, mailbox user traffic normally should not get this "donotmodify" flag and could drop the From rewriting behavior once DKIM2 becomes widespread. Thanks. -Wei > 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]
