At 03:42 21-03-2009, John R. Levine wrote: >We really need to reset our vision from the blacklist model to whitelist. >With blacklists, there's no fundamental difference between the behavior of >bad guys and good guys, we're forced to use complicated ever expanding >heuristics to try to tell the difference, and we constantly have to change >them as bad guys adapt whatever behavior we attribute to good guys. But >with a whitelist model, you say here's what a good guy does, you design it >in a way that bad guys can't fake, and you're done. If it's properly >designed, it doesn't have to change every time there's a slightly >different attack, and the simpler it is, the less likely actual good guys >are to screw it up. Hence simple, constrained interfaces.
I don't see much benefit in using DKIM for a blacklist model where we have to play catch-up with the "bad guys". Using DKIM only to move from IP address to domain based reputation gives us IP address independence only. It is easier to sign using one domain if the end-result we seek is only to create an input for a reputation system which assesses the sending MTA. The downside is that we are replicating the current "IP address model" with its disadvantages. >I have my doubts about the utility of any added output, since I don't >believe there's anything a sender can say that will inherently increase >its merit to receivers. The best you can do is to put in hints of where >they might find favorable info from credible sources. Hence the assessor >uses the d= to look in some local database and see what it thinks of the >domain. It's also the way we designed VBR -- it doesn't matter whether >the VBR-Info header is signed, because the recipient isn't going to >believe anything it says without checking first. That's one way to use DKIM. This brings us back to the question of whether we should constrain the specification to do that only and leave any other uses to extensions or experimentation. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
