Hi there,
This is a new machine with rules copied over from another machine. How
about this? I just start new. Is there a good page out that explains
setting up spamassassin from scratch and getting the sa rules set up
well and cleaned up nicely? I am happy to start from the beginning with
best practices.
Cheers,
Noah
On 8/11/14 4:31 PM, Karsten Bräckelmann wrote:
On Mon, 2014-08-11 at 09:18 -0400, Joe Quinn wrote:
Keep replies on list.
Do you remember making any changes, or are you using spamassassin as it
comes? What kind of email is going through your server? Very large
emails can cause trouble with poorly written rules. If you can, perhaps
systematically turn off things that are pushing email to that server
could narrow it down to a particular type of email.
On 8/9/2014 4:41 PM, Noah wrote:
thanks for your response. I am not handling much email its a new
server and currently the MX points to another server.
What mail is it handling?
Not MX, so I assume it does not receive externally generated mail at
all. Which pretty much leaves us with locally generated -- cron noise
and other report types.
How is SA integrated? What's your message size limit (see config of the
service passing mail to SA)? Are you per chance scanning multi MB text
reports?
A sane size limit is about 500 kB. Besides, local generated mail isn't
worth processing with SA, and in the case of cron mail often harmful
(think virus scanner report).
How do I check the SA configuration? How do I check if I am using
additional rules?
By additional rules, we mean any rules or configuration that is not
stock SA. Anything other than the debian package or running sa-update.
Generally, anything *you* added.
On 7/31/2014 3:19 PM, Noah wrote:
what are some things to check with spamassassin commonly running at
100 percent?
For how long does it run at CPU max? What is the actual process name?
It would be rather common for the plain 'spamassassin' script to consume
a couple wall-clock seconds of CPU, since it has to read and compile the
full rule-set at each invocation.
Unlike the 'spamd' daemon, which has that considerable overhead only
once during service start. In both cases may the actual scan time with
high CPU load be lower than the start-up overhead.
