This topic seems to come up every other week. Could we make a rough consensus call on it? I agree with Richard that the "donotmodify" flag should not be part of DKIM2 and would be better documented separately by those who have a stake in its importance.
-- Best regards, Tobias Herkula Head of Mail Transfer Development Mail Backend Development 1&1 Mail & Media Development & Technology GmbH www.mail-and-media.com Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 Geschäftsführer: Alexander Charles, Thomas Ludwig, Dr. Verena Patzelt, Marc Sier Member of United Internet This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. ________________________________ From: Richard Clayton <[email protected]> Sent: 26 September 2026 17:16 To: [email protected] <[email protected]> Subject: [Ietf-dkim] removing "donotmodify" was: Call for Agenda Items: September 23 Interim -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <[email protected]>, Tero Kivinen <[email protected]> writes >We have been trying to teach both senders and receivers that do not >send links, and if someone sends you links do not click on them. everyone should have a hobby ... but you will never achieve either >But the main point was not really about the links, but the actual text >changes. Do we really need such capability at all, or can we consider >all of those being malicous? And I am talking about changes or >deletions, not additions to the end or beginning of email. 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. - -- 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/AwUBarfh2mHfC/FfW545EQIgbACgxdnPWVoAWoJ8s5H/d077rigqcOwAoLJ0 h6dy99syl28ldwDDRwvDs1jn =r95x -----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]
