John R Levine writes: > On Thu, 13 Aug 2026, Tero Kivinen wrote: > > I think the whole idea of sender giving mandates to the whoever is > > receiving the email is wrong. The sender should NOT give instructions > > In general I agree with you but that ship sailed a decade ago.
So because DMARC and others have been written that way, we cannot change that it in DKIM2? I was assuming DKIM2 is going to be something new, and better, so we should change this aspect of it also. > > So instead of donotexplode the sender should say something like > > "onerecipient", meaning email was meant to be sent to one recipient. > > It's just a token the software looks at. It could equally well be > "qokxonr". That would be better than donotexplode, as do not explode is something that people will be interpreting when they are writing their implementations. > > What is the intended use for the "donotexplode" flag? > > Same as what you said, mail intended for a single recipient. So why not say that so. Why format it as mandate to recipient? It would better to provide it as statement. > > When would you be setting that flag when sending email? > > Receipts, bank statements, password resets, anything that is clearly for > one recipient. Actually I do still want those even if it gets duplicated to my two mailboxes... > > Why would it be useful for you to send that flag? > > To discourage mailing lists and the like from forwarding it if someone > accidentally or maliciously sends it such a message. Mailing lists have been implementing ARC, why do you think they would implement this? There is no benefit for them to implement this. Yes, it might catch someone accidently typing mailing list address to the password reset prompt, but how often that really happens? > > Yes, I can see all spammers and phishing attacks using that flag, as > > they do not want anybody to modify their urls or adding ugly "this > > email is from external source" warnings to emails, but what other use > > there is for this flag? > > Same as above. I don't want them modifying my password reset URL either. > It's advice to systems that modify mail that this message is not one they > should forward. As those emails should NEVER include URLs that user is expected to click, destroying all those emails would be beneficial, but if there are no URLs or other dangerous things, only the login code you need to log in, then security gateway adding "this email is from external source" deleting my login emails instead of passing them forward with warning is not helping the user... So I do not really see any real use for donotmodify flag. I was trying to think what would be the actual meaning for the sender end for that flag, and could not think of better name for it (like "onerecipient" for "donotexplode")... If people can't provide useful meaning for that flag from the sender point of view, I think we should remove it. -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
