dnsbl'S + bogofilter = spam barbecue

[Chris Fortune]

> 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

Objective?  You have to be very careful.  There are a lot of considerations before you hand over blocking to DNSBLs.  For example I
do NOT use the dnsbl.sorbs.net Aggregate zone.  Here's why:
- block.dnsbl.sorbs.net - List of hosts demanding that they never be tested by SORBS.
- dul.dnsbl.sorbs.net - Dynamic IP Address ranges

So, if your mail server is temporarily misconfigured or vulnerable and SORBS tests you and puts you on their list, then you get
angry and demand that they never test you again, you are put permanently on their block.dnsbl list.  Or, if you decide to run a
server from your home using the wonderful Dynamic IP Address technology, you will be blacklisted by SORBS.  I don't see how this is
objective.

xbl.spamhaus.org at one time listed Dynamic IP Addresses, but then later dropped them.  Will they list them again in the future?
How would you know?  They got in hot water for it the last time, maybe they won't bother to print it on their website the next time.

rfc-ignorant.org lists servers that are misconfigured but running.  But is that good judgement to block mail?  For example does all
mail coming from a small rural server run by a non-English speaking computer student deserve to be blocked just because it isn't set
up perfectly?

This is a spam war we are in, but like soldiers, it's our duty to reduce "collateral damage".  That is, innocent civilians shouldn't
be gunned down.  There should be a lot of evidence to justify blocking, and that's why I don't block mail outright unless the IP is
listed in at least three non-overlapping DNSBL databases, and let bogofilter + network tests + heuristic filters + user filters deal
with the rest.  It's expensive, but the results are worth it: no false positives.


> 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.
>
Strongly agree, but for _all_ dnsbls, because they are _all_ _subjective_.  IMHO bogofilter fixes the problem very _elegantly_
because it treats the output of the DNSBLs as just another token.



> 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.
>
ipchains demands very low! resource usage, and heartily recommended for busy servers, but is not easy to set up.   Go Jef!  I
already customized ASSP (written in perl) to include bogofilter at SMTP time, and it gives me a warm bogo-glow every time I check my
mail log!   Works amazingly well, but resource heavy - Unix fork() helped a lot!

Chris Fortune,
http://spameater.com/
Thanks for supporting anti-spam R&D



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 10/29/2004