der Mouse wrote:
But DNSBLs can't solve the problem when spam is sent via botnets.
That's actually true, but not for the reason you imply. DNSBLs can't
solve the problem _at all_; it's a social level problem and requires a
social level solution. Wnat DNSBLs do is mitigate the damage so that
we have at least middling-usable email while solutions evolve at the
social level.
I should also point out that that his original reason (BOTs re-DHCP'ing
themselves too quickly for DNSBLs to be effective) simply isn't borne
out by experience.
Many ISPs force DHCP IP-affinity significantly, and it's kinda hard for
most BOTs to force their cable modem/access router/whatever (which is
the real holder of the DHCP address) to refresh. But beyond that, it's
our experience that most BOTs emit from the same IP for at least a day
or two, and it's entirely common to see the same IP emitting from the
same BOT for weeks and in some cases for 6 months or longer. Often
multiple BOT types at the same time, emitting different campaigns. etc.
We are using technology that detects many BOTs (eg: Srizbi, Storm,
Cutwail etc) in real time - about 70% of all "infected PC" spam is
identifiable in our implementation. The CBL is purported to target the
same sorts of things. It's been our experience that if we had been
forced to rely on the CBL alone and not our real-time detection, we'd
"miss" at most 10% of the BOT spam (ignoring all other detection
methods), and usually closer to 2-3%. That's an impressive success
rate, and disproves any notion that DNSBLs are inherently too slow for BOTs.
[Our sample size is on the order of 20M-50M emails per day. So I don't
think we suffer from being too small to infer useful results from.]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf