Oh, you're right. On the machine not showing a spam score, the log shows: Jun 12 23:58:42 osiris amavis[5815]: [ID 702911 mail.info] (05815-08) spam_scan: not wasting time on SA, message longer than 204800 bytes: 326+312287
That makes sense. The primary MX gets much more traffic than then backup MX, but I was hoping that Amavisd-new would not bother running spam tests on something clearly generated by itself. This got me looking in my /var/amavis/.spamassassin directory where I noticed that all these files hadn't been updating since I upgraded to BerkeleyDB4 from BerkeleyDB3, including auto-whitelist. I've deleted those files and restarted Amavisd-new. I need to watch this for sometime and see what is happening. Thanks for your insights. You've helped kickstart my brain (: Mark Martinec wrote: > Gordon, > > >>...one machine doesn't tag the mail as spam: >>X-Spam-Score: - >>X-Spam-Status: No, score=x required=6 tests=[] >> >>While the other machine does: >>X-Spam-Status: No, score=5.436 required=6 tests=... > > > On the first machine SA was not called or timed out. > > The reason could be: mail size larger than $sa_mail_body_size_limit, > sender white- or blacklisted, recipient in @bypass_spam_checks_maps, > but probably most likely in your case: SA processing time exceeded > $sa_timeout value, which for version older than 2.4.1 may be on the > short side for a busy host (starting with 2.4.1 the $sa_timeout > does not matter). Your logs could tell what happened. > > Mark _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
