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 188.8.131.52 18633 969K 184.108.40.206 7820 469K 220.127.116.11/11 5254 256K 18.104.22.168 4974 253K 22.214.171.124/10 4500 230K 126.96.36.199 3420 150K 188.8.131.52 2765 129K 184.108.40.206/11 2096 105K 220.127.116.11 2073 99504 18.104.22.168 2059 124K
- 22.214.171.124 is our poster spike baby, jumping into clear first place this week after only coming in second last week.
- 126.96.36.199 and 188.8.131.52 kept trying to send us stuff that had already hit our spamtraps.
- 184.108.40.206 had bad reverse DNS (it's also currently in SORBS).
- 220.127.116.11 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
- 18.104.22.168 is a Wanadoo France dialup. The heat death of the universe will happen before we talk to them.
- 22.214.171.124 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 126.96.36.199 (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: 188.8.131.52 and 184.108.40.206, 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.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)|
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
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.
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.