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. >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. R's, John _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
