On Wed, Sep 16, 2026 at 7:08 PM Emanuel Schorsch <[email protected]> wrote:
> Thanks for the clarifications! Some comments below. > > On Wed, Sep 16, 2026 at 5:49 PM Wei Chuang <[email protected]> wrote: > >> >>> - Why do we need to switch from evaluating the current RFC5322 >>> fromHeader to evaluating the domain at i=1? Is it to deal with the >>> consequences of the second bullet? It seems to imply if you want to >>> violate >>> the originators intent, instead of just needing to do fromHeader munging >>> (how it works today to take ownership and bypass), you would need to >>> start >>> the chain over (unnecessarily throwing out useful information). >>> >>> If From header munging occurs, it typically supports DMARC with DKIM1, >> not DKIM2, which can authenticate through message modifications at >> forwarders. The munged From header's authenticated domain represents the >> forwarder's policy. That forwarder isn't the author who introduced the >> message; rather, it works in support of the author to deliver the message >> to its final destination. The author would more commonly be viewed as the >> message owner. More concretely, a user sends a message to a mailing-list. >> Should we use the policy of the mailing-list or the message author? I >> prefer using the author's policy. >> > > I hear you, and am sympathetic to the argument that the original author > should get some say (possibly the max of the i=1 and i=n policies?), but I > have some concerns about this approach. > > 1) Consistency. The current fromHeader is what is used today to decide > what DMARC policy should be applied. The fromHeader indicating who the > current sender is, is what most systems have evolved around today. Many > systems add the current fromHeader to addressbooks (one of the complaints > about fromMunging). Even if the consensus ends up being that we should > migrate this behavior, it seems premature to migrate this before systems > have had time to update for the DKIM2 world. I think it is safer to update > the spec in phases. In phase1 now we keep more consistent and use the > current fromHeader to decide policy. In phase2 once DKIM2 has been more > widely adopted we update to use i=1. > One way to do this is to specify i=1 or i=n policies, and have the BCP say what the current recommendation is. > 2) Safety. Suppose spammer.com is the i=1 hop and has a p=none policy. He > sends DKIM2 mail to phisher.com at i=2 hop who DKIM2 signs with > phisher.com and updates the fromHeader to irs.gov and then sends it along > to a victim. How would your current proposal apply? If the receiver mailbox > looks at i=1 wouldn't it determine that the right consequence is to still > accept the mail? Vs looking at i=n and seeing irs.gov has a p=reject > policy and no domain matches it and the mail should be rejected. > If the i=1 author is [email protected], shouldn't we use that as the authenticated identity rather than some forwarder's identity? Also we can require the From header to be aligned at every SMTP transaction boundary which implies From header munging at those boundaries. FWIW the current I-D calls for that by default, though that's pretty onerous, and there is an explicit escape hatch with the "unaligned" flag. > 3) Graceful failure. Noone intended fromHeader munging to be a solution. > It was an unintended consequence to DMARC allowing senders to assert > policy. What was the easiest way to get around the sender asserted policy > for DMARC? Change the fromHeader. So that's what people did. Because > inevitably there are mail paths that need to continue to flow (in this case > mailing lists) and there is a legitimate desire to not lose all forensics > but instead to do the minimum needed to be able to forward the mail along > to the next recipient. I expect the same thing to happen here. There will > be mail flows not fully supported for various reasons. If you tell people > to look at i=1 then if an intermediary wants to send the mail along in a > non-breaking way they will be forced to entirely destroy the chain and > start a new one so that they are i=1 and can determine the policy. I think > that is a much more destructive outcome than fromMunging that loses a lot > more forensics and so is a less graceful way to handle that failure case. > I'm not sure I follow the scenario. I guess this is saying that chain of custody can be verified to i=n (highest) but not to i=1 because the algebra doesn't work. To me that is WAI. Those earlier identities can't be claimed. > >> >>> This would keep consistency in the following examples: >>> >>> 1) Mail is sent to a DKIM2 mailing list which adds a footer. FromMunging >>> is done. fromHeader now aligns with a signer of the current copy. DMARC >>> Pass. Same as today. >>> 2) Mail is sent to a DKIM2 mailing list which adds a footer. No >>> fromMunging is done. fromHeader does NOT align with a signer of the current >>> content, but does align with the original sender pre-change-recipe. DMARC >>> Fail. >>> >> >> I think the goal of DKIM2 with an updated DMARC is to support keeping the >> original aligned From header and allow that to count as a pass. >> > > I had a different understanding of the goal of DKIM2. My understanding was > that the goal was to create a safe way for interested receivers to recover > the original aligned fromHeader and restore it under their best judgment. > Likely that's the crux of the debate. There's DKIM2's goals (the spec document) which I agree is mean to to recover the prior versions of the message. I claim that an updated DMARC goal ought to support authentication w/ the original aligned From header w/o munging. > > >> >>> 2a) If fromDomain is p=reject then mail would be rejected. Same as >>> today. (with your proposal, mail would be accepted, which would be a big >>> change). >>> 2b) fromDomain is p=none then mail is accepted. Same as today. >>> >>> If I'm understanding right, because of this consistency most mailing >>> lists would continue to interoperate just as well as they do today. E.g. >>> IETF which does fromMunging if there was p=reject would continue to be >>> unaffected by 2a and 2b would continue to work for IETF as it does today. >>> >> >> Current behavior involves From header munging caused by the existing >> DMARC and DKIM; DKIM2 and updated DMARC must initially support and handle >> this. However, this doesn't mean we must continue supporting From header >> munging in the distant future once DKIM2 and updated DMARC adoption is >> widespread. >> -Wei >> > > Thank you for making this point clearly as I think it is an important > discussion that we need to broadly have. I disagree on the long-term goal > and think even with 100% DKIM2 adoption, fromHeader munging should still be > the default behavior. My main reasons are: > > 1) Safety. Even if everyone adopts DKIM2, not every MUA and receiver will > necessarily update their systems to handle body recipes appropriately. I > expect that even after DKIM2 is fully rolled out there will still be a > number of receivers that haven't updated to take advantage of the new > properties that DKIM2 has. Given that many many people are used to looking > at the fromHeader to tell who the sender is, I think there is a real > phishing risk introduced by changing the default to allow impersonations > (even if those impersonations are tracked). > Agreed, it is entirely possible the forwarder is malicious and attempts to spoof the author. But keep in mind that the author sent the message down that path, and no one else, which DKIM2 can verify. > 2) Compatibility. I made the point above so won't belabor it. But I think > this is a huge change in how the mail system operates and what assumptions > are made. So even if we go down that path I think we should start with > behavior that is close to what exists today. We can update the DMARC spec > again down the road once there is more experience with DKIM2 and what the > adoption looks like. > 3) Tradeoffs. I understand many hate fromMunging. But it seems to me like > interested receivers now have a very straightforward way to reverse the > effects. On the flipside removing fromMunging has real risks that are more > difficult to mitigate. > There are other tradeoffs though such as usability which touches upon security. Most likely the recipient is familiar with the author's identity, but less likely with the intermediate identities. For instance, consider the not-uncommon problem where From header munging on mailing-lists obscures the author's identity, which spammers and phishers exploit. -Wei > > Best, > Emanuel >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
