Maybe I should read the other 22 posts before jumping in "RFC 4871 gives no precise definition of what an "assessor" can use to make whatever decisions it wants to draw from the message *and* the signature(s). "
correct and it should stay that way Bill Oxley Messaging Engineer Cox Communications, Inc 404-847-6397 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Thomas Sent: Friday, March 20, 2009 9:39 PM To: John R. Levine Cc: [email protected] Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata John R. Levine wrote: >>> We seem to have a fairly basic disconnect here. As far as I'm >>> concerned, an assessor has better things to worry about than the >>> internal details of the signature. Trying to reverse engineer or guess >>> what the signer had in mind would be a hopeless swamp even if it were >>> desirable. ... > >> If assessors can't be bothered, then how will reputation systems know >> the >> difference? > > Sorry, but I have no idea what the antecedent to this question is > supposed to be. The difference between what and what? > > > You wrote: > Sure, it's possible to put on a worthless signature that leaves out > crucial headers, but signers who do so won't get a very good > reputation so the problem should be self-limiting. There's no > existing installed base of inept signers we have to work around, and > it would be a poor idea do anything that would allow crummy signatures > to appear to work. If assessors can't be bothered to assess the supposedly "self-limiting" "implementation details", then reputation systems can not take them into account. By definition. > Assessors know whether a message is signed, and if it has valid > signature(s), the domain(s) that signed them. All that other stuff in the > signature is implementation details. RFC 4871 gives no precise definition of what an "assessor" can use to make whatever decisions it wants to draw from the message *and* the signature(s). That you have a particular use case in mind that doesn't care about "implementation details" does not and should not imply that that is the only valid use of DKIM information. That is why the errata is so wrong headed. Mike _______________________________________________ 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
