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