For high-volume I'd recommend a couple tweaks if your CPU load average is going too high.

1) disable razor, as you already suggested, along with razor2, dcc, and pyzor.

2) zero the scores for several, or all, of the DNSBLs. I personally took the approach of zeroing the scores of DNSBL's for ones which score under 0.5, and I'm not high volume. If you do leave any DNSBLs on, make sure your spamd server has FAST access to a nameserver. I'd even go as far as to recommend a caching nameserver running on the same server as the machine running spamd if it doesn't already have a normal DNS server on it.

3) I'd also consider zeroing some of the "very low scoring" rules. Particularly those with evals. My cutoff was anything less than 0.01, but you might want to take a wider swath if CPU usage is a problem for you.

4) Reduce some timeouts and retry counts. This helps a lot in preventing mail from backloging whenever a blacklist becomes unavailable or a email with "no mx for from" arrives.

The following are the score tweaks I use with 2.43, they outline the basic concepts above, but you might want to do this to a greater extent than I have. Your mileage may vary, but this might be a good start for what you want to do.

-----------------------------------
#Timeout reductions
#the following reduces the time for a run of SA
#but risks timing out valid blacklist data. Still far better to
#skip a blacklist sometimes than to choke a mailserver.
rbl_timeout 10
razor_timeout 10
#the following reduces the time for a run of SA
#but risks claiming a from: has no mx when it
#does indeed have one. This is a bit more risky
#as it increases chances of FPs.
check_mx_attempts 2
check_mx_delay 3

#disabling razor 1, but allow razor2, that works much better
score RAZOR_CHECK 0
#score RAZOR2_CHECK 0

#first, zero some low-scoring DNS lists. <0.5 is NOT worth cost of lookup.
score RCVD_IN_OSIRUSOFT_COM 0
score X_OSIRU_DUL_FH 0
score X_OSIRU_SPAMWARE_SITE 0
#I don't like the idea of checking these, and the scores aren't very high
score RCVD_IN_MULTIHOP_DSBL 0
score RCVD_IN_UNCONFIRMED_DSBL 0

#default scores too low to be worth running
# kill anything > 0.01
#score EXPECT_TO_EARN 0.008
#score SUPERLONG_LINE 0.009
#score MIME_BOUND_DIGITS_3 0.009
#score BIG_BUCKS 0.003
#score GAPPY_TEXT 0.005
#score RESERVES_RIGHT 0.008
#score USER_AGENT_OUTLOOK -0.006
#score GIFT_CERTIFICATE 0.004

score EXPECT_TO_EARN 0
score SUPERLONG_LINE 0
score RISK_FREE 0
score MIME_BOUND_DIGITS_3 0
score BIG_BUCKS 0
score GAPPY_TEXT 0
score RESERVES_RIGHT 0
score USER_AGENT_OUTLOOK 0
score GIFT_CERTIFICATE 0

At 01:00 PM 10/23/2002 -0600, Gustave Eiffel wrote:

Hello all,

I am using spamc for all users through /etc/procmailrc on 4 servers and
spamassassin works great.  The problem is that it loads up the CPU to 4.0 and
often 10.0 or above.  How can I reduce this?  Eliminate razor check is one I
have seen on some other posts.  What would be the best to try?


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en

_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk


Reply via email to