On Sat, Sep 26, 2026 at 8:35 AM Richard Clayton <[email protected]> wrote:
> I think that there is (a) a strong case for removing "donotmodify" from > the DKIM2 spec itself and -- simultaneously -- (b) a strong case for > senders to be able to signal that they think that intermediaries should > not make particular types of change to their email (and if they feel > that it unacceptable, that they should reject the email). > > Since some modifications are more benign than others there is a case for > attempting to define a new LimitModification: header field (the header > field name is a strawman) for discussion. > > We then define some "obviously safe, common and useful" modifications > such as pre-pending up to 15 ASCII characters to the Subject header > field, adding a plaintext header or footer etc. and systems would then > process mail with regard to whether modifications went beyond that. > > If we (or us-over-in-MAILMAINT) cannot agree that these modifications > are safe, useful (or can be verified to have occurred) then we pack our > tents and go home. Otherwise, we might be able to make modifications > that are unsafe (or hard to verify) a thing of the past. > > Either way, we do not hold up DKIM2 deciding whether we are trying to > boil and ocean or a small pond. This seems reasonable to me. In my mind, saying "modifications isn't allowed" really means the same thing it does in DKIM1 today, which is, "if you modify" then you need to munge the fromHeader to take clear ownership. The value I see of donotmodify right now is allowing a sender (for example google.com) to specify on a per-message basis rather than on a per-domain basis whether modifications are allowed (a DKIM1 signed mail with p=reject means no modifications allowed). That is some theoretical value, but I haven't yet heard anyone who specifically is raising their hand and said they would make use of that. And I would guess that security sensitive senders won't be rushing to relax their requirements anytime soon. So it seems okay to get rid of donotmodify and focus on defining a more useful "allowedModifications" header which would define which kinds of modifications the sender is okay with for that message (empty set would be equivalent to donotmodify). Strawman definition of category of modifications: subjectText, footerTextAddition, headerTextAddition, anyTextAddition, footerAddition, anyTextAddition, any. Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
