Spam on the Debian Lists
Pascal Hakim talks about the amount of spam received by the DebianLinux mailing lists, . To anyone that doesn't get a lot of email, or deal with email professionally, hopefully this gives you some concept of the scope of the problem. It's beyond ridiculous.
Everyone once in a while, someone complains about spam on Debian lists. I keep promising people some automated numbers and graphs, but haven't gotten around to it. In the mean time, feel free to look at these.
Type
19/5/2004
18/5/2004
Emails allowed through
2,082
2,287
B locked by spam filters
5,239
6,068
Blocked by Debian RBL
8
48
Blocked by Postfix mime checks
1,770
1,892
Blocked by Postfix body and header checks
30,700
32,608
Blocked by Sender rejects
20,476
20,267
Emails delivered out to subscribers
1,489,400
1,350,760
Hopefully those numbers show exactly what we are up against. And yes, you are reading those numbers right. 3.5% of messages or so that are sent to a list actually make it to the list.
I've been fairly vocal about my dislike of blacklists and challenge response systems as a way of controlling spam (see SpamBlacklistsConsideredHarmful and ChallengeResponseSystemsConsideredHarmful). However I would like to encourage everyone who maintains, or has influence over the maintainer of, a domain name to investigate SPF, the SpamPreventionFramework. The very short version of how it works is that domain name administrators add an entry to their DNS records which lists the mail servers which are allowed to send mail for that domain. This doesn't attempt to directly stop spam, instead it aims to make forgery of the senders address as difficult as possible. Regardless you are better off reading the executive summary than listening to me.
SPF isn't trivial to implement and will only be effective if it becomes widely deployed (much like anti-relaying rules which were deployed in the mid-ninties), but what appeals to me is that it doesn't require collateral damage. That's not to say there won't be any, but rather that it's all technically avoidable (where as it's impossible to avoid with blacklists or CR systems).
I hope to have the changes made to spack.org, shand.net and wetafx.co.nz join the company of google.com, aol.com and oreilly.com in the near future. I'll report back ...