--On Thursday, March 13, 2014 3:50 PM -0700 John Hardin
<jhar...@impsec.org> wrote:
On Fri, 14 Mar 2014, Jason Haar wrote:
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.
In the amavisd config?
Hm... I'm seeing really random scores across the board, pyzor or not (I
commented out the die() so tha t cannot be the cause).
For example:
Mar 13 17:02:24 edge01 amavis[60025]: (60025-04) spam-tag,
<a...@mydomain.com> -> <d...@mydomain.com>,<g...@mydomain.com>, No,
score=-1.149 tagged_above=-10 required=3 tests=[ALL_TRUSTED=-1,
BAYES_00=-0.05, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
This is missing RCVD_IN_DNSWL_HI. This email originated on our MTAs, and
was delivered going through them.
This did too, and correclty has that rule applied:
Mar 13 17:00:08 edge02 amavis[39369]: (39369-17-3) spam-tag,
<a...@mydomain.com> -> <d...@zimbra.com>, No, score=-5.149 tagged_above=-10
required=3 tests=[BAYES_00=-0.05, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, UNPARSEABLE_RELAY=0.001]
autolearn=unavailable autolearn_force=no
The difference is the timing... The second one came in at 17:00:07 and was
marked scanned through SA by 17:00:08. The second one came in at 17:02:20,
so there was a 4 second processing time in Amavis.
The odd thing is that the amavisd default for child process timeouts is 8
minutes. The SA timeout for RBL lookups is 5 seconds. So my deliveries
are well within those timeout boundaries.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
