Weekly spam summary on February 10th, 2007
This week, we:
- got 15,405 messages from 262 different IP addresses.
- handled 23,822 sessions from 1,467 different IP addresses.
- received 258,033 connections from at least 76,977 different IP addresses.
- hit a highwater of 7 connections being checked at once.
The overall volume is about the same as last week; technically it's up a bit, but I figure it's within the normal fluctuation levels by now.
It's interesting that the connection count doesn't seem to completely tied to the number of new IP addresses; the highs and lows don't match up, although there's a general correlation.
Kernel level packet filtering top ten:
Host/Mask Packets Bytes 220.127.116.11/27 44955 2696K 18.104.22.168/24 29284 1756K 22.214.171.124 18732 974K 126.96.36.199 12807 615K 188.8.131.52/24 8622 389K 184.108.40.206 6667 312K 220.127.116.11 6370 298K 18.104.22.168 5001 240K 22.214.171.124 4846 232K 126.96.36.199 4681 219K
Yow. Things are significantly up over last week, and we have a serious winner.
- 188.8.131.52/27 is totallyfreeld.net. They used to be SBL-listed,
but for some reason they got taken out, and apparently they wasted
no time in opening up the floodgates.
- 184.108.40.206 (terra.es), 220.127.116.11 (PacBell DSL), 18.104.22.168
(on the SORBS DUL), and 22.214.171.124 (bad
HELOs) all return from last week.
- 126.96.36.199 tried too many bad
- 188.8.131.52 is a Bellsouth ADSL IP that we consider dynamic.
- 184.108.40.206 also had too many bad
HELOs and returns from early January.
It's been quite a while since we had so many returning IPs, but the real standout is clearly 220.127.116.11/27 by a mile, beating even centrum.cz's 18.104.22.168/24 (itself well up over last week). Given that they somehow got out of the SBL, I am now very glad that I put in our own kernel-level blocks (and I have now made sure that they are listed in pretty much every level of block that we have, just in case).
Connection time rejection stats:
73757 total 45224 dynamic IP 21356 bad or no reverse DNS 5533 class bl-cbl 221 class bl-sdul 211 class bl-dsbl 207 class bl-pbl 101 class bl-njabl 95 class bl-sbl
Things are distinctly up compared to last week, despite the not markedly higher overall connection count. As usual, everything except the CBL is relatively useless, although I suspect that the PBL and the SORBS DUL would jump significantly if we didn't already have our own blocks for those.
The two leading SBL listings were SBL50738, an advance fee fraud spam listing from this month (12 rejections) and SBL50181, a compromised Brazilian web server abused by advance fee fraud spammers since November (10 rejections, and we've seen it before).
Three of the top 30 most rejected IP addresses were rejected 100 times
or more this week: 22.214.171.124 (259 times, bad DNS), 126.96.36.199 (143
times, dynamic IP), and 188.8.131.52 (127 times, 'dynamic' IP). 16 of
the top 30 are currently in the CBL and 18 are currently in
This week Hotmail managed:
- no messages accepted.
- no messages rejected because they came from non-Hotmail email addresses.
- 48 messages sent to our spamtraps.
- 2 messages refused because their sender addresses had already hit our spamtraps.
- 6 messages refused due to their origin IP address (3 from the Cote d'Ivoire, two from Gilat Satcom, and one in SBL50431).
And the final numbers:
|what||# this week||(distinct IPs)||# last week||(distinct IPs)|
Apparently some sort of miracle happened this week and the spammers all stopped forging us. Alternately, my software is broken.
Bad bounces were sent to only 11 different bad usernames this week;
E7D6' got two hits and everyone else got one. Bounces went to three
hex bad usernames (
3E4B), four actual ex-users,
two things that could be valid usernames, and two random alphabetical
jumbles. Bounces came from machines in Germany and Russia, among other
Colour me pleasantly happy and certainly hoping that this keeps up. But I'm not going to hold my breath.
A temptation with challenge/response anti-spam systems
Every time I see a mail from a C/R system, I get more and more tempted to teach our mail filtering infrastructure about the most common ones, so that it can automatically acknowledge the challenges, discard the messages, and not bother the users with them at all.
Will this acknowledge a lot of spam, and thus dump it on the people operating those C/R systems? Sure, but that's not our problem. And I'd clearly be doing our users a service, especially if C/R systems get widespread.
(This is another example of how C/R systems try to work by offloading your spam problem on precisely the wrong people. The only way they can 'work' at all is if most of the mail addresses you challenge don't even exist; otherwise you are reaching either spammers or pissed off people, neither of which have your interests in mind.)
As a special bonus prize, I could even hack our system to do this even
for local addresses that don't actually exist, since it's perfectly
possible to automatically acknowledge the challenge and 5xx the
command at the end of the SMTP conversation. I'd have to make sure that
this only happened for single-recipient email, but that describes all
of the C/R email I'd want to do this to.
(Ob-attribution-darnit: I've had this thought for a while, but the impetus to actually write this entry was provided by reading about a related temptation with C/R systems here.)
Link: Why the ease of installing Java matters
In Java in The Land of Make Believe, Ryan Tomayko unloads a righteous rant about why Java's license matters and what effects it has in the Linux and *BSD worlds, with great bits like:
If you want to get on the bad side of software developers and system admins, the fastest route is to waste their time.
Amen. What he said.
(The good news is that Sun GPL'ing Java may finally be changing all of this mess, which Tomayko happily acknowledges.)
(From many places, but I saw it originally on Planet Python, as Tomayko's blog is syndicated there.)