[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Going from procmail based SA to spamass-milter produces more spam
From: |
John E Hein |
Subject: |
Re: Going from procmail based SA to spamass-milter produces more spam |
Date: |
Mon, 30 Oct 2006 13:46:58 -0700 |
Ken Long wrote at 15:23 -0500 on Oct 30, 2006:
> On Mon, 2006-10-30 at 13:01 -0700, John E Hein wrote:
> > Ken Long wrote at 12:58 -0500 on Oct 30, 2006:
> > Three...
> >
> > "erratic results" doesn't tell me much.
>
> Erratic means some messages seemed to tag out the same and some did not.
>
> As I mentioned, I tried setting up a double check by passing the mail
> that makes it through sa-milter into procmail and here is an example
> e-mail.
>
> spamass-milter provided these results:
>
> Oct 30 13:33:57 mailbuoy spamd[22619]: clean message (3.3/5.0) for
> klong:0 in 4.4 seconds, 6936 bytes.
> Oct 30 13:33:57 mailbuoy spamd[22619]: result: . 3 -
> HTML_80_90,HTML_FONT_BIG,HTML_MESSAGE,HTML_NONELEMENT_00_10,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,URIBL_WS_S
> URBL
> scantime=4.4,size=6936,mid=<address@hidden>,autolearn=no
>
> It then went on to my .procmailrc where it was run against spamc and
> came up with these results:
>
> Oct 30 13:34:01 mailbuoy spamd[22920]: identified spam (5.2/5.0) for
> klong:0 in 3.2 seconds, 7101 bytes.
> Oct 30 13:34:01 mailbuoy spamd[22920]: result: Y 5 -
> HTML_80_90,HTML_FONT_BIG,HTML_MESSAGE,HTML_NONELEMENT_00_10,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_NJ
> ABL_SPAM,SPF_HELO_PASS,SPF_PASS,URIBL_WS_SURBL
> scantime=3.2,size=7101,mid=<address@hidden>,autolearn=no
>
> Same message. Same SA configuration on same machine using same bayes
> and same preferences. Different results.
So the difference is:
RCVD_IN_NJABL_SPAM
SPF_HELO_PASS
SPF_PASS
With SA debug bumped up, you can look and see what it's doing when it
does those network tests (just search for spf & njabl).
These are DNS based tests. A couple things that could affect those
would be timeouts and DNS configuration problems. Also DNSBL lookups
can vary over time, but your example shows a time difference of only 4
seconds, so that's not likely the issue.
It's also possible that the Received: header parsing (or actual
Received: header content) is different in some way so it's checking
different IPs in your two cases. The SA debug should tell you what
IPs it's using for the dns lookups.