Re: Going from procmail based SA to spamass-milter produces more spam

[John E Hein]

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.