On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote: > On 10/16/2010 10:26 AM, John R. Levine wrote: > >> Yes, it ties an identifier to a bag of bits, and yes it specifies what > >> those bits are, but it really does deal only with those bits and not > >> (necessarily) the entire message. > > > > Technically. you are correct. Semantically, that's silly. > > > > We went through backflips trying to figure out how to design the > > signatures so that the message modifications they allowed would preserve > > the same message, for an ill defined but I think well understood version > > of the same. > > Yes that was the goal. No that was not the result.
-1. I think we did that just fine. > Which header fields are essential to protect? How much of the message body > is essential to protect? This is completely orthogonal to the question. As long as a receiver can reliably determine what is protected and what is not, then the protection goal is achieved. It does not require that there is agreement on what that should be. > The current DKIM spec does not answer these questions and easily permits > protecting very little of the message. Almost certainly too little to > ensure the protection you assert. One can also point a gun at ones own head. That doesn't make a gun a suicide device of no value for anything else. The spec does permit people to do silly things, but so what. > That's an example of what I mean when I says that there are assumptions > about DKIM that go beyond what it (always) delivers. Saying it's possible to use DKIM in ways that doesn't support this is not the same as saying DKIM doesn't support it. It's possible to operate any modern MTA as an open relay, but it doesn't follow that all MTAs are open relays or that they fail to protect against open relaying. > I guess I should thank you for demonstrating my point. If you had one that relevant to the discussion, it's not at all clear to me what it was or how it was demonstrated. > > While it's always been possible to sign messages in ways > > that allow gross changes, e.g. don't sign the subject or MIME headers, > > set l=0, if you sign a message using a normal set of options, the idea > > was always that the message the recipient saw would be the one you > > signed. Throwing up our hands at the double header trick is, one might > > say, ahistoric. Claiming it's an MUA problem is simply wrong. > > 1. Your first sentence concedes my basic point > > 2. There is no commonly-agreed upon and documented concept of "normal set > of options" that I'm aware of. What is normal for you might or might not > be normal for the next person configuring DKIM. True, but irrelevant. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
