On Aug 24, 2010, at 1:30 PM, Mark Delany wrote: >>>> As a part-time MTA developer I am not confused. The DKIM signature >>>> provides a simple piece of trace information ("I handled this mail") >>>> that is cryptographically bound to some header and body content. >>> >>> Yes. And that the obverse is possible: "I didn't handle this mail". >> >> I don't see how DKIM can provide the obverse - the obvious way >> is for a sender to assert that all their mail has a DKIM signature, >> but that fails when the DKIM signature breaks in transit. Is there >> a clever trick I'm missing? > > So you're saying it can provide the obverse; you just don't like the > failure modes. Perhaps surprisingly, the failure modes are exactly > what attracts some folk to DKIM.
The failure modes of DKIM are all false negatives, which is fine. (Concrete example: I've not seen any suggestion that there has been mail that was signed by paypal.com that wasn't from paypal, and I suspect someone would have mentioned it). The failure mode of anything that's based on the inverse of DKIM are all false positives. While you can assert "I didn't handle this mail", that's not an assertion that can be trusted, in general. (Concrete example: I've seen email that paypal.com asserted was not sent by them, based on lack of DKIM signature, which actually was sent by them). I'd be surprised if that failure mode attracted people to DKIM, and I'd be interested to hear more about why it did. "I'm pretty sure I didn't handle this mail" is a an assertion that you can make in this way, though, and the level of certainty is going to be high enough to be of value in some cases. But it's not quite the same thing as being able to say "I didn't handle this mail". > We also have to be patient. When DK was first discussed, folk said > that it was impossible because MTAs routinely made arbitrary changes > to the payload, but that's no longer true. Folks also said that the > mainstream players would never get on board, but that's no longer > true. > > A fork-lift change was never going to occur overnight so we just have > to keep chipping away. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html