Tero, +1 to hashing MIME parts separately.
A Recipe that can undo a removal has to carry the removed content forward. If a safety filter strips a malicious content, the removed content travels on in the Message-Instance headers, and anything that reconstructs would put it back. A filter whose purpose is removal will choose a null body Recipe and under -09 that means the message cannot be fully verified. Perpart hashing gives safety removal a path and the original signature can still be checked. Removed attachments map onto that directly. A dangerous link inside an HTML part does not; that would need the same idea at a finer grain, which likely is not worth the complexity. On the trust point your example shows that “recipient” in this discussion carries two meanings: the person the mail is for, and the receiving provider. The person can choose a forwarder or filter, but unless the provider gives them a way to say so, that choice never reaches the system making the decision. For clarity, none of this affects my own service. It is a privacy relay and protecting identities already requires it to re-originate. So its position is settled. I raise this because forwarders and safety filters in general will run into it. William Weiner From: Tero Kivinen <[email protected]> To: "Bron Gondwana"<[email protected]> Cc: "William Weiner"<[email protected]>, "Richard Clayton"<[email protected]>, "ietf-dkim"<[email protected]> Date: Tue, 03 Nov 2026 15:23:02 -0700 Subject: [Ietf-dkim] Re: I-D Action: draft-clayton-dkim-canmodify-00.txt > Bron Gondwana writes: > > 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. > > I do have a feeling that we are going to see lots of NULL body > recipies... > > > There is no "benign entire removal" possible with the current > > hashing mechanism. > > We could of course modify the hashing mechanism to be such that > complete MIME parts could be removed (i.e., hash each mime part > separately, and then generate body hash by hashing combintion of those > hashes, in which case there would be remove MIME part xxx having hash > of yyy, and then even when the final recipient is not able to > reconstruct the missing body part, it can verify that there used to be > such body part and verify the original signature). > > > 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). > > Unfortunately that does not work. I am pretty sure google/yahoo/etc > are saying no, when I say that for my emails they should trust DKIM2 > results from the iki.fi which will be forwarding my emails to there. > > They have not been able to implement such feature for the ARC, so I am > not holding my breath that they will implement it for DKIM2. > > > 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. > > Recipients can do that, but forwarders can only do that if the final > recipient accepts ARC or some other signal, and allows me to configure > that this forwarder verified DKIM2 for me, and the final recipient > should trust its resolutions and accept email even when the DKIM2 > signature did get broken because of the changes done. > -- > [email protected] > _______________________________________________ > 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]
