On Sat, 3 Jan 2004, Tim Jackson wrote:
> meantime can I suggest you remove bl.spamcop.net from your list? Although
> useful, it's very likely to cause you a significant number of false
> positives (and hence likely to upset people). Much better to just assign a
> modest spam score to it if you're using SpamAssassin.
Good advice. But an alternative strategy that might be worth
considering is to block when the IP appears not only in spamcop (i.e
"has proven to relay spam") but also in at least one of the technical
open-relay/proxy/etc lists (i.e "is technically capable of being used
as a spam relay").
In fact, we're currently doing both - spamassassin points for being in
one of the two kinds of lists, but block at RCPT time if the IP is in
both kinds of list (thus saving the overhead of spam-rating, and any
remaining potential risks of rejecting at end of DATA).
Just in case this isn't obvious, it's a matter of having two
"dnslist" clauses in the same "deny", e.g:
deny hosts = +rbl_hosts
[...]
dnslists = bl.spamcop.net : spam.dnsbl.sorbs.net
dnslists = relays.ordb.org : list.dsbl.org [..etc..]
[...]
Other technical lists to be considered for the second test at the
present time might be
: smtp.dnsbl.sorbs.net \
: web.dnsbl.sorbs.net \
: zombie.dnsbl.sorbs.net \
: dul.dnsbl.sorbs.net \
: dnsbl.ahbl.org \
: l1.spews.dnsbl.sorbs.net
- if you're not already outright blocking on one of other of those.
(But these details change quickly as the spammers wipe out this or
that DNSrbl and the anti-spammers retrench, so you need to keep an eye
on developments).
In current versions of exim 4, it would be more efficient to test the
value(s) returned by dnsbl.sorbs.net, rather than testing their
individual domains. But until we get to upgrading ours from 4.14, I
gather that multiple return values aren't supported, so for best
results we need to test as above.
cheers
