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