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. 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. * 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? * 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. William Weiner From: Richard Clayton <[email protected]> To: <[email protected]> Date: Mon, 02 Nov 2026 10:19:07 -0700 Subject: [Ietf-dkim] Re: I-D Action: draft-clayton-dkim-canmodify-00.txt > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >Internet-Draft draft-clayton-dkim-canmodify-00.txt is now available. > > > > Title: Permitted modifications to DKIM2 messages > > Author: Richard Clayton > > Name: draft-clayton-dkim-canmodify-00.txt > > Pages: 6 > > Dates: 2026-11-02 > > Attentive readers will recall that we dropped the "donotmodify" flag > from DKIM2, that some people are concerned we have discarded the > "fragility" of DKIM1 (any change makes it fail), and also that I > promised to produce a proposal to tackle this by means of a new header. > > I have a strawman proposal which sets out some "benign" modifications > that senders might wish to allow (to be pragmatic about what happens to > their messages in the Real World TM). > > It does stress that these are requests and Receivers will do whatever > they want -- so maybe it is useless to try anything in this space at > all... but do see what you think ! > > <https://datatracker.ietf.org/doc/draft-clayton-dkim-canmodify/> > > - -- > richard @ highwayman . com "Nothing seems the same > Still you never see the change from day to day > And no-one notices the customs slip away" > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBaujGC2HfC/FfW545EQKM+wCfTp8wkfVA8jveUPpH6QUn4mkfUDEAoI6b > WGfMaFqVd594C40E3UAVnk96 > =jkcK > -----END PGP SIGNATURE----- > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
