dnsbl'S + bogofilter = spam barbecue

[Tom Anderson]

From: "Chris Fortune" <cfortune at telus.net>
> a satisfying method.  Careful selection of DNSBLs is required, and I took 
> a long time to test and investigate.  Check out this
> highly recommended page:  http://www.scconsult.com/bill/dnsblhelp.html

Good article.

> I abandoned DNSBLs completely for several months because they were 
> unreliable as a single point of authority (for reasons...
> Ouch!  Disagree.  The tools are supposed to solve the problem, not create 
> new ones.  DNSBLs are famous for their poor management and
> innacuracy.

This would be true of subjective lists, for example, as the above link 
points out, SPEWS, Spambag, MAPS, SBL, and ORB.  However, other lists are 
purely objective, eg:

http.dnsbl.sorbs.net only lists open HTTP proxies
socks.dnsbl.sorbs.net only lists open SOCKS proxies
smtp.dnsbl.sorbs.net only lists open SMTP relays
web.dnsbl.sorbs.net only lists webservers with vulnerabilities abusable by 
spammers (formmail, etc)
list.dsbl.org only lists servers which specifically request they be listed 
(usually open relays/proxies)
xbl.spamhaus.org lists servers with exploits including open relays/proxies, 
worms, virii, spyware, etc.
dsn.rfc-ignorant.org lists servers which do not accept email bounces
postmaster.rfc-ignorant.org lists servers which don't have a working 
postmaster address
bogusmx.rfc-ignorant.org lists servers whose MX points to private, local, 
loopback, etc., IP space
whois.rfc-ignorant.org lists servers which have missing, incomplete, or 
incorrect whois data

The above are all directly testable and not at all subjective.  Anyone 
listed in those lists is either incompetently running an insecure system or 
maliciously spamming people.  The only possible false positives will occur 
when an IP address has changed ownership, and each of those lists has a 
mechanism to remove an address in such a case.  Moreover, if someone takes 
ownership of a previously blacklisted address, they can ask for a different 
one from their provider.  These lists are neither inaccurate nor poorly 
managed lists AFAICT.  In addition to the above, I'm using sbl.spamhaus.org 
because they specifically list their foremost goal as eliminating virtually 
all false positives even though they maintain a somewhat subjective list of 
well-known and verified spammers, and I've heard of no complaints against 
this list.  BTW, I've dropped relays.visi.com since it wasn't blocking 
anything that wasn't caught by sorbs first.  After several days now running 
these blocklists, I've eliminated about 80% of my spam, and I haven't had 
any false positives.  I still get nearly the same number of false negatives 
and about half as many unsure spams getting through bogofilter, which 
implies that the smarter spammers (the ones able to fool bogofilter) are 
staying off of the blocklists.  It sure does free up system resources 
though.

>> I'm interested in the MTA implementation in order to block spam at SMTP 
>> time
>> and never have to receive or process it with bogofilter.
>
> Yes, many a sysadmin of a large mail server has dreamed of this day.  For 
> now, a multi-level filtering approach is more advisable.

I'm using the above listed _objective_ dnsbls and rhsbls to reject outright 
with a descriptive bounce, coupled with bogofilter to classify the 
remainder.  Perhaps adding a step between the two to feed the _subjective_ 
dnsbls and rhsbls to bogofilter would be a good idea.

> This feedback mechanism looks like a good re-use of information resources, 
> provided that IP addresses are accurate!.  Somebody once
> posted a Linux recipe to this list that bans IPs at the kernel level using 
> `ipchains`.  Bogofilter was the filter of choice.  That's
> a nice way to do it: bogofilter decides bogosity (in concert with DNSBLs), 
> IP address is saved to a db and count is incremented,
> (optional - greylisting, or adding a factored count to bogosity score), 
> once a data row reaches a threshold count then it is no
> longer a vote but becomes a veto: ipchains is notified and the IP address 
> is also entered into a local blacklist for x hours.  Data
> rows are decremented every x hours to flush IP addresses out.

I wonder if I even have ipchains compiled in my kernel...  I think dnsbls 
seem to be the easiest solution.  I look forward to Jef posting his milter.

Tom