On Thu, Nov 5, 2026 at 10:27 PM Wei Chuang <[email protected]> wrote:
> On Mon, Nov 2, 2026 at 3:29 PM Emanuel Schorsch <[email protected]> > wrote: > >> ...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? ... >> > > 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 intention wasn't to bias against the message's safety, and I'm open to other wording. My goal is that the default behavior remains the same as today, modifications without from munging = DMARC fail. So I just wanted to make sure that the absence of the flag (since most organizations will default to not adding it) preserves that behavior. I recognize that many people are okay with those modifications and I think it is good to support that use-case (effectively what p=none does today). > > >> My second concern, and a bigger concern, is that the content of the >> message is irrelevant because arbitrary body modifications are allowed. ... >> > > 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. > Thanks, Wei! I think this is reasonable. If you see a use-case for the "okaytomodify" flag I have no objections and think it's a reasonable capability to add. My primary concern is that default behavior remains the same as today. So just to double check, if "okaytomodify" was missing, the message was modified, and the fromHeader wasn't munged then DMARC would be a fail? And if "okaytomodify" is present then DMARC would be a pass? At the end of the day receivers can do whatever they like as Tero and John point out. But I think p=none/quarantine/reject gives providers the flexibility to express what behavior they would "like" in a way that we've seen be useful and I think "okaytomodify" usefully extends that concept to the message level instead of only being able to make domain level statements. Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
