J D Falk wrote:
Jeff Macdonald wrote:
I'm a bit behind on this but:
On Thu, Nov 29, 2007 at 03:43:55PM -0500, J D Falk wrote:
I agree, that would be extremely helpful -- but DKIM's i= won't give
it
to us. (Unless you're assuming that these same botnet operators will
allow themselves to be corralled into a single identifer, which
clearly
isn't the case.)
this thinking needs to be applied to d= too. And once you do that,
then the logical conclusion (well, to me :)) is that d= isn't any
better as an identifier.
A bad guy buying another domain name is a threat we already have to deal
with today. It's not a high barrier, but it is a barrier.
The same bad guy having an infinite number of entirely distinct i=
identities at each of those domains would be a new threat, equal to
forging the From: header -- and the obvious conclusion will be to ignore
i= and instead concentrate on d= (along with other reputation inputs.)
The bad guy can still create subdomains and publish keys there: Create
a key under foo._domainkey.sub.example.com and they can sign with s=foo;
d=sub.example.com. In other words, using d= doesn't get away from being
able to create a whole bunch of entirely different identifiers.
Creating key records is really cheap.
This is part of the reason that I consider d= to be just the location
where the key is stored, and nothing more than that.
But since this is about reputation, it's out of scope.
Sure enough.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html