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