>...
>On Friday, January 13, 2006, 10:12:40 AM, Irina Irina wrote:
>> Hello Matt and all,
>
>> I enabled SURBL checks on a secondary server yesterday.  It catches spam so
>> great that I like it very much.
>
>> Today I enabled it on our main server...  Queue started to grow, messages
>> were piling up.  I had to revert back, queue then went down gradually.
>
>> Compared on both servers with
>>     spamassassin -D --lint
>> and did not notice too big difference in time (thought it would take much
>> longer on the main server).
>
>
>> Do I need to have this in local
>>     skip_rbl_checks 0
>> to hit SURBL checks?  Or only loadplugin
>> Mail::SpamAssassin::Plugin::URIDNSBL?
>
>I believe you need both, however skip_rbl_checks 0 enables all
>the RBL tests, not just SURBLs.
>
>  http://spamassassin.apache.org/full/3.1.x/dist/rules/20_dnsbl_tests.cf
>
>If you were previously not using RBL tests and only want to use
>SURBLs, then you can give zero scores to the other RBL tests.
>That may save some processing time, if it lowers your scores
>somewhat. 
>
>  http://spamassassin.apache.org/full/3.1.x/dist/rules/50_scores.cf
>...
>Presumably you would zero these out in the local server config
>files, and not the installed configs.
>
>Cheers,
>
>Jeff C.
>...
        One important issue often glossed over is the distinction between
processor time and latency.  The "net" tests in general, both RBL and digest,
add significant latency to SA, but only relatively insignificant processor
time.  The effect of this is on a loaded server you may need more children
and thus more memory, but the actual throughput will vary little with a tuned
system (i.e. the proper number of children for 3.0.x or the proper choices
of forking method for 3.1.x+) and the supplied default net tests.

        DISCLAIMER:  I am *very* biased and use a far greater than standard
number of net tests of each of the common flavors (in particular, additional
URI tests based on IP BLs besides just the SBL), *and* I am a small site
with hardware resources I can afford to throw at the problem:  If you are
a 100K+ message/day site, things may look very different to you.  I doubt
any site under 20K messages a day needs much consideration of tuning for
net tests (and those upto ~35K/day just need to adjust the number of children
or forking strategy depending on which version of SA they are running).

        The SARE rules, which are extremely useful and valuable will cause
your processor and memory usage (per child) to grow much more than net tests,
but have a much smaller effect on latency (YMMV, and the choice of which SARE
rule-sets you choose makes a *huge* difference).

        For a medium to large site it is important to consider messages per
time period, not how long any one message takes to pass through the system
(indeed, that is why there are multiple instances running under most setups
to begin with);  There is nothing wrong with allowing for 15 or 20 seconds
per message to avoid Pyzor timeouts, but if make sure that the number of
children will still allow the required peak message per second/minute/hour
rate you need (86400 second in a day, so a 20K message/day site with 20
second RBL/digest timeouts will need about 5 children on the average and
more during peak periods).


        Paul Shupak
        [EMAIL PROTECTED]

Reply via email to