You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Vincenti Francesco <Fr...@aspasiel.it> on 2008/09/19 09:34:45 UTC

Trobles with spamassassin

Good morning everybody,

My name is Francesco, from ThyssenKrupp.

I'm mailing you for some suggestions about a problem which I find in my
antispam system, based on spamassassin.

My system has the following characteristics:

-          A two nodes cluster based, active-active, one for the
incoming email and the other for the outgoing email. If a node crashes,
the other brings the service on its shoulders.

-          Each node has 4GB RAM and two processors

-          O.S.                             Fedora core 3

-          Mail server                    qmail 1.0.3

-          Antivirus                       clamav 0.87.1

-          Antispam                      spamassassin 3.0.4

-          Cluster controller           heartbeat

-          Interface                       qmail-scanner-queue.pl

Starting from the 15th of July, I find, sometimes, in the log file of
qmail-scanner-queue.pl the following alert instead of normal score: SA:
finished scan in 600.010015 secs - hits=?/?.

I have already searched on the official site of spamassassin and it
seems to be generated by some kind of trouble using the web scansion. I
really used pyzor and razor2 scansion, so I took them out from local.cf.
This action caused the decrease of average processing time from 15
seconds to 3.5 seconds for each treated email. But I still have some
kind of web search because the system is configured to use RBL search
too, and I can't take it out. The time has been improved but the problem
stays!

I have to write and to upgrade a local configuration file, named
local_rules.cf which has reached the dimension of 250KB it is very
useful to stop a lot of SPAM which is not stopped by the other rules.
The problem started to appear after one of the upgrade I usually have to
do, which wasn't so dramatic to justify this behaviour, I think.

Looking at my MRTG graphics I have noticed that the problem appears when
the levels of system load and cpu usage are higher then usual but not
the level of messages, which seems to be non influential.

Someone told me that starting from middle of July a lot of public
servers have been subject to attacks by crackers, and the attacks are
still running.

I really think that the problem is caused by the dimensions of the local
configuration file, but every day I receive more than 15000 emails and
the problem appears for no more than 50-60 emails! 

 

If you know the source of the problem or how to intervene to solve it I
will be very grateful for your help.

Thank you very much anyway.

 

Best Regards

Francesco Vincenti

 

 


Re: Trobles with spamassassin

Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 19 Sep 2008, Vincenti Francesco wrote:

> Good morning everybody,
>
> My name is Francesco, from ThyssenKrupp.
>
> I'm mailing you for some suggestions about a problem which I find in my
> antispam system, based on spamassassin.
>
[snip..]
> -          Each node has 4GB RAM and two processors
>
> -          O.S.                             Fedora core 3
>
> -          Mail server                    qmail 1.0.3
>
> -          Antivirus                       clamav 0.87.1
>
> -          Antispam                      spamassassin 3.0.4
>
> -          Cluster controller           heartbeat
>
> -          Interface                       qmail-scanner-queue.pl
>
> Starting from the 15th of July, I find, sometimes, in the log file of
> qmail-scanner-queue.pl the following alert instead of normal score: SA:
> finished scan in 600.010015 secs - hits=?/?.
[snip..]
>
> I have to write and to upgrade a local configuration file, named
> local_rules.cf which has reached the dimension of 250KB it is very
> useful to stop a lot of SPAM which is not stopped by the other rules.
> The problem started to appear after one of the upgrade I usually have to
> do, which wasn't so dramatic to justify this behaviour, I think.

Two things;
1) That is an obsolete version of clamav (current version is up to 0.94)
The database updates probably are not working with your client as
the database contains features that are version specific.
So you may not be protected at all due to database VS client version
mismatches.
Update it promptly.

2) That is an obsolete version of spamassassin, (v3.2.5 is current, v3.3
almost out.) Spam is a constantly thing thing as spammers try to
circumvent anti-spam measures, so spamassassin evolves to try to beat it.

This you have already found by your need for that very large local config
file. If you update to a more recent version of spamassassin you can
probably get rid of that oversized local config file and get better
performance than you have already.

Bottom line, update both ClamAV & spamassassin.


-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Re: Trobles with spamassassin

Posted by SM <sm...@resistor.net>.
Hi Francesco,
At 00:34 19-09-2008, Vincenti Francesco wrote:
>My system has the following characteristics:
>-          A two nodes cluster based, active-active, one for the 
>incoming email and the other for the outgoing email. If a node 
>crashes, the other brings the service on its shoulders.
>-          Each node has 4GB RAM and two processors
>-          O.S.                             Fedora core 3
>-          Mail server                    qmail 1.0.3
>-          Antivirus                       clamav 0.87.1
>-          Antispam                      spamassassin 3.0.4
>-          Cluster controller           heartbeat
>-          Interface                       qmail-scanner-queue.pl

That version of SpamAssassin is quite old.

>Starting from the 15th of July, I find, sometimes, in the log file 
>of qmail-scanner-queue.pl the following alert instead of normal 
>score: SA: finished scan in 600.010015 secs - hits=?/?.
>I have already searched on the official site of spamassassin and it 
>seems to be generated by some kind of trouble using the web 
>scansion. I really used pyzor and razor2 scansion, so I took them 
>out from local.cf. This action caused the decrease of average 
>processing time from 15 seconds to 3.5 seconds for each treated 
>email. But I still have some kind of web search because the system 
>is configured to use RBL search too, and I can't take it out. The 
>time has been improved but the problem stays!
>I have to write and to upgrade a local configuration file, named 
>local_rules.cf which has reached the dimension of 250KB it is very 
>useful to stop a lot of SPAM which is not stopped by the other 
>rules. The problem started to appear after one of the upgrade I 
>usually have to do, which wasn't so dramatic to justify this 
>behaviour, I think.

I gather that you have read 
http://wiki.apache.org/spamassassin/FasterPerformance  The large 
local rules file will affect performance.  If you want to keep pyzor 
and razor2, see http://wiki.apache.org/spamassassin/UsingNetworkTests 
on how to reduce the timeout values.  Run spamd with the -D switch to 
find out whether there are any errors.

Regards,
-sm 


RE: Trobles with spamassassin

Posted by "Martin.Hepworth" <ma...@solidstatelogic.com>.
Hi

You'll probably get a lot of this, but a lot the software you mention is really really old, and I'm surprised you're clamav is indeed getting it's regular updates.

Also a lot of people will recommend NOT using a fast moving linux distribution like Fedora as server.

Once you've upgraded spamassassin and clamav then I'd have a look at this for some ideas about getting better performance out of SA..

http://wiki.mailscanner.info/doku.php?id=maq:index#getting_the_best_out_of_spamassassin

--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300

> -----Original Message-----
> From: Vincenti Francesco [mailto:Francesco.Vincenti@aspasiel.it]
> Sent: 19 September 2008 08:35
> To: users@spamassassin.apache.org
> Subject: Trobles with spamassassin
>
> Good morning everybody,
>
> My name is Francesco, from ThyssenKrupp.
>
> I'm mailing you for some suggestions about a problem which I
> find in my antispam system, based on spamassassin.
>
> My system has the following characteristics:
>
> -          A two nodes cluster based, active-active, one for
> the incoming email and the other for the outgoing email. If a
> node crashes, the other brings the service on its shoulders.
>
> -          Each node has 4GB RAM and two processors
>
> -          O.S.                             Fedora core 3
>
> -          Mail server                    qmail 1.0.3
>
> -          Antivirus                       clamav 0.87.1
>
> -          Antispam                      spamassassin 3.0.4
>
> -          Cluster controller           heartbeat
>
> -          Interface                       qmail-scanner-queue.pl
>
> Starting from the 15th of July, I find, sometimes, in the log
> file of qmail-scanner-queue.pl the following alert instead of
> normal score: SA: finished scan in 600.010015 secs - hits=?/?.
>
> I have already searched on the official site of spamassassin
> and it seems to be generated by some kind of trouble using
> the web scansion. I really used pyzor and razor2 scansion, so
> I took them out from local.cf. This action caused the
> decrease of average processing time from 15 seconds to 3.5
> seconds for each treated email. But I still have some kind of
> web search because the system is configured to use RBL search
> too, and I can't take it out. The time has been improved but
> the problem stays!
>
> I have to write and to upgrade a local configuration file,
> named local_rules.cf which has reached the dimension of 250KB
> it is very useful to stop a lot of SPAM which is not stopped
> by the other rules. The problem started to appear after one
> of the upgrade I usually have to do, which wasn't so dramatic
> to justify this behaviour, I think.
>
> Looking at my MRTG graphics I have noticed that the problem
> appears when the levels of system load and cpu usage are
> higher then usual but not the level of messages, which seems
> to be non influential.
>
> Someone told me that starting from middle of July a lot of
> public servers have been subject to attacks by crackers, and
> the attacks are still running.
>
> I really think that the problem is caused by the dimensions
> of the local configuration file, but every day I receive more
> than 15000 emails and the problem appears for no more than
> 50-60 emails!
>
>
>
> If you know the source of the problem or how to intervene to
> solve it I will be very grateful for your help.
>
> Thank you very much anyway.
>
>
>
> Best Regards
>
> Francesco Vincenti
>
>
>
>
>
>




**********************************************************************
Confidentiality : This e-mail and any attachments are intended for the 
addressee only and may be confidential. If they come to you in error 
you must take no action based on them, nor must you copy or show them 
to anyone. Please advise the sender by replying to this e-mail 
immediately and then delete the original from your computer.
Opinion : Any opinions expressed in this e-mail are entirely those of 
the author and unless specifically stated to the contrary, are not 
necessarily those of the author's employer.
Security Warning : Internet e-mail is not necessarily a secure 
communications medium and can be subject to data corruption. We advise 
that you consider this fact when e-mailing us. 
Viruses : We have taken steps to ensure that this e-mail and any 
attachments are free from known viruses but in keeping with good 
computing practice, you should ensure that they are virus free.

Red Lion 49 Ltd T/A Solid State Logic
Registered as a limited company in England and Wales 
(Company No:5362730)
Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU, 
United Kingdom
**********************************************************************