John Levine writes: > It appears that Hannah Stern <[email protected]> said: > >Hi! > > > >The draft says: > > > > If a verifier receives a message with a donotexplode request and > > a later hop has indicated that it has exploded the message then > > the message SHOULD be rejected. > > > >So according to how I'd plainly read it, the verifier would only check > >if any subsequent hop has the "exploded" flag. > > > >However, what if a hop explodes the message without setting the flag? > > I think donotexpode is advice to cooperative signers since as you note, > there's no way for subsequent signers to check. I'd think that if a > mailing list implements DKIM2, it would reject or at least hold for a > moderator anything with donotexplode.
I think the whole idea of sender giving mandates to the whoever is receiving the email is wrong. The sender should NOT give instructions who to process the email, it should tell what are the properties of the email it is sending out. The DMARC has exactly same problem with p=reject/quarantine/pass. It tries to mandata receiver to do something, instead of telling what are the properties of the original email that receiver should be able to see. So instead of donotexplode the sender should say something like "onerecipient", meaning email was meant to be sent to one recipient. I mean even if there is only one final recipient, email might still get "exploded" towards multiple mail boxes. For example in iki.fi it is very common that people forward their emails towards multiple mailboxes, i.e., both towards their personal mail box and also send copy to their work email address. Quite often there is also third copy sent to the iki.fi backup read only www-mailbox, which they can use to check emails which did not reach their mailboxes... This would still be completly ok with "onerecipient" type of flag, as we are still talking about one recipient, just multiple mailboxes. On the other hand sending such email to the role email address, where it is distributed to group of people (and which is not really a mailing list) could cause the system to do something different. What is the intended use for the "donotexplode" flag? When would you be setting that flag when sending email? Why would it be useful for you to send that flag? One use I can think of is some kind of login by email code thing, but in that case donotexplode is completely wrong thing to do, onerecipient or similar would be much better description. I myself for example do "explode" all emails I receive to two mailboxes just because of those "login by email code" things, i.e., I use the iki.fi read only www-mailbox to get those one time login codes, because it is faster than logging in to read my emails. > >For "donotmodify" it's specified that header fields may be added still. > >If the recipes were optimal, that would mean that there are only "c" > >entries. However, if a site reorders existing fields, it would need to > >use "d" at least somewhat (due to the monotonicity requirement on copy > >rules), and of course if a site is extra simplistic it might use "d" > >even when "c" would work. So in the end we'd possibly need to create a > >set of fields in the new version, and for each header field in the old > >version, check if it's in the new set? Or how would you implement that? > > That does seem ugly, doesn't it? On the other hand, I'd think that it > wouldn't be hard to keep the new headers or maybe a set of hashes, and > check them after the changes are undone. If DKIM2 will have the diffs of changes happening, why would we even need "donotmodify" flag? What is that flag trying to say? 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? Why would I need to explictly say that I do not want this email to be modified, I would assume that the default is that email should not be modified unless there is good reason for that, and if there is good reason for that then the system doing that will ignore that flag anyways? -- [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
