Hi all, I would like to pick up one point from Richard's comments in the “base64+JSON on the critical path” thread, because I think it is also relevant to this discussion. On this particular aspect, I find Richard's interpretation quite compelling: when a From field is first introduced at i=1, it should align with the d= domain of that signature, and if an intermediary later changes the From field, the signer making that change should align with the new From identity. To me, this gives i=1 a simple and unambiguous meaning, while still allowing intermediaries to modify the message and sign those modifications without having to align with the original From domain. As long as they do not change the From field, I don't see why they should need to. What I am still struggling with is the role of unaligned. I understand the migration and interoperability motivation behind it, and Wei's explanation of the longer term goal of avoiding From munging, but I am not sure I understand what security property we gain by allowing an authenticated signer to explicitly declare that it is not aligned with the identity being shown to the recipient. In particular, if I have understood this correctly, authentication of that declaration does not seem to establish authorization to use the unaligned From identity. We know who made the declaration, but that does not tell us that the domain in the From field authorized that signer to represent it. This is why I would prefer to keep the relationship simple: the From identity is aligned with i=1, and whenever that identity is changed later in the chain, the new From is aligned with the signer that introduced the change. Other intermediaries can remain exactly what they are, authenticated participants in the chain that take responsibility for their modifications, without claiming the From identity. I also think this keeps two different questions reasonably separate. DKIM2 can establish the authenticated history of the message, including who introduced or changed the identity presented in the From field, while DMARC or another policy layer can determine what the Domain Owner expects receivers to do with that information.
Best Pietro Da: Wei Chuang <[email protected]> Inviato: giovedì 17 settembre 2026 05:36 A: Emanuel Schorsch <[email protected]> Cc: Al Iverson <[email protected]>; [email protected] Oggetto: [Ietf-dkim] Re: DKIM2 / DMARC Sender Policy Proposal On Wed, Sep 16, 2026 at 7:08 PM Emanuel Schorsch <[email protected]<mailto:[email protected]>> wrote: Thanks for the clarifications! Some comments below. On Wed, Sep 16, 2026 at 5:49 PM Wei Chuang <[email protected]<mailto:[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<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fspammer.com&e=b336b1a5&h=258ef9b6&f=n&p=y&m=4hlhHw3SkkzGqB2> is the i=1 hop and has a p=none policy. He sends DKIM2 mail to phisher.com<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fphisher.com&e=b336b1a5&h=53420727&f=n&p=y&m=4hlhHw3SkkzGqB2> at i=2 hop who DKIM2 signs with phisher.com<https://urlsand.esvalabs.com/?u=http%3A%2F%2Fphisher.com&e=b336b1a5&h=53420727&f=n&p=y&m=4hlhHw3SkkzGqB2> and updates the fromHeader to irs.gov<https://urlsand.esvalabs.com/?u=http%3A%2F%2Firs.gov&e=b336b1a5&h=ee0b2eeb&f=n&p=y&m=4hlhHw3SkkzGqB2> 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<https://urlsand.esvalabs.com/?u=http%3A%2F%2Firs.gov&e=b336b1a5&h=ee0b2eeb&f=n&p=y&m=4hlhHw3SkkzGqB2> has a p=reject policy and no domain matches it and the mail should be rejected. If the i=1 author is [email protected]<mailto:[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 -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Clicca qui per segnalarlo come spam.<https://mail2.mcnsrl.it/action/4hlhHw3SkkzGqB2/report-as-bad> Clicca qui per metterlo in blocklist<https://mail2.mcnsrl.it/action/4hlhHw3SkkzGqB2/blocklist>
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
