Wandering Thoughts archives

Weekly spam summary on November 11th, 2006

This week, we:

• got 15,129 messages from 287 different IP addresses.
• handled 21,714 sessions from 1,659 different IP addresses.
• received 193,764 connections from at least 45,843 different IP addresses.
• hit a highwater of 35 connections being checked at once.

Connection volume is down from last week. The highwater is much higher and was set sometime Thursday; before then we had the same highwater as last week.

This shows a Thursday peak as well, ramping up on Wednesday and sliding down on Friday.

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
72.244.103.210        14789    692K
69.31.86.14           11047    663K
203.158.55.63          8565    436K
64.166.14.222          6958    334K
193.252.22.158         5086    305K
212.216.176.0/24       4894    241K
213.1.255.134          4866    234K
210.108.75.241         4186    201K
64.32.177.103          3525    165K
213.4.149.12           3364    175K

It's a miracle: 213.4.149.12 has dropped from consistent first place all the way down to barely ranking this week. Overall it's a bit worse than last week; the high end is worse and the low end is not much better.

• 72.244.103.210 returns from two weeks ago, and is still a Covad something-or-other.
• 69.31.86.14, 193.252.22.158, and 213.4.149.12 all return from last week.
• 203.158.55.63 is an iinet.net.au customer machine in the CBL.
• 64.166.14.222 is a Pacbell DSL line, returning from September.
• 213.1.255.134 and 64.32.177.103 kept dumping bad HELOs on us.
• 210.108.75.241 is a Korean IP address with no reverse DNS.

Just over half of this week's top ten are returning IPs that we've seen before. I tend to find this depressing.

Connection time rejection stats:

  43509 total
  23493 dynamic IP
  16892 bad or no reverse DNS
   1744 class bl-cbl
    221 class bl-sdul
    194 class bl-njabl
    189 class bl-dsbl
     59 class bl-spews
     46 class bl-sbl
     40 class bl-ordb
     35 cuttingedgemedia.com

Two of the top 30 most rejected IP addresses were rejected 100 times or more; 64.166.14.222 (567 times), and an internal UofT client machine that has apparently been misconfigured to try to use us as its server. Fifteen of the top 30 are currently in the CBL and five are currently in bl.spamcop.net.

This week's gifts from Hotmail:

• 2 messages accepted.
• 3 messages rejected because they came from non-Hotmail email addresses.
• 38 messages sent to our spamtraps.
• 2 messages refused because their sender addresses had already hit our spamtraps.
• 1 messages refused due to its origin IP address being in SBL38620 (listed March 4th 2006, and it's apparently an Internet cafe in Nigeria with a satellite Internet connection).

And the final numbers:

I don't like the upward trend compared to last week, but there's nothing I can do about it.

This week's bad bounce targets are all over the map. Almost nothing got hit more than once ('olsak' is the leader, at 4 times, followed by 'noreply' and a couple of old usernames here at 3 times), and the popularity of Slavic women's first_lastname usernames continues its slide. Apart from that there are words like worm and zodiac, old usernames, vaguely plausible usernames like semerad, a certain amount of capitalized names like Kardel, one XXoX, a lot of random jumbles like zywcfnhiqtji, and the return of a few Linux ALSA function names.

(I have no idea why 'snd_pcm_hw_params_get_buffer_size' is so absurdly popular with spammers as the origin of their forged spam, but it is and has been for years.)

A thought about disaster recovery planning

Disaster recovery planning is famously difficult, and not just because it's a hard subject. In fact there seems to be a kind of repulsion field that makes people either shy away from thinking about it or dismiss it as something that they can't do anything about anyways. (The latter is the 'if we have a serious fire the organization's dead anyways, so why worry about the backups?' mindset.)

I've come to think that one significant reason for this is that when you plan realistically, you wind up with a list of disasters that you are deliberately and consciously not going to be able to recover from. The problem with this is that choosing to lose data and systems in some circumstances never sits very well with people, sysadmins especially; we feel that our job is to save data, not to callously throw it away because we didn't want to try hard enough.

However, if you don't tackle the issue, you're not choosing to lose data in cold blood, you're losing data because you never thought about the problem. It's a lot easier to contemplate losing data through ignorance than through apparent choice.

(And even if we accept that we can't do anything, actually thinking about it makes us feel helpless, which people generally dislike.)