Hi Bill,
Thanks for tips, I will deploy them.
Regards,
Marlon
> 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
>
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
>
