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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf