Wandering Thoughts archives

2006-08-19

Weekly spam summary on August 29th, 2006

The SMTP listener crashed and was restarted around Wednesday at 2am, so some of the statistics are short this week. That said, this week we:

  • got 12,378 messages from 234 different IP addresses.
  • handled 17,251 sessions from 822 different IP addresses.
  • received 87,872 connections from at least 29,223 different IP addresses since Wednesday at 2am.
  • hit a highwater of 6 connections being checked at once, since Wednesday at 2am.

It looks like we had around 140,000 connections this week in total, which is up from last week. The other volume stats are about the same.

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes
213.4.149.12          18633    969K
80.65.49.38            7820    469K
218.0.0.0/11           5254    256K
64.75.176.18           4974    253K
61.128.0.0/10          4500    230K
196.15.9.55            3420    150K
72.244.103.210         2765    129K
220.160.0.0/11         2096    105K
82.127.59.99           2073   99504
193.252.22.158         2059    124K
  • 213.4.149.12 is our poster spike baby, jumping into clear first place this week after only coming in second last week.
  • 80.65.49.38 and 64.75.176.18 kept trying to send us stuff that had already hit our spamtraps.
  • 196.15.9.55 had bad reverse DNS (it's also currently in SORBS).
  • 72.244.103.210 is a Covad machine we consider to be a 'dialup', seen before back in July. Evidence suggests that it would have also been rejected for a bad HELO name.
  • 82.127.59.99 is a Wanadoo France dialup. The heat death of the universe will happen before we talk to them.
  • 193.252.22.158 is smtp1.wanadoo.co.uk, and is in SPEWS as S703 because, surprise surprise, it is spewing advance fee fraud spam.

(You might suspect that I have a low opinion of all Wanadoo properties. You would be correct.)

Connection time rejection stats:

  29928 total
  14000 dynamic IP
  12304 bad or no reverse DNS
   1492 class bl-cbl
    645 class bl-njabl
    229 class bl-spews
    211 class bl-sbl
    205 class bl-sdul
    173 class bl-ordb
    114 class bl-dsbl

This is down somewhat from last week.

Six out of the top 30 most rejected IP addresses this week were rejected 100 times or more, with the champion being 196.15.9.55 (360 times). 16 of the top 30 are currently in the CBL, 11 are currently in bl.spamcop.net, and two are in the SBL.

The SBL sources are the same as last week: 208.32.133.155 and 208.32.133.156, our friends 'Cutting Edge Media', SBL45150. Between the two of them they accounted for just over half of the SBL hits this week. Personally, I am hoping that they go away soon.

Hotmail is not making me any happier this week:

  • 6 messages accepted, at least three of which were spam.
  • 7 messages rejected because they came from non-Hotmail email addresses.
  • 13 messages sent to our spamtraps.
  • 2 messages refused because their sender addresses had already hit our spamtraps.
  • 1 message refused due to its origin IP address being a SAIX/Telkom SA DSL line.

Next week will likely see a drastic reduction in the 'non-Hotmail email addresses' category but an equivalent increase elsewhere, since I have just decided to accept hotmail.fr and hotmail.co.uk email from Hotmail's mail servers. (I may regret this.)

And the final numbers:

what # this week (distinct IPs) # last week (distinct IPs)
Bad HELOs 610 54 301 44
Bad bounces 34 33 25 23

Unfortunately the biggest source of bad HELO names this week was a University of Toronto machine that I may need to hunt down and get fixed.

Bad bounces went to 23 different usernames this week, in the usual variety: some old ones, some vaguely plausible usernames, and some random alphanumeric jumbles.

spam/SpamSummary-2006-08-19 written at 23:06:12; Add Comment

Documentation needs testing

One of the under-appreciated areas of writing systems documentation is testing it. And I don't mean proofreading it (although that's necessary too); I mean making sure that it is things like comprehensible, clear, correct, and complete.

Testing is vital, because documentation that is incomplete or incorrect is often worse than no documentation at all. Documentation creates confidence, which means that bad documentation lets people go wrong with confidence, turning a small mess into a much bigger one. ('But the instructions said to newfs /dev/sda1...')

Unfortunately, testing documentation is hard and time consuming. You don't really know if it's good until someone else follows it and things work, and this can be hard to arrange, especially in small or specialized environments. (This is a hidden benefit of part-time student labour at a university; it provides you with a steady stream of guinea pigs to test your documentation on.)

And of course for testing documentation on procedures, you need to try out the procedure in an environment where you can afford to fail. Which often means spare time and spare equipment, which can also be hard to get. (Testing overview and orientation documentation may be even harder; how do you test that someone learned enough from it to be useful?)

In the absence of good guinea pigs, your co-workers are the best testers you have. Unfortunately, it's usually difficult to get people to really take the time to go over the documentation carefully (unless people already get all this). After all, your co-workers either already know most of this stuff or don't need to, and they have other work to do.

(I've always liked to get pre-readers and the like, but it took a recent discussion of documentation to make me understand why and to see this issue.)

Sidebar: why you need other people

Documentation has to be tested by someone else for the same reason you can't thoroughly test your own programs; you're too close to it. You really need someone who's ignorant enough that they can't just fill in the blanks and the unclear bits on their own, without noticing.

(And part of the problem is that after a while, your initially ignorant person learns enough to start filling in the blanks on their own, and you need another guinea pig.)

Serious disaster recovery tests are the extreme example of this, where you send an accounting clerk out to the backup site with your instruction binder and a pile of backup tapes and see what happens.

sysadmin/DocumentationNeedsTesting written at 00:17:44; Add Comment


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

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