On Mon, 28 Sep 2009, jmunjr wrote:
Thanks for all the responses. I really appreciate them.
Message size.
Mail is not being restricted by message size.
We'd need to see the spamc command line options to tell for sure.
System overload.
Server almost always has a load under 1.00, though at night numerous scripts
run bringing the server load to ~1.50-2.00 at times.
Sorry, I was speaking primarily about memory, though the run queue metric
can indirectly suggest whether or not swapping is a problem. How much
memory is installed? Is swap being hit?
Possibly DNS timeouts. Do you have a caching nameserver set up locally,
No local caching nameserver
That would probably help performance.
System tasks, like automatic restart of spamd after running sa_update.
Not sure about this. How would I know? I run Webmin/Virtualmin and
spamassasin came installed with it.
Sorry, I can't help for any of the various admin consoles that obscure
those details. You might poke around under /etc/cron.* and run "crontab
-l" as root to get some idea of scheduled tasks.
What command-line arguments are being used with spamc?
Don't think there are any.
This is fairly important, if you can find where spamc is being called.
Check your MTA log (e.g. /var/spool/maillog) for the time around
What to look for? I checked and nothing out of the ordinary on each of
these messages.
Well, error messages obviously. Do you see anything from spamd indicating
it ever saw those messages? Do you see the MTA handling the message but no
information from spamd, where you'd normally see something from spamd?
I have also read of someone having messages that don't get scanned by SA
to get sent back to SA to get rechecked. How would I go about doing
this? I'm not terribly adept at knowing all the terms so any step by
step help is appreciated.
In order to suggest how to do that we'd need to know how spamc is glued
into your mail server. As I said, I'm not familiar with webmin and how it
might glue things together.
I seem to remember you mentioned procmail; you might poke around in the
procmail scripts (typically /etc/procmailrc) and see if you can find the
call to spamc. Unfortunately, procmail has its own layer of smart error
recovery, so you'd have to tell it to requeue the message too.
At the simplest level, adding "-x" to the spamc command line tells it to
return an error if the message couldn't be scanned, rather than just
passing the message on. Whetever called spamc has to react properly to
that error or you may lose messages. If whatever calls spamc sees an error
code and just delivers the original message, then you've not gained any
ground.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If guns kill people, then...
-- pencils miss spel words.
-- cars make people drive drunk.
-- spoons make people fat.
-----------------------------------------------------------------------
Approximately 8958960 firearms legally purchased in the U.S. this year
