On Oct 29, 2015, at 4:04 PM, Bill Cole <sausers-20150...@billmail.scconsult.com> wrote:
> 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. Sorry to reply to Bill instead of Alex, don’t have the original message. I am a bit surprised that even this long after the original report how few RBLs have this listed: http://multirbl.valli.org/lookup/23.246.233.6.html > > [ 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 Only one piece of the headers there looks a bit odd to me, but I may not be seeing the same thing. :) Charles > >> 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.
