On 29-02-16 06:24, Charles Sprickman wrote:
> Hi all,
>
> Recently I occasionally get bursts of spam that slips through Postfix
> (postscreen BL checks, protocol checks) and SpamAssassin. I just had
> another big jump in the last week. This was mostly spam touting Oil
> Changes, SUV sales and Lawyer Finders.
>
> What I just did was go through a collection of missed spam and re-ran
> it through spamassassin. All of it jumped from originally scoring
> around 2-3 to a minimum of 6.5 with most hitting around 12. The
> biggest difference I see is that DNSBL and URIBL services had started
> hitting. When originally received, these emails all originated from
> very clean IPs.
>
> I have TXREP enabled as well, but that doesn’t seem to be having
> either a positive or negative impact.
>
> What are my options to try to catch this junk before it hits the
> various *BLs?
>
> I’ve not had much luck with Bayes - when I had it enabled recently on
> a per-user basis it was just hitting the master DB server too hard
> with udpates. I’m considering enabling it again with a shared db for
> all users, which I hope might work better. It would only be auto
> trained, perhaps with some manual training by me.
>
> Here’s a few samples, hosted elsewhere so as not to trip anyone’s
> filters:
>
> https://gist.github.com/anonymous/0fcaf481875959c9151f (2.7 on
> Friday, 14 tonight)
>
> https://gist.github.com/anonymous/a5396f68699392808988 (3.4 earlier
> tonight, 6.5 just now)
>
> I have more samples, I can dig them up if that’s helpful.
>
> Sometimes I wonder how much this has to do with the age of our domain
> and the fact that it begins with “b”. :)
>
> The only thing I’ve been contemplating is a local spamtrap and DNSBL.
> We have a site that’s regularly trawled for email addresses, so
> seeding it should not be too difficult…
>
Hi,
You want to give the RBLs a bit more time to kick in, you could consider
greylisting (or postscreen after-220 checks which also cause a delay and
a retry).
Regards,
Tom
