dnsbl'S + bogofilter = spam barbecue

[Chris Fortune]

> From: "Chris Fortune"
> > Any single DNSBL can be mistaken, so mail should not be rejected if it is
> > listed on only one DNSBL.  To be careful query 4 of
>

> From: "Tom Anderson"
> That's a good idea as long as the ones being compared are all checking for
> the same standard.  For instance, you can't compare a list that tracks open
> relays to one that tracks improper MX records.

That's a good point, I thought of it when I first investigated DNSBLs and designed a data structure for lists of various types, but
soon abandoned that approach for reasons I can't remember, probably because it needs research and statistical analysis to arrive at
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

I abandoned DNSBLs completely for several months because they were unreliable as a single point of authority (for reasons already
mentioned by Jef P.), and bogofilter did such a great job anyways.  I returned to DNSBLs because they are so computationally cheap
it seemed like a shame to not use them, but how to use them in a way that gives them a vote, not a veto?


> The fact that any mistakes
> are simply bounced with the cause listed makes me fairly secure in
> implementing just one list for each standard, as the sender can always try
> contacting in a different fashion if important, or else try to get
> themselves off the respective list.
>

Ouch!  Disagree.  The tools are supposed to solve the problem, not create new ones.  DNSBLs are famous for their poor management and
innacuracy.


> 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.


> However, I'd love
> to use bogofilter to supply my own dnsbl list based on spam that gets
> through.  This way, if an address spams one account, it can be blocked
> before it spams another.  Unfortunately, I don't have time at the moment to
> research this.
>

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.



---
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/30/2004