From Adam Katz
(For details on filtering spam, see Anti-spam)
I know how to win the war on spam. The first step is acknowledging that we can do it, and the second step is actually accepting that we want to do it. However, doing this would have a number of consequences that certain companies (the ones that could actually win the war on spam) are financially dis-interested in undertaking. Namely, it would kill the spam-fighting industry, and that would cause some harm to the anti-virus industry, as spam fighting has become an extra service they tease you about so you'll pay the extra money to get the premium version of their anti-virus utility. Another major hurdle is that spam detection techniques are often closely held secrets, and revealing any part of that process is often quite taboo. We can't get very far until these issues are resolved, and we need backing by some heavyweight players (like Google, who recently bought anti-spam company Postini).
Contents |
Blue Frog
Back in 2006, an Israeli company called Blue Security had a spam-fighting service that was so successful and so effective that some of the world's larger spammers got together and actively attacked it. After receiving a massive distributed denial-of-service (DDoS) attack (and not handling it well at all), Blue Security announced that they were shutting down and moving into other industries (and that their Venture Capital backers actually went along with this!).
Blue Frog's model
Blue Frog worked as a service connected to a client-side filtering tool. Your email was hashed and published by Blue Security so that spammers could use it as a Do-Not-Spam List and remove your email from their lists without allowing them to farm new addresses. When you received a piece of spam, you would simply click a button to report it. Blue Security would then try to unsubscribe you. This unsubscription attempt would often result in taking down the spammer's servers (the spammer's profit paradigm is that you send out a few million spams and something like 0.01% of the recipients respond; 0.01% is a hundred customers/victims per million emails; this is only profitable if your servers are actually up and running when those recipients respond). The unsubscription request is considered fair under the US "CAN-SPAM" act, which requires marketers to accept one opt-out response per user.
The problem
The problem with the model is that Blue Security's servers were themselves not able to handle the load provided by a counter-attack from the spammer community. It was a centralized mechanism that had that single point of failure that proved their undoing. Another problem was that it was a subscription service, and therefore its user base was smaller than one might like for full effectiveness.
A new incarnation
So far, nobody has managed to re-create Blue Frog's mechanism with any degree of success. SpamCop and KnujOn are close, but they don't perform that final action of the opt-out request. KnujOn is novel in that they actually pursue bigger spammers directly, using their ICANN connections to shut down spam websites' registrars (the groups to whom KnujOn and SpamCop send their complaints to). This is making progress, but very slowly (especially considering that KnujOn is not an automated process, and it's run by a team of two people in their spare time).
It's time I added a proposal.
Do-not-spam registry
First, we need to re-create Blue Frog's do-not-spam list. Hashed emails is a great idea. However, we must address the problem in Blue Frog's model -- it cannot be centralized. Piece of cake: using a trackerless torrent in BitTorrent, we can publish pgp-signed regularly updated lists. The original poster is completely hidden (just like a CDN), and even if the signing agent is removed from the equation, the last published list will still be around for anybody to use. A second file should also be hosted by this mechanism. This file is the list of admins to whom opt-out requests should be sent, indicating that the traditional server-side requests (like those automatically generated by SpamCop) have fallen on deaf ears. Careful, this is the same trigger-finger issue that Blue Security was criticized for (encouraging retaliation, perhaps on par with "fight fire with fire" or "eye for an eye" mentality).
SpammerAssassin
SpamAssassin is already one of the most widely deployed spam filters out there. Let's write a plugin for it that reports all spam that is manually trained as such (sa-learn --spam). This should really be the default. There is almost never confidential information in spam; let companies that might have the problem disable this feature rather than requiring everybody else to enable it. SpamAssassin should not be the only implementation; we need as much penetration as possible, and that means we also need implementations for Thunderbird and Outlook.
Reported spam then goes through the motions at a service like SpamCop. After sending the report to the usual authorities (Razor, Pyzor, DCC, SpamCop, and KnujOn ...someday), this reporting agent (which I'm calling "SpammerAssassin" for now) will then check the Do-not-spam registry's "deaf-ears" list for that entry. If it's there, it sends an opt-out request.
The opt-out request must come from the filtering system (or another system controlled by the receiving party's mail administrators, preferably the MX record), or else we suffer the centralization problem and are again prone to attack (or filtering ... the spammers will obviously try to filter this with the same kind of attentiveness that we give their spam!). It should also randomly use one of several unsubscribe methods (including nothing at all, as we want to simulate a non-100% response rate so as to be fair to legitimate vendors accidentally caught in our cross-hairs), though we must be careful about the possibility of spammers using this mechanism to create attacks of their own (e.g. forged sender address, forged opt-out server).
Final thoughts
So my proposed Blue Frog re-implementation doesn't actually require a big-time player to facilitate, though it would very heavily benefit from direct support from SpamCop and KnujOn and the SpamAssassin community. I maintain that Google is powerful enough that they could probably implement this solution automatically (without even telling their users) and do away with the vast majority of the spam problem in a few weeks, but that would turn their investment in Postini sour...