On Thu, 31 Jan 2008, Gregory Machin wrote:
> I'm looking for a working example of all the rules one can apply to
> block spam , thus making spamassasin the last res aught . I'v got alot
> of rules setup but still to much is getting though ..
"too much"? Have you looked to see how much is getting through vs. what
you are rejecting? Is it 50%? 10%? 1%?
When my users grumble they are getting "too much" spam, I have a stock
answer that I send them. I put the "too much" into perspective for them,
and tell them how much spam that we're preventing them from receiving,
because of the checks I put in place. I also remind them that as the
proportion of spam vs. legitimate mail over the Internet goes up, it is
inevitable that a higher proportion will slip through. I comment that no
anti-spam system is perfect, and furthermore that it is an arms race, and
spammers are always working to defeat the checks in place.
> got fake mx records
> got hello syntax checks
> got rbls
Which DNSBLs?
> got grey listing
>
> I'm missing soming thing somewhere ...
Maybe you aren't. Maybe you've reached the point where you're doing all
the 'technical' checks you reasonably can (as opposed to content checks),
and they have reached the limit of what they will match on.
Do you have any 'catchall' mail domains?
What you could do is perform an analysis of the spam that you are
receiving. You may actually find a lot of it is originating from a small
number of hosts or netblocks, in which case you can consider blocking them
directly yourself, either within the Exim config, or by implementing your
own local DNSBL.
The other important thing you didn't mention was introducing delays into
the SMTP transaction, which tends to shed off a lot of the zombie SMTP
engines which aren't programmed well enough to hang around in many cases.
I now use something like the following strategy:
# Delay strategy:
# connect: 5-10s
# helo: 5-10s
# but connect + helo < 15s
# mail: 30-60s if sender not <>
# rcpt: 30-60s first rcpt only if sender not <>
# data: 30-60s
which was based pretty much on something posted to the list a few months
ago (thanks!), and has been pretty effective.
To help to avoid problems with some legitimate hosts, you may consider
adding the following condition to some of your ACLs clauses:
! dnslists = list.dnswl.org
which will cause the clause not to run for hosts listed at the "whitelist"
DNSBL. Read the site to determine what makes them more "trustworthy" than
others.
(In the following, the numbers I quote are from last night's stats run for
my MXs, based on ~800k total connections, ~360k RCPTs refused, and 64k
messages accepted for other processing.)
In your HELO checks, ensure you are rejecting offers of your own name/IP
address:
Rejects/HELO checks: total 46576
: is my own domain 57
...
(This proportion used to be a lot higher, I guess spammers have learned
not to do this now).
Also in the HELO checks:
: not fully qualified 33279
: contains underscore (rejected) 336
Also, if you can, change the IP address of your MXs, especially if you
have had the current ones a long time. You will find many spam engines
keep a cache of MX records associated with domains rather than look them
up at spam time.
Rejects/local criteria: total 14802
: connection on legacy IP 14080
...
Of the DNSBLs I use:
Rejects/DNSBLs: total 229543
: Spamhaus 221450
: PSBL 5608
: Sorbs 1609
...
(As you can see, DNSBLs, and Spamhaus in particular, are the most
effective defence).
PSBL raises one or two queries a week, SORBS maybe a little fewer over the
month. Once I have explained the issue to complaining people (either the
intended recipient, or the sender), and methods of resolution, I generally
don't hear from them again. It's not often I find out if they a) fixed
the original listing problem, b) gave up, c) found some other solution, d)
grumbled to all and sundry about how my site is "the only one that has a
problem with my mail", ... I like to hope it is mostly a), but I don't
lose sleep over them grumbling if they aren't willing to actually come
back and talk to me again.
> Or is there anyone willing to look at my configs and advise me if they
> got the time ...
If you post the salient parts of them, people may look.
Marc Perkel uses a number of techniques which he claims improve the
situation for him. However they are usually not without risk or their own
problems; I'm sure Marc will speak up, otherwise there are plenty of
suggestions from him in the list archives.
Don't forget that the more checks you implement, the more likely it is you
will have false positives. The acceptability of these false positives
depends almost entirely on your user base, so you have to bear that in
mind evaluating any other 'tricks'.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK
