Just yesterday I manually pushed a piece of spam through spamc and spamassassin and got a different score too. It ended up being caused by "time_limit". "spamassassin" didn't listen to it whereas spamc/spamd did and the email took a loooong time to process - triggering the scores to be different
I ended up just increasing "time_limit" to fix. Could that be affecting pyzor related timeouts too? (mine wasn't pyzor related - just a big message with lots of text and attachments) Jason On 14/03/14 10:15, John Hardin wrote: > On Thu, 13 Mar 2014, Quanah Gibson-Mount wrote: > >> --On Thursday, March 13, 2014 1:48 PM -0700 John Hardin >> <jhar...@impsec.org> wrote: >> >>> On Thu, 13 Mar 2014, Quanah Gibson-Mount wrote: >>> >>> > In looking at why some spam is still making it through, it >>> appears that >>> > Pyzor errors block URIBL lookups: >>> >>> I'm working with someone who seems to be having the same problem in >>> 3.3.1 >>> - thanks for noting this, I will take a closer look. >> >> Thanks. The scoring can vary depending on when the pyzor callback >> fails. For example, in another run, the pyzor error doesn't come back >> until after more of the URI checks are done: >> >> etc. I.e., the scoring is completely erratic based on where URIBL >> processing is when the pyzor callback fails. > > That's similar to the behavior they're seeing. Much lower URIBL hits > than when running SA from the command line on the test MX, and the log > shows problems with pyzor (though the excerpt I saw didn't mention a > traceback, it just said "no output"). > > FWIW they're running amavisd-new, and we're trying to figure out why > the scores on MTA-processed messages are so much lower than when the > same message is passed through command-line SA in debug mode. > -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
