Re: [Asrg] Re: Asrg Digest, DNSBL BCP v.2.0

At 11:19 PM -0500 3/2/07, Stephanie Erin Daugherty wrote:

> I'll agree that its a horrible idea. At one point, a DNSBL could 
> effectively stop a lot of spam. Now, most DNSBL operators and DNSBL 
> users have realized that the technology long ago ceased to be useful 
> in stopping all but the most persistent and long-lived spam sources, 
> and compromised hosts.
That is not consistent with the evidence I have on hand.

I deal with multiple receiving sites (corporate and microdomain) and 
know of none where the CBL fails to reject over 2/3 of all SMTP 
connections or has ever had a detectable false positive rate greater 
than 1 per million rejections over a period of over a month, with the 
false positives coming in very brief episodes (commonly describable 
as the consequences of ill-considered NAT designs.) For most sites, 
the reject rate is usually in the 75-80%.
The Spamhaus XBL and Zen lists enhance that performance by 5-10% by 
aggregating the CBL with additional lists, and while I've used them 
for relatively short times (< 6 months) on anything but very small 
sites, I've been unable to find any increase in false positives.
As a first cut against spam, applied without having to examine 
anything other than the connecting IP, DNSBL's remain extremely 
useful.
> So, you might ask, what are DNSBL's still useful for? Mainly, four things:
> * Keeping track of compromised hosts, because they present a threat 
> to the internet as a whole.
> * Keeping track of hosts that shouldn't be sending mail - machines 
> on networks where servers aren't allowed for instance.
That's basically the model of the Spamhaus XBL and PBL.

> * Brute-force education of end users and server administrators about 
> community standards of security and acceptable behavior on the 
> internet.
> * Bringing the problems that allow spam and other network abuse to 
> the wallets of those who can do something about it.
> It's that last one that's the big one.
Yes, but I think you've missed another application. Applying the 
Spamhaus SBL as a "URIBL" by checking body URI domain parts for 
resolution to SBL-listed address space is usefully effective against 
spam that makes it past CBL and its derivatives. The numbers 
fluctuate wildly (10-40% of what gets past traditional DNSBL 
application) based on fluctuations of DNSBL effectiveness and spammer 
behavior.
> Unfortunately, there are some providers who wouldn't kick spammers 
> off their network, if not for the fact that DNSBLs would soon force 
> them out of business.
I think that's an appealing story that does not always describe 
reality. I know there are some providers who respond to listings, but 
there are some who simply don't, and are unimpeded by that for years. 
The entity formerly known as UUNet (finally seeming to clean up a bit 
since the VZ acquisition,)  the 'new' AT&T (i.e. SBC,) Comcast, and 
the Chinese Internet oligopoly seem impervious to the supposed 
business  impact of DNSBL's.

> DNSBLs are unfortunately very good at this one thing - making "not 
> my problem" a big enough issue that ignoring security, permitting 
> abusive behavior, or ignoring the basic principles of the internet 
> becomes costly enough to become a problem worth fixing.
Not for all providers.


> As a DNSBL operator, I don't like this aspect of it, but it's the 
> same principle as behind things like the infamous UDP 
> (http://www.stopspam.org/faqs/udp.html).
The UDP worked better when it was applied than anything in email can 
because the news network is built on a fundamental building block of 
explicit and strictly bilateral agreements to pass traffic. Sites 
that have agreements with everyone they accept mail from don't have 
major spam problems.

> Ultimately, a DNSBL does not stop spam.
But, they do. I see DNSBL's stopping most spam at multiple sites.


--
Bill Cole                                  
bill(_at_)scconsult(_dot_)com

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg