On Mon, Nov 2, 2026 at 3:29 PM Emanuel Schorsch <[email protected]> wrote:
> Thanks Wei! > > On Mon, Nov 2, 2026 at 2:38 PM Wei Chuang <[email protected]> wrote: > >> On Tue, Oct 27, 2026 at 12:58 PM Emanuel Schorsch <[email protected]> >> wrote: >> >>> In the benign case I agree. For a mailing list or a trusted forwarder >>> you are of course correct. The whole issue here is that you don't know who >>> are benign forwarders. In the malicious case, it is the opposite, the >>> malicious forwarder's identity is the more relevant thing to show. >>> >> >> What I try to argue is in the general case for general mailbox user >> traffic that might traverse mailing lists, this identity doesn't have to be >> rewritten for DKIM2. For more sensitive transactional traffic, e.g., >> PayPal/IRS/billing traffic that is NOT intended to go through mailing >> lists, it can be distinguished by a flag donotmodify. The mandates From >> rewriting behavior, or that MTAs reject such traffic. Either way with >> DKIM2, you know the forwarders' identities via signature rt=/mf= tags and >> from earlier versions of the From headers as they are rewritten. >> > > Isn't this what DMARC allows today? Less sensitive mail can stick to > p=none. > Functionally similar, but this proposes a per message flag "donotmodify" which you acknowledge below, whereas the DMARC p= policy is domain-level. > And the reverse direction is equally true, "Either way with DKIM2, you > know the originators' identities". It still seems to me to come down to a > question of defaults. And whether the default behavior should change from > what it is today on day one of DKIM2 counting for DMARC. Or if we should > revisit this discussion once we have seen how DKIM2 adoption is proceeding > in the field and how providers are updating to handle it. > >> >> To be clear, I fully agree that receivers can and should use their local >>> understanding of their customers' relationships to undo the fromMunging and >>> show the originator when that is more relevant. Where I disagree strongly >>> is that the spec should default to showing the originator for a p=reject >>> domain instead of requiring receivers to make an intentional and informed >>> choice into adopting that behavior. >>> >> >> What I'm suggesting has one additional change, in that it proposes >> publishing a "donotmodify" flag on the signature, to distinguish the >> traffic sensitivity. >> -Wei >> > > I have two concerns on the "donotmodify" flag. One, I'm not yet convinced > of the benefit. It seems like it shifts the classification from the domain > level "p=reject" to the message level. Do you anticipate IRS/Paypal/Google > adopting that? Do you anticipate that they'll be comfortable with their > domain defaulting to allowing modifications and relying on all their infra > updating to adding "donotmodify" on every risky message? It seems more > realistic that they would want the default to be "donotmodify" and allow > tagging a message with "okaytomodify" to indicate that despite the domain > level guidance, this specific message is low risk and okay to modify. That > would also require fewer changes on day one. > Potentially yes. Let's take your new wording- "okaytomodify" as the flag, even though I'm sure it's intended to bias the reader to question the message's safety in such forwarding flows. I would imagine that Mailbox Providers might find it useful because I still believe recipients can make a better trust determination with the message's author than forwarders such as mailing lists or security gateways that may leave footers, modify the subject, etc. It's even more likely when the alternative implies do-not-modify, and some forwarders that must modify the message may reject it rather than rewrite the From header. > My second concern, and a bigger concern, is that the content of the > message is irrelevant because arbitrary body modifications are allowed. The > risk comes from the domain itself. Suppose someone from irs.gov > participates in an IETF discussion and is sending a text only low risk > message. They tag it with "okaytomodify". But now, the recipient has a > validly signed irs.gov message and can change the body / subject in any > way they want with recipes and now not modify the fromHeader. The issue is > that even the lowest risk message from a phishing target domain has high > risk because of body recipes. That's the main reason why I don't see much > of a use-case for a message level "donotmodify" tag instead of the usual > DMARC behavior. > I see the "okaytomodify" flag being used with personal communications, which, at a practical level will be harder to exploit than notification emails because the attacker has to participate in personal conversations. I'm not claiming it's impossible, but not as easy as you're implying. In any case, the IRS personal sender can choose the do-not-modify default as well. A simple policy might be to set "okaytomodify" for IRS internal traffic that might traverse its internal mailing lists. In all other cases, use the do-not-modify default, which implies From header rewriting or message rejection upon forwarder modifications. -Wei > Best, > Emanuel >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
