Whitelists and Blacklists (by alaric)
In my previous post, I spoke of technologies that prevent [email spoofing](E-mail spoofing) by reliably tying the mail server sending a message to a domain, or checking that the message is from who it claims to be from.
These measures alone can reduce spam - in the short term - because, right now, lots of spam is spoofed. But as these technologies spread, spammers will set up lots and lots of domains, put valid SPF and CSV records in them, and start spamming.
When a new domain appears, it will be in no whitelists and no blacklists. It could be a newly started company or project or vanity domain, or it could be a spammer. There's no way to tell until it's sent enough spam to get noticed and put on a blacklist, or it signs up to a whitelist. It's innocent until proven guilty. The problem is that it'll probably be worthwhile for spammers to register a few domains a day, or perhaps set up some software to register one every ten minutes, so they can't be blacklisted fast enough.
I think there are two solutions to this:
Whitelists becoming more prominent
Perhaps one way of distinguishing new legitimate domains from new spammer domains would be to make whitelist membership the norm. A business setting up a new domain would either use their existing CSV-whitelisted mail servers, or get their new domain on a SPF/DomainKeys whitelist before attempting to actually use it.
The problem is, whitelists currently boil down to:
- ISP internal whitelists, where one contacts AOL, Hotmail, etc. and individually applies to get on their whitelist, paying fees or signing acceptable use policies as appropriate. This is a bit laborious.
- Expensive third-party whitelists, such as Sender Score Certified (formerly known as Bonded Sender) or Habeas. These are a bit expensive.
Perhaps we need a third kind of whitelist, perhaps run (like the blacklists) as a community non-profit project. Anyone who signs up gets to join the list after agreeing to an acceptable use policy, but they have to peform a Turing test and/or submit significant Hashcash (perhaps a 38-bit or so stamp, which would take an hour to compute on fast hardware), along with IP-based rate limits (about one domain per week), and they get struck off if they are reported spamming. That way, it'd be hard for spammers to keep registering new domains on the system.
Use Hashcash instead
We can still use SPF/CSV/DomainKeys to block phishing attacks, but give up on them as an anti-spam measure and use Hashcash instead. Hashcash doesn't need any whitelists or blacklists, and instead works by checking that the sender put a certain amount of effort into sending the message, which means that an off-the-shelf computer can send a few Hashcash-stamped messages per second rather than thousands of them, which dramatically reduces the economic incentive to spam.
Hashcash is being a bit ignored by most organisations worrying about anti-spam measures - does anyone know why? Just insufficient marketing? I know there are criticisms of Hashcash, but it still looks pretty compelling to me; a study suggests that there is no suitable level of hashcash stamp that can be requested that will reduce spam to acceptable levels without impacting legitimate mail sending, but I find their reasoning pessimistic (spammers using botnets are a problem we need to solve anyway for security reasons - and ebusiness companies wanting to send lots of legitimate order-status and newsletter emails can, likewise, run a legitimate distributed computing effort on their office desktops; and I suspect that reducing a machine capable of sending thousands of messages per second to one that can only send ten per second, thus increasing the cost of hardware required to send N spams per second by a factor of one hundred, will have knock-on effects in the spam industry; pushing little guys out of business, raising prices so less customers buy their services, etc).
Wed 13th Sep 2006 2:03 pm 
Subscribe