I would like to restart the discussion around the donotmodify and donotexplode flags.
I understand why senders would like to be able to express these preferences. However, I am still not convinced that they belong in the core DKIM2 specification. In practice, local receiver policy and ultimately decisions made by the recipient have always taken precedence over preferences expressed by the sender. A receiving system may need to modify a message as part of its local processing, and a recipient may have configured forwarding, aliases, mailing lists, filtering or other processing which results in a message being modified or delivered to more than one destination. This becomes particularly problematic if such preferences have consequences for later verification. At that point they are no longer merely descriptive information or a sender preference; they start influencing what downstream systems are permitted to do with the message. I think DKIM2 should primarily authenticate and describe what happened to a message, rather than define sender policy about what must not happen to it. For that reason, I think donotmodify and donotexplode would be better handled in a separate policy document. Such a document could define sender preferences and the semantics around how receivers may choose to interpret them, without making them part of the DKIM2 authentication mechanism itself. It could also become the natural place for other policy concepts that people may still consider useful from DMARC once DKIM2 is deployed. My expectation is that much of what DMARC provides today becomes unnecessary when DKIM2 provides the underlying authentication properties directly, but that does not mean every policy concept around message handling necessarily disappears. Keeping those concerns separate would give us a much cleaner model: DKIM2 authenticates what happened and who took responsibility for it. A separate policy layer can express what a sender would prefer to happen. Local receiver policy and recipient decisions remain authoritative. That separation seems considerably easier to reason about than embedding sender policy constraints into the DKIM2 protocol itself. -- 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, Dr. Michael Hagenau, Thomas Ludwig, Dr. Verena Patzelt 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.
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
