Far be it for me to defend Dave, but I think you two are in violent agreement. I think you misread some of Dave's comment because they were posed as rhetorical.
Mike On 10/16/2010 11:56 AM, Scott Kitterman wrote: > 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
