John Levine writes: > It appears that Tero Kivinen <[email protected]> said: > >> > 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. > > Perhaps I am overoptimistic, but I hope people read the fripping RFC > before they write their code rather than just guessing what a token > means.
Implementors who actually implement it might do, but the people who turn them on definately are NOT reading RFCs before enabling features in the software they use. And implementors do use same terms that are used by the RFC, thus what term we do pick for RFC will affect the implementations and the adminstrators who are turning on those features. Looking how badly consultants are explaining what p=reject means for the DMARC > >> > 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... > > Implementors are allowed to use some intelligence. I don't think it is > all that hard to say that some small number of copies of a donotexplode > message is OK, particularly if they don't have other characteristics of > list mail. What do you have against changing this to explain what are the properties of the email instead of giving bad instructions to the recipients? I get a feeling from your objections that you somehow think that we should keep donotexplode, is that correct? Why do you think we should keep that name? > >> > 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? > > The obvious answer is to keep junk out of their lists. > > The donotexplode flag has utility for large mail systems. As I think > Bron said, if across a mail system they see 100 or 1000 copies of a > donotexplode message, they know something is wrong. (Two or three > copies would presumably be OK.) You and I have mail systems too > small to do that but I could imagine something like DCC that passed > around message-ID hashes so we could share bulk measures. And what do you expect those large mail systems do when they receive the first 10 copies? What about after 100 copies? DO you explect them to start rejecting them at some point? What is the number of copies they should start putting it to the spam folder? Do you think they should at some point start rejecting the email? > >> > 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, ... > > Um, you seem to be using a different Internet than the one I use. Password > reset messages have URLs all the time and no amount of telling people they > are stupid (even if it were true) is going to change that. More, and more often I see an email that has code that I need to cut & paste to the login in password recovery prompt. This is mostly because security experts have been complaining that DO NOT send links, DO NOT click on links, and never ever login through a link you get in the email. For example M3AAWG has been trying to teach this for years. I am optimistic that at some point we will get more secure systems and there will not be password recover links etc sent in email. I would really like to also have mandate that would require every mail system to show the actual domain name of the sender email, but I am not that optimistic that ever happening, even when that would provide much better protection against phishing attacks than DMARC/DKIM etc ever can... -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
