On Tue, Nov 3, 2026, at 12:30, William Weiner wrote: > Richard, > > Thanks for putting this together. Some comments from the point of view of a > system that modifies mail on behalf of recipients. > > * Removals. The three modification categories all add or replace. In practice > a lot of modification is removal: security gateways stripping attachments or > links, and privacy filters removing remote content such as tracking images > (present in nearly half the messages in the corpus I posted on Oct 13). > Removal is a different risk class from addition, since it cannot introduce a > phishing payload, so a removal category (remote content, attachments) could > let receivers recognize the benign case cheaply, which seems to be the aim of > the draft.
Removal isn't possible with DKIM2 - not entirely - unless you use NULL recipes, or provide the instructions to recreate the original message. Which means you're basically either re-originating the message, or at least doing a NULL body recipe. There is no "benign entire removal" possible with the current hashing mechanism. > It also matters for verification. As Vittorio noted, current implementations > cap Recipes at around 1000 literal lines, so removing an attachment over > roughly 56 KB forces a null Recipe, which -09 reports as PERMERROR. Unless > removal is handled somewhere, the most common recipient-side change will push > those systems to break the chain or start a new one, and receivers lose the > per-hop attribution DKIM2 is meant to provide. Which basically means, as has been stated by Richard many times in many IETF calls and emails (and by me) that what you're doing needs a trust relationship with either the sender (in which case you re-originate) or the final recipient (in which case they override the PERMERROR for known sources, basically they don't re-validate DKIM2 if the message comes from you, they trust your validation). > * Who sets the request. Most mail originates at large mailbox providers, so > in practice CanModify will express what the provider’s software chooses > rather than what the individual sender wants. Is a per-user setting meant to > be in scope, or is the provider treated as the originator for this purpose? Provider is probably the originator. I have been thinking about this and I expect mailbox providers for general users to default to "subject prefix, from replacements, body wrap". > * Recipient-requested changes. Some modifications are asked for by the > recipient, for example a filtering or security service they chose. If a > message carries “CanModify: none” and the recipient’s own service then > changes it, the final receiver sees a violated request that the recipient > actually wanted. A sentence on how receivers should treat changes made on the > recipient’s behalf might help. Otherwise “none” may push those services > toward rewriting From, which is the outcome the draft seems to be trying to > make unnecessary. Recipient can ask for whatever they want, they're the recipient. We're not the protocol police, they can have a relationship which overrides DKIM2. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
