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 220.127.116.11/24 6663 339K 18.104.22.168 6659 303K 22.214.171.124 3918 188K 126.96.36.199 3190 162K 188.8.131.52/10 2648 132K 184.108.40.206 2490 127K 220.127.116.11/13 2252 109K 18.104.22.168 2185 111K 22.214.171.124/12 2165 106K 126.96.36.199 2014 96672 188.8.131.52 1877 90096 184.108.40.206 1853 88944 220.127.116.11 1750 105K 18.104.22.168 1686 80768 22.214.171.124/11 1529 75816 126.96.36.199 1502 72096 188.8.131.52 1455 69840 184.108.40.206 1422 68256 220.127.116.11 1320 65136 18.104.22.168/11 1294 63600
Finally, 22.214.171.124 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.
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.