I agree with donotexplode. I think that's quite orthogonal to DKIM2. I don't agree about donotmodify. That's really useful, consider something like an invoice with bank details. It's already pretty hard for an attacker to replay one of those (they have to be able to sign as the recipient domain!) but if they can, then not allowing them to substitute the payment target and have it seem legitimate is still a strong protection.
Bron. On Thu, Sep 17, 2026, at 13:09, Tobias Herkula wrote: > 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] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
