sysadmin@??? wrote:
> HI,
*SNIP*
>
> I used SA in a past, the block rate is about 50%. I need more.
>
You should find a much better overall success rate if you:
- *first* block all the worst-case offenders in Exim acl's
during the earliest practical stages of the smtp mating dance.
There is not much point in SA scanning a message from a
zombie-farm that has an IP that does not resolve to a hostname,
is on a dynamic IP with no PTR record, is addressed to a
non-existent user on your host, forges its source, attempts to
pipeline when you do not advertise it, violates smtp protocol
synchronization, goes away mad after a short delay, doesn't
complete handshakes, etc.
These help:
pipelining_advertise_hosts = :
smtp_enforce_sync = true
Tune these to suit:
smtp_accept_max = 200
smtp_accept_max_per_connection = 20
smtp_accept_max_per_host = 10
Consider use of these:
host_lookup = *
helo_try_verify_hosts = *
dns_again_means_nonexist = !+local_domains : !+relay_from_hosts
Kill this:
#rfc1413_hosts = :
rfc1413_query_timeout = 0s
...and more, all well documented.
Use this while developing your 'production' configure:
log_selector = +all
Then tail -f /var/log/exim/mainlog and keep an eye on the
progress of your changes.
Once these, and many other low-resource-load tests are passed,
then one can also call out to a select few reliable RBL's
Exim can check all of these things well before calling on SA,
and these may safely reject over 80% of the unwanted traffic.
IF a message passes all this, as it should do with a proper mx
correspondent, one may now check that message format, mime and
attachment types are acceptable and otherwise adhere to the rules.
In all of these acl's you can use the 'warn' verb to add integer
'demerit' points weighted to the severity of the offense to
acl_c(x) and acl_m(x) variables.
By pulling a corresponding set of 'threshold' integer values
from a per-user or per-domain table or db, you can then check
the accumulated 'demerits' against user/domain preferences at
several checkpoints, one or more per each smtp phase.
Only then do the deny/drop/discard - or carry on to the next
step and do so if further tests fail.
This allows more flexibility toward rooting out the malicious
while reducing false-positives than a hard 'deny' at each
component test, and supports more flexible 'per user' preferences.
Run the surviving traffic through clamAV first, as it takes
fewer resources to run than SA.
Finally, only when all else looks to be a legitimate and
'reasonably' well-formatted and protocol-compliant message, you
can call in an SA that is stripped down for lighter load:
- No need to do white/black list or RBL checking in SA if you
have done so already in Exim, which is more efficient.
- Spam Bayes can be left-off, as it is dodgy in multi-user
environments AND adds too little score-weight for the resources
it consumes.
Configure other SA scoring weights in local.cf over-rides to
better suit *your* needs.
At least for starters, you may also wish to make use of
'fakereject' and/or also make a copy of rejected traffic to an
archive so that you can review the effectiveness, sort out WHY
things are as they are, and recover from any false-positives
easily by moving an otherwise-lost message back into the user's
mailstore.
None of the really 'good stuff' is 'click a CPANEL' simple.
If you want professional results, one-size does not fit all.
You should expect to invest some time studying, planning,
testing, to *progressively* tailor acl's to your specific user
environment's needs. Dropping in someone else whole code-set is
risky.
Most tests will pay off in the earliest days, the rest may take
days, weeks, or even months of watching and tuning to become a
highly effective, low false-positive fit to your specific
environment.
A 'low risk' start can be had by inserting 'warn' verbs that
make the test but do nothing more than log the results.
Give each 'warn' a code and write that to the log with the
message. That will let you see what is working and find it more
easily to edit changes.
Example:
# DATA_9: IF NOT proper sender address in ANY header THEN warn.
#
warn
logwrite = Entering D9
message = X-Sender-Verify-Failed: No valid sender.
log_message = D9 No valid sender in headers
!condition = ${if eq{$acl_m0}{1}}
!verify = header_sender
set acl_m2 = $acl_m2 No Valid Sender=24
set acl_m5 = ${eval:$acl_m5 + 24}
The 'logwrite' always makes a log entry.
The log_message makes an entry only if the acl test is met.
The NOT condition allows skipping this test if the traffic is
from one of our authenticated clients (acl_m0 copied from
acl_c0, is set much earlier, elsewhere).
acl_m2 is concatenting a growing string of fault messages.
acl_m5 is carrying a cumulative score of demerits to later test
against a one or more threshold integers, server, domain, or
user specific.
Change some, not all, of your 'warn' verbs to 'deny' verbs only
after you are comfortable that they are doing what you want.
Requiring that recipients can be verified, for example, is
nearly always correct. Mismatched HELO, OTOH, is too common to
use by itself, and expecting a messageID in each message will
reject all too many broken Microsoft mailers from otherwise
decent folks.
Specific acl fragments are all over the list archives, docs, and
how-tos on websites.
But they are all examples that you must adapt or roll-in very
carefully. Trying to just cut and paste disparate chunks
together, even the 'official' examples, can create conflicts and
unexpected behavior.
Exim's superb 'debug' tools and enhanced 'real time' logging are
your friends.
Overall, these concepts work extremely well for us in
production. The end result is just short of *magic* as to
blocking spam and zombies, so it is definitely worth the
learning curve.
But dropping MY config onto YOUR server would stop all traffic cold.
HTH,
Bill
