Hi all, John's comment about donotmodify made me wonder about the default semantics of this flag.
Personally, I would expect that, when donotmodify is absent, the default behaviour should be equivalent to donotmodify=yes. In other words, modification should require an explicit indication from the signer that it is permitted, rather than requiring the signer to explicitly state that modification is not permitted. This seems particularly important considering the examples being discussed here, such as changes to URLs, amounts, or other security-sensitive content. From a safety perspective, I would find it more intuitive for "do not modify" to be the default, with permission to modify being explicitly granted when appropriate. Is that already the intended interpretation? If not, would it make sense to consider this as the default behaviour? Regards, Pietro -----Messaggio originale----- Da: John R Levine <[email protected]> Inviato: mercoledì 12 agosto 2026 03:36 A: Wei Chuang <[email protected]> Cc: [email protected] Oggetto: [Ietf-dkim] Re: DKIM2, fromMunging, and recipes On Tue, 11 Aug 2026, Wei Chuang wrote: > lists. I was describing the implications of a DKIM2 pass which does > not say anything about safety. Instead I was trying to say that > someday a safety validation such as DMARC, could be built using DKIM2, > though that linkage between DMARC and DKIM2 does not exist today. I have two somewhat contradictory thoughts. One is that if I think that changing the content of my message is bad, I can say so, and if I don't say so, why are you second guessing me? The other is that it's hard to think of scenarios other than security gateways where it makes sense to change the URL in a message. In DKIM2, just like DKIM1, just because the signatures are valid doesn't mean the message is nice or wanted or benign. I could easily imagine a heuristic that makes a URL change a strong spam signal. R's, John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected] -- Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto. Seguire il link qui sotto per segnalarlo come spam: https://mail2.mcnsrl.it/action/4hKWKD3xFyzGprm/report-as-bad _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
