>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
