March 2003

I recently wrote about some thoughts to combat spam, that would involve cash micropayments for some e-mail. I wasn’t entirely happy with that idea, and I’ve refined it a little.

My idea, as it currently stands, is this:

Everyone who receives e-mail would maintain a blacklist (of pestilential senders) and a whitelist (of good senders). Anyone not on either of these lists is said to be on the “graylist.” Everyone who sends e-mail would be required to put a small amount of money–perhaps one dollar–into an escrow account.

When Alice sends Bob a piece of mail, before Alice’s mailserver actually delivers the message, it checks to see whether she is on Bob’s blacklist or whitelist.

If Alice is on neither, that is, she’s on the recipient’s graylist, a “hold” is placed on one cent in her escrow account by her mailserver, and the message is delivered. When Bob receives her e-mail, he can choose whether her e-mail is legitimate or not. If it is legit, the hold on that penny is released. If not, the penny is deducted from her account (perhaps paid to Bob, his ISP, a charity, or some combination). When declaring a message to be legit, Alice is added to Bob’s whitelist. If not, it goes on his blacklist (this process could be simplified a bit so that responding to a message automatically whitelists the sender).

If she is on the whitelist, the message is delivered without involving the escrow account at all.

If she is on the blacklist, the message is not delivered and one penny is automatically deducted from her escrow account.

The problem with this is that it adds quite a lot of overhead to graylist and blacklist correspondences, and some overhead to whitelist ones. The Internet hasn’t had any successful micropayment systems yet.

What about using a non-cash system? In theory, this system could work using valueless certificates. One would apply to a “trusted certificate-issuing authority” for a bundle of, say, 100 certificates. The process could be designed to thwart scripts that would simulate human action, and one could be prevented from receiving more than 100 certificates/month (for example). The authority would deposit 100 signed and encrypted certificates in your “escrow account,” and in all other respects, the system would function similarly. When Bob’s mailserver (or perhaps Bob’s own mail software) receives Alice’s message, it checks the certificate against the certificate-issuing authority; if it is valid, the message is presented to Bob (who can still choose to blacklist it, if he wants). If not, the message is bounced.

Note that this system is pretty similar to the authenticated e-mail that some people would like us to use anyhow. This would also involve a similar amount of processing overhead. And in fact, the cash-based system would need to use pretty much the same system of signed and encrypted certificates.

There are some broader differences between the cash-based and cashless systems. If everyone can receive a bounty for identifying spam, even a tiny one-penny bounty, more people are likely to actually do it, making spam less tenable. (A system like this would also make it attractive for technically savvy users to create “honeypot” e-mail addresses to attract spam, automatically blacklist it, and collect lots of pennies.) And the idea of a certificate-issuing authority is problematic, as they would, in effect, be gatekeepers: if you can’t get your certificates, you cannot communicate by e-mail. The authority could charge money for issuing certificates, or otherwise abuse this power. If these certificates were issued automatically and solely as digital representations of pennies, the system should be less prone to abuse. There would need to be more than one authority.

So if I’m saying that the whole validation process should be added on without a surcharge being imposed (which I am), how would this be funded? All e-mail host operators should pitch in to fund the system. I have no idea what the numbers on this would look like, but I suspect that they would save more thanks to reduced traffic than the system would require them to contribute.

Side note: there’s now an official Anti-Spam Research Group. Maybe I should try to get this idea in front of them.

[Later] Interesting to note that Robert Cringely came up with somewhat similar micropayment system for fighting spam.

[Later still] David Nunez pointed out this article on a “spam tax.”

I’m trying to find a content-management system, mostly for running a limited-access discussion forum. I’ve already looked at Drupal, which is pretty nice, but I have not yet figured out how to make it fully support Japanese, which is a make-or-break feature.

I can get limited success writing Japanese in Drupal, but (in the best-case scenario so far) the characters wind up being escaped to numeric Unicode entities, which are not editable after being posted, and apparently are not searchable.

I also looked at the Slash engine, but A) the installation instructions assume you are root, assume you are more technically adept than I am, and are very sketchy all around, and B) has the same problems with Japanese.

I suspect the Japanese-handling problems in both Drupal and Slash could be fixed with some minor coding changes, but I don’t know where to start. Messing with the template charsets doesn’t do it.

Other desirable features:
Threaded message structure
Moderation/karma points a la Slashdot
Flexible permissions setup
Straightforward templating for admin

None of the other CMSs or web-BBSs I’ve looked at so far have forum threading,

[Later] Seems that I can almost get Japanese working right in Drupal (why do I think of towering drag-queens every time I say that?) after all: there was a configuration issue that was causing the Japanese to be escaped. I turned that off, and now everything is close to hunky-dory, except for one thing: searching on Japanese terms always returns no results.

[Still later] Turns out a Japanese drupal user has developed a patch. This helps some of the problems I was having (and was already groping towards solving). Still doesn’t enable Japanese searching, though.