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. 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. 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. Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
