A free-market approach to canning spam
Fred Goldstein, July 2003
...So long as email is free, and the cost of bandwidth and computing are both going down, spammers will thrive. ...
.
...Spam is sensitive to the cost of a message. Spammers send off messages by the million, and get a miniscule percentage response. Micropostage only has to be costly enough to make spam unaffordable....
...A list server could issue its own micropostage, for free, to its own lists. A properly run listserv would easily get whitelisted...
...If a micropostage service goes belly-up, then users will be left holding worthless stampettes. Indeed the user is left holding the bag if a service gets considered spam-friendly and is dropped from whitelists...
Everybody, it seems, hates spam. And almost everybody wants to do something about it, or at least wants somebody to do something about it. But nothing is effective. A few schemes do see widespread use.
- Blacklists allow
mail recipients to block incoming mail from known spam senders.
This helps, but it is far from perfect. Spammers routinely hijack
new machines to use as relays. And legitimate mail is sometimes
blocked when an ISP's server gets hijacked, cutting off mail from
ordinary users.
- Filters examine the text of incoming mail to see if it looks like spam. Some filters, like Spam Assassin, apply specific tests. Others depend on "Bayesian" analysis,
wherein words are identified as being more likely components of spam or
non-spam. Filtering helps catch some spam, but some spammers
learn how to evade most filters in an ongoing arms race. And
non-spam mail can be incorrectly tagged as spam. Even worse, the
spam is still delivered; client-side filters hide spam but don't reduce
its volume. Or is it worse when an ISP filters incoming mail,
incorrectly discarding its subscribers' real mail when the spam filters
have false positives?
These approaches are essentially unsatisfactory. The rate of spam keeps increasing, tying up network resources, client disk space, and users time. Real mail is lost in the flood of spam. And it is going to get worse. So long as email is free, and the cost of bandwidth and computing are both going down, spammers will thrive... unless something serious is done. While some have suggested capital punishment for spammers, the likelihood of a realistic regulatory, political or judicial solution is small. Spammers have influential friends in Congress and elsewhere who are likely to protect them. Most proposed anti-spam laws have few teeth; some would actually give spammers new legal protections. And since most spammers are criminals to begin with, they are likely to flout any prohibitions of their activities.
Therefore the solution must, like so much of the Internet, be based on a technical approach, one that also takes into account the business realities of the medium. A number of ideas have been put forth that have one feature in common: They all maintain the free as in lunch price of email. The mere notion that anyone should ever pay to use email is simply unthinkable. Alas, it is also necessary. Alternatives simply have not worked.
A simple approach is to simply use authentication. Certificate-based authentication systems can guarantee that a sender is who it says it is. This should discourage spammers, who take advantage of the weakness of the Internet's mail protocol, SMTP, to obscure their tracks. But a spammer could do a lot of damage before users discovered that a valid certificate was hijacked. Authentication alone is unlikely to do the job. Certificate-based authentication may be adequate to identify known "friends", senders whose mail is always accepted, but another mechanism is needed to authorize mail from strangers while not allowing mail from spammers. Note that non-cryptographically-protected whitelists are unreliable, because spammers forge message headers.
One proposed scheme, "hashcash", requires the sender to perform some meaningless calculations as the price of postage. This discourages spam but is generally wasteful, and favors spammers who hijack large processors. CAMRAM uses a processing-based micropostage model, using processing as the price of a stamp.
I suggest that the key to ending spam is to establish a very simple, decentralized scheme of purchased micropostage. Now that is a loaded word -- cash-based micropostage schemes have come and gone, none attracting many friends. But most such schemes have been rather complex and thus costly to implement. Micropostage is often designed as a kind of electronic funds transfer scheme, wherein the sender is making a small payment to the recipient. This requires transactional integrity, a rather compute-intensive requirement, in order to guarantee that all funds are precisely accounted for. It is also unnecessary when the only purpose of micropostage is to stop spam. Spam prevention needs only to raise the cost of sending mail to strangers to a level slightly higher than zero.
Spam is sensitive to the cost of a message. Spammers send off messages by the million, and get a miniscule response rate. Micropostage only has to make mail costly enough to make such mass mailings unaffordable. True "opt-in" commercial email, the type sent by honest merchants to their customer lists, is more valuable and likely to still be sent. And private mail is probably even more valuable. But users do not want to be bothered by thinking about the price of email. It has to look free to the bulk of consumers, who don't send thousands of messages a month to strangers.
A key element of this spam-prevention system is the stampette. Every message sent to a participating receiver requires one stampette, unless, perhaps, the recipient has the sender on a whitelist of authenticated friends. When mail bearing a stampette is received, it is verified in real time against its issuer, the micropostage service. The receiving message transfer agent (SMTP daemon) doesn't accept incoming mail until its stampette is verified against the stampette's issuing micropostage service, which "cancels" it (marks it as such in its own database) so that the same stampette can't be used over and over by a spammer. This is the most resource-intensive part of the process, because the micropostage service has to keep track of the status of a large number of stampettes that it has already sold. A large micropostage service might need a very powerful cluster of computers, or might choose to issue its stampettes against a diverse set of servers. Still, the overall cost of doing this is almost certainly much lower than the cost of today's flood of spam.
The price of each stampette is set by the market. It is bounded at the high end by competition, because the micropostage service business should have open entry. It is bounded at the low end both by the cost of running the micropostage service and by a simple rule: The recipient of the mail (typically a POP server) can choose to accept or decline stampettes from whichever micropostage services it chooses. It is a whitelist system, so stampettes that come from an unknown or untrusted micropostage service are simply not accepted. In practice, it's likely that stampettes will gravitate towards a common price range.
So if the GuangZhou Second Micropostage Service sells its stampetts for, say, 1 million per yuan, which even a spammer can afford, then the worlds' mail recipients will decline such stampettes. There's also a real cost of validation, which bounds the low end, but I'm assuming that Moore's Law will reduce that effect over time. So in practice, there will probably be services putting out whitelists of "good" micropostage services, or blacklists of bad ones, like today's RBLs (real-time black hole lists). But the lists will be smaller, because they do not need to list mail senders, only micropostage sellers.
A realistic price strikes me as being a few thousand stampettes per dollar or Euro. So every ISP could buy them in bulk and issue its retail subscibers a monthly ration of, say, a thousand. That would cost around a quarter per subscriber, and save much more than that in the reduced cost of handling spam. Major ISPs could, of course, issue their own; however, if they issue them in sufficient quantities to spammers, users might revoke their whitelist status.
Mailing lists are a different matter. A list server could issue its own micropostage, for free, to its own lists. Or users could allow simple certificate-based authentication for list servers. A properly run listserv would easily get whitelisted; subscribers who sign up for a mailing list would simply add the server to the whitelist. Because the list server would be validating its own mail, the third-party realtime transaction would not need to occur; the validation would simply be part of the delivery process.
Corporate users would buy stampettes in bulk -- these would only be needed for external mail, of course, since incoming stampette checking would take place at the public Internet gateway. If fifty bucks buys a hundred thousand stampettes, it will be in the noise compared to the upstream bandwidth cost.
The stampette itself is similar to a digital signature. It is a special mail header field which identifies the issuer (to check against a whitelist and then contact for validation/cancellation) and contains a unique and non-obvious stampette identifier string (so that a specific stamp can be cancelled). The identifier is encrypted using the issuer's private key; the user's whitelist contains the issuer's public key. This prevents forgery, spoofing, or "man in the middle" attacks.
This approach does pose some risks to users. If a micropostage service goes belly-up, then users will be left holding worthless stampettes. Indeed the user is left holding the bag if a service gets considered spam-friendly and is dropped from whitelists. The micropostage service gets its only revenue from stampette sales, so it depends on repeat business. So both sides have a vested interest in keeping the service operating and viable, but both sides lose if the market chooses otherwise. Perhaps users will be best off with a stock of stampettes from two separate services.
And for the scheme to be implemented, mail clients need to be modified to allow the user to attach a stampette or perhaps a "friends and family" certificate. Likewise, mail receiving servers (typically POP or IMAP servers, which act as proxy SMTP daemons for their users) need to implement the validation protocol. Still, there should be room to add it to existing products and even keep creaky old SMTP as the mail protocol.
This system maintains the key goodness of the Internet: No centralized authority, no taxation, users empowered to accept or decline connections, and low cost. It's an example of how technology might fix a real problem. If, and only if, the user community is willing.
