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.
http://pastebin.com/vxrUdEvy
As of right now, 23.246.233.6 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.
[ INTENTIONAL VAGUENESS FOLLOWS ]
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 whois.arin.net '+ 23.246.233.6'"
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.
