Spamassassin timing

[Alexander Dalloz]

Am Fr, den 09.07.2004 schrieb jdow um 21:59:

Hi Joanne, nice to read you again :)

> Um, Alexander, a Spamassassin 2.63 with a relatively full set of the
> SARE rule sets is a little bit tough on a 166 MHz running the small
> "bigevil" set and no xBL tests. I am a little worried about running
> the new 35,000 entry big evil test set. If that 350 MHz machine is
> servicing more than a one or two users who do a LOT of email it is
> possible it could be too small.

Sorry, I didn't want to propagate low or even lowest level machine for
such tasks. May point was only to demonstrate that my old computer is
far enough to manage many intensive mail tasks.

22:14:30  up 36 days, 19 min,  1 user,  load average: 0.00, 0.05, 0.07

I must confess my setup on the machine handling mail is a bit too much,
but I use it for testing things too. So actually I fetch my mail from
the university account using fetchmail, it then goes to Sendmail. First
milter-sender hooks in and checks whether the sender address is valid
(lists are whitelisted or at least cached), then it goes to AMaViS (Perl
application) and is checked for viruses by McAfee uvscan. Then comes the
next milter which is MimeDefang (too a Perl application), calling ClamAV
and SpamAssassin 2.63 for tagging suspicious messages. RBL checks are
made directly by Sendmail and not through SA. Ok, I did not hook in
other tools like pyzor or razor.

> First off as important as the CPU speed may be the amount of system
> ram present is critical. SpamAssassin uses LOTS of memory. So it is
> wise to limit the number of concurrent Spam assassins running.

Yes, RAM is a limiting factor too. My box has 256 MB.

> Second spamd/spamc is much faster than spamassassin itself. It
> bypasses the lugubrious perl startup process and loading MOST of
> the configuration files. (User custom files, if enabled, are still
> read in for each message processed.)

Perl disadvantages. Therefor MimeDefang uses embedded Perl for calling
and using SpamAssassin. Makes a good job.

> Third, his delay time sounds like DNS delay. He may have his
> SpamAssassin configured to use a dead BL.

I assume that too.

> Fourth, 2.63 is the ONLY version anyone should be useing today.
> 3.0 is in its first public beta at this time. It includes some
> worthwhile innovations.

SA 3.0 is available as a development RPM.

> Fifth, the SpamAssassin wiki is well worth consulting.
> http://wiki.spamassassin.org.
> 
> Sixth, the SpamAssassin mailing list is a useful resource.

Yes, though much traffic there like here ;)

> Seventh, check back mailing list messages for references to "SURBL."
> A lot of people absolutely adore it these days. (Even the guy with a
> server farm that processed 103 million emails last month.)
> 
> {^_^}    Joanne

Alexander


-- 
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) on Athlon CPU kernel 2.6.6-1.435.2.3 
Serendipity 22:11:00 up 2 days, 4:19, load average: 0.20, 0.49, 0.47 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20040709/81776869/attachment-0001.sig>