>...
>In the last couple of weeks, I've suddenly started having tons of spam get
>by SA. Up until then, things had been working beautifully for a number of
>years (with occasional upgrades and tweaks, of course). I'm not sure what
>has changed, but something seems broken. I upgraded to 3.1.2, but it
>didn't seem to improve things much. I also am not seeing an obvious
>pattern to the things that are getting through. Some of them are actually
>getting autolearned as ham, which is probably making the problem even
>worse.
>
>Here are several example messages that have gotten through in the last day
>or so (including the scores they got):
>
>http://dogcow.org/tmp/spam-misses-20060602/
>
>I have SA installed locally in my home dir, running through procmail (no
>spamd/spamc involvement). I theoretically have network checks on (I'm not
>running SA with '-L').
>
>Any thoughts on what is going wrong here?
>
>Thanks.
>
>Sean
>
Sean,
Other than the stock spams and the single asian porn spam, these
are Kuvayev and Yambo pill sites. The SARE stock rules will help with
the stock junk (so will Bayes).
Also, your Bayes is seriously busted and you don't seem to be
running net tests - enable all of the URIBL tests (the SBL would have
caught nearly all of these) and consider adding or sa-update'ing to get
URIBL[black] in there also. Further enable all the digests you can (i.e.
DCC, Razor and Pyzor). You say net tests are enabled, but there are no
hits on the SBL or SURBL, only Pyzor - looks very odd; Check your ".pre"
file for enabled plugins.
Finally, many of these were mis-learned as ham - feedback all
low scoring FNs as "hand-training" to Bayes with sa-learn. Every one
of these spams should have been caught.
And lastly, if you're willing to be a little more strict (and
you appear to be a small business site), in Postfix you can block on
the SBL-XBL and "defer_if_reject" for SpamCop's BL - both of these will
likely save a lot of the spam from coming through as will greylisting
(Postgrey is the easiest method for small Postfix sites to use).
Paul Shupak
[EMAIL PROTECTED]
