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.

Day Connections different IPs
Sunday 22,042 +5,058
Monday 26,755 +7,229
Tuesday 25,419 +6,811
Wednesday 29,058 +7,241
Thursday 32,172 +6,803
Friday 31,499 +6,677
Saturday 26,819 +6,024

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        14789    692K           11047    663K          8565    436K          6958    334K         5086    305K       4894    241K          4866    234K         4186    201K          3525    165K           3364    175K

It's a miracle: 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.

  • returns from two weeks ago, and is still a Covad something-or-other.
  •,, and all return from last week.
  • is an iinet.net.au customer machine in the CBL.
  • is a Pacbell DSL line, returning from September.
  • and kept dumping bad HELOs on us.
  • 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; (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:

what # this week (distinct IPs) # last week (distinct IPs)
Bad HELOs 1780 151 1298 140
Bad bounces 482 416 370 256

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.)

spam/SpamSummary-2006-11-11 written at 23:41:45; Add Comment

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.)

tech/DRPlanningThought written at 00:32:51; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.