2005-07-24
Spam summary for July 23rd 2005
It looks like the hope from last week that spammers had stopped forging University of Toronto subdomains as the origin of their spam was in fact just a hope. 'Nonexistent local user' rejections are back up like clockwork. Oh well; it would have been nice.
IP level rejections:
Host/Mask Packets Bytes 212.216.176.0/24 6663 339K 213.4.149.11 6659 303K 151.189.20.157 3918 188K 83.103.57.17 3190 162K 61.128.0.0/10 2648 132K 193.111.201.127 2490 127K 221.216.0.0/13 2252 109K 194.30.33.37 2185 111K 219.128.0.0/12 2165 106K 216.7.201.43 2014 96672 194.250.136.10 1877 90096 68.63.102.114 1853 88944 66.235.196.26 1750 105K 220.245.160.88 1686 80768 218.0.0.0/11 1529 75816 217.52.32.185 1502 72096 65.214.61.100 1455 69840 193.41.153.65 1422 68256 216.109.197.126 1320 65136 220.160.0.0/11 1294 63600
Finally, 24.156.64.52 has dropped entirely out of the list. A number of other apparent dynamic/DHCP/cable modem sources are on it, though; I'm not surprised. Zombie spam is the big problem of these days.
Connection-time rejections:
24003 total
8375 rejected due to bad/missing reverse DNS information
1236 class bl-cbl
698 class bl-ordb
509 class bl-dsbl
335 class bl-spews
330 class bl-sbl
162 class bl-sdul
158 class bl-njabl
10 class bl-opm
Surprisingly, rejections have plummeted overall, although they're broadly like last week's. We had about 186,000 SMTP connections from at least 35,000 different IP addresses, which is somewhat up on our usual connections volume (I usually expect about 120,000 over the course of a week).
We rejected 9,200 IP addresses at connect time, let 1,330 machines get as far as the SMTP banner, and actually accepted email from only 197 different IP addresses. This is about the depressing ratio mismatch I expected from previous weeks.
At this point I'm running out of interesting statistics to take more looks at, so I'll probably flip away from weekly spam stats posts in favour of just generating the data and archiving it for long-term local analysis. (I suppose I could do a breakdown of connection time rejections by source ASN. (But if I do that, I should probably explain 'ASN' first.))
The necessary evolution of mail servers
In a comment on my Legend of Debian post, Chris Wage wrote in part:
Most of the servers I run are: webservers, mailservers, CVS servers, etc. These are things for which well-established stable software has existed for years. I don't need bleeding-edge software to do them. I need stable representatives of that software that are supported by security updates but don't otherwise change.
I have to disagree with this in the case of mail servers.
Unless you actively enjoy getting spammed your mail server software needs to be upgraded on a regular basis, because spammers evolve their techniques all of the time. One of my major issues with Debian Woody is that by the end of its life, its default mailserver (Exim 3) is clearly not adequate to the job of stopping spam.
This means that if you do spam filtering at all, you're going to need regular mail server software upgrades in some form. (This also means that you're going to need to evaluate upgrades if your operating system vendor doesn't deliver regular ones.)
Virus authors also evolve their tricks all the time, so people doing virus filtering need to think about this issue too.