Agreed with Bron, I don’t yet see a useful use-case for donotexplode and would support removing it. Donotmodify does seem useful for senders that are sending sensitive content as Bron described.
Best, Emanuel On Thu, Sep 17, 2026 at 3:32 PM Bron Gondwana <brong= [email protected]> wrote: > 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
