spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Cole" <>
Subject Re: Filtering snowshoe spam
Date Thu, 29 Oct 2015 20:04:26 GMT
On 29 Oct 2015, at 11:09, Alex wrote:

> Hi,
> I've been receiving tons of messages not being tagged by spamassassin
> on one host, despite it hitting bayes999, and wanted to see if there
> was something that could be done.
> As of right now, isn't listed on zen or any other popular
> RBL, and there doesn't appear to be anything standing out in the
> header that could be used.


Well, there might be, if you look for things that might have been added 
by the spammer to trace the source of "sanitized" spam reports, for the 
purpose of listwashing.

I'm VERY careful about adding SA rules that hit on non-standard+non-X-* 
headers broadly, but those sorts of rules can be very productive if you 
have adequate time and mailstream to test them. Snowshoers are the 
vanguard of the spam arms race and can't seem to resist effectively 
giving their messages fingerprints

> I realize I could write some body rules
> (this is what I miss most about SOUGHT), but as you know it's often
> too late to catch such a moving target. I'm finding very large blocks
> of IPs are typically involved with these campaigns.

Or in this case, not so much: "whois -h '+'" 
shows a /28 SWIP'ed earlier this month.

I wish there were a usable way to automate whois lookups across RIRs to 
identify recently reassigned small blocks like that to add a 
probationary point to SA scores (i.e. IP in a /25 or smaller net 
reassigned within 30 days => score 1.0) but unfortunately the various 
bodies managing IP addresses are in aggregate an obstinately 
anti-interop collection of narcissists, many of whom have actively 
fought against any publicly usable federation of their precious 
proprietary databases. (BUT: see below)

> I have dozens of these that get through before they are blacklisted
> and would like a more general or broad solution.

Tools used in front of handling messages can help:

1. Greylisting. As you seem to understand, these don't take terribly 
long to ruin the reputations of their IPs and/or the domains of URLs in 
their bodies, so making the sender wait 10 minutes can often get you 
past the window of novelty.

2. DNS patterns. Note that the HELO name resolves to the client IP but 
that IP's PTR resolves to a generic name programmatically derived from 
the IP. The spammer has taken care with DNS to get affirmative SPF 
results for the envelope sender and HELO, but hasn't bothered to fix his 
PTR? Sloppy spammer...

3. Hacky imperfect whois-checking scripts. I wouldn't advise this on a 
high-volume system, but if you can tolerate missing some cases in order 
to err on the side of safety & taking an extra half second on every SMTP 
session, it isn't terribly hard to identify ~75% of the snowshoe blocks 
at connect time (and almost never penalize a legitimate sender, because 
legitimate senders with SWIP'ed IP ranges tend to keep them for more 
than one billing period.)

> They typically hit at least bayes80 with sa-3.4.1.
> Are there any routines out there that can extract the last-external IP
> and either store it in a file or otherwise make it available to be
> added to a check_client_access map?

I'm not aware of any existing canned tools that try to automate 
detection of messages that SA has made a mistake on and block by IP 
based on that second-guessing. It seems like an unwise tactic.

View raw message