Absent SSP (or something like it), then in the broad sense of the
word, DKIM does need some kind of reputation system to be effective.
That depends what problem you're trying to solve, since there are some
that only involve validating that the sending address is real without
caring if the sender is nice or nasty.
A simple example is mailing list signups: if a subscription request
shows up and it has a DKIM signature from a domain that matches the
address that's signing up, I think it would be reasonable to skip the
confirmation step, without any reference to the signer's reputation.
I agree that there are plenty of other applications that will need an
implicit or explicit reputation system, but the basic problem that
DKIM solves is address forgery in e-mail. There's all sorts of other
problems that forged addresses enable, but that's beyond the scope of
the threat.
If we turn back the clock and imagine that we were the group
standardizing HTTPS, it's like people are saying yeah, it'll keep
people from snooping on the traffic, but now you have to explain
whether you're keeping people from snooping on passwords or on credit
card numbers or software downloads or copyrighted e-books or what, and
then get into arguments about whether it would be better to generate
single-use credit card numbers, couldn't you just serial number the
e-books to detect pirate copies, etc etc etc.
The problem is mail address forgery, we all agree that DKIM is a
reasonable way to address it, and for the purposes of the WG there is
no need to get into what other higher order problems might or might
not be solved thereby.
R's,
John
PS: If this sounds like I don't care whether we do SSP, that's right,
but it seems to me that SSP is at worst harmless so there's no reason
not to do it so long as it doesn't get in the way of the main job.
_______________________________________________
ietf-dkim mailing list
http://dkim.org