You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Do...@bakerbotts.com on 2004/11/15 23:54:48 UTC
spamassassin time outs
We are running SA 3.01 and the latest MailScanner. Besides the delivered SA
rule sets, we have the following:
r--r--r-- 1 31854 May 31 19:24 70_sare_adult.cf
-r--r--r-- 1 3927 Apr 24 2004 70_sare_bayes_poison_nxm.cf
-r--r--r-- 1 211390 Oct 3 20:18 70_sare_header.cf
-r--r--r-- 1 103436 Sep 12 20:22 70_sare_html.cf
-r--r--r-- 1 11559 Sep 16 12:45 70_sare_oem.cf
-r--r--r-- 1 17548 Aug 16 09:38 70_sare_random.cf
-r--r--r-- 1 19899 Oct 3 20:20 70_sare_specific.cf
-r--r--r-- 1 7023 Oct 8 00:45 70_sare_spoof.cf
-r--r--r-- 1 7937 Nov 11 00:45 70_sc_top200.cf
-r--r--r-- 1 13211 May 11 2004 72_sare_bml_post25x.cf
-r--r--r-- 1 57580 May 6 2004 99_FVGT_Tripwire.cf
-r--r--r-- 1 10147 May 1 2004 99_sare_fraud_post25x.cf
-r--r--r-- 1 8043 Nov 12 23:12 bakerbotts.cf
-r--r--r-- 1 100721 Nov 7 14:13 bogus-virus-warnings.cf
-r--r--r-- 1 23470 May 25 11:56 chickenpox.cf
-r--r--r-- 1 18052 Nov 2 00:45 evilnumbers.cf
-r--r--r-- 1 4883 May 25 11:03 random.current.cf
-r--r--r-- 1 3880 Apr 27 2004 weeds.cf
The bakerbotts.cf is our own custom rule set.
We process between 100k and 165k emails a day on two primary servers, with 3
overflow servers. Since we have implemented 3.01, we have experienced a
higher number of timeout messages from SA. Yesterday 487 and the day before
544.
Nov 15 15:57:00 dalgate-inside MailScanner[8379]: SpamAssassin timed out and
was killed, failure 1 of 20
Nov 15 15:58:25 houmx01-inside MailScanner[1377]: SpamAssassin timed out and
was killed, failure 1 of 20
Does the software need more CPU resources; or do we have too many add-on
rule sets; or is there another explanation?
We are using pyzor, but not dcc or razor2. Using all three was slowing down
the spam check process.
Any ideas would be greatly appreciated.
Thanks,
Donald
Re: spamassassin time outs
Posted by Matt Kettler <mk...@evi-inc.com>.
At 05:54 PM 11/15/2004, Donald.Dawson@bakerbotts.com wrote:
>We are running SA 3.01 and the latest MailScanner. Besides the delivered
>SA rule sets, we have the following:
It's most likely due to bayes expiry.
Requoting a past post of mine on the subject:
------------------------------------------------------------------------------
Mailscanner is inappropriately impatient with SpamAssassin. It's timeouts
were designed in the pre-bayes era, and are not designed to accommodate
bayes housekeeping chores like expiry and journal syncs.
In the short term, you can help by running a sa-learn --force-expire on
your bayes DB.
In the longer term, here's some suggestions I use on my own MailScanner
server: (I use all of these together)
1) Increase the spamassassin timeout in MailScanner.conf. Bring it to 60
seconds at least, I have mine set to 120.
2) Set the "Rebuild Bayes Every" parameter in MailScanner.conf. 86400
seconds is a good start. This makes MailScanner invoke SA's bayes
housekeeping directly, rather than during a scan of a message.
3) in /etc/mail/spamassassin/local.cf set: bayes_auto_expire 0. This will
keep SA from trying to run bayes expires (long and slow) during message
handling, but relies on #2 above to allow expiry to occur.
4) I also have a sa-learn --force-expire running as a daily cronjob. I have
tested the setup without this measure, and #2 is sufficient to cause expiry
to occur. Really this is just a fail-safe to allow expiry to occur even if
MailScanner's calls fail to run it properly for some reason.
Re: spamassassin time outs
Posted by Martin Hepworth <ma...@solid-state-logic.com>.
Donald
I'd also check which RBL's you are using. I found quite a few problems
when I had more than 2 RBL'S being checked - even with an increased SA
timeout setting in MailScanner.
Also I 'think' SA 3.01 contains weeds.cf and chickenpox.cf as standard
rulesets now (check in /etc/mail/spamassassin). And the evilnumbers.cf
isn't being updated, use the surbl URI RBL's instead.
--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300
Donald.Dawson@bakerbotts.com wrote:
> We are running SA 3.01 and the latest MailScanner. Besides the
> delivered SA rule sets, we have the following:
>
> r--r--r-- 1 31854 May 31 19:24 70_sare_adult.cf
> -r--r--r-- 1 3927 Apr 24 2004 70_sare_bayes_poison_nxm.cf
> -r--r--r-- 1 211390 Oct 3 20:18 70_sare_header.cf
> -r--r--r-- 1 103436 Sep 12 20:22 70_sare_html.cf
> -r--r--r-- 1 11559 Sep 16 12:45 70_sare_oem.cf
> -r--r--r-- 1 17548 Aug 16 09:38 70_sare_random.cf
> -r--r--r-- 1 19899 Oct 3 20:20 70_sare_specific.cf
> -r--r--r-- 1 7023 Oct 8 00:45 70_sare_spoof.cf
> -r--r--r-- 1 7937 Nov 11 00:45 70_sc_top200.cf
> -r--r--r-- 1 13211 May 11 2004 72_sare_bml_post25x.cf
> -r--r--r-- 1 57580 May 6 2004 99_FVGT_Tripwire.cf
> -r--r--r-- 1 10147 May 1 2004 99_sare_fraud_post25x.cf
> -r--r--r-- 1 8043 Nov 12 23:12 bakerbotts.cf
> -r--r--r-- 1 100721 Nov 7 14:13 bogus-virus-warnings.cf
> -r--r--r-- 1 23470 May 25 11:56 chickenpox.cf
> -r--r--r-- 1 18052 Nov 2 00:45 evilnumbers.cf
> -r--r--r-- 1 4883 May 25 11:03 random.current.cf
> -r--r--r-- 1 3880 Apr 27 2004 weeds.cf
>
> The bakerbotts.cf is our own custom rule set.
>
> We process between 100k and 165k emails a day on two primary servers,
> with 3 overflow servers. Since we have implemented 3.01, we have
> experienced a higher number of timeout messages from SA. Yesterday 487
> and the day before 544.
>
> Nov 15 15:57:00 dalgate-inside MailScanner[8379]: SpamAssassin timed out
> and was killed, failure 1 of 20
> Nov 15 15:58:25 houmx01-inside MailScanner[1377]: SpamAssassin timed out
> and was killed, failure 1 of 20
>
> Does the software need more CPU resources; or do we have too many add-on
> rule sets; or is there another explanation?
>
> We are using pyzor, but not dcc or razor2. Using all three was slowing
> down the spam check process.
>
> Any ideas would be greatly appreciated.
>
> Thanks,
> Donald
>
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.
**********************************************************************