Slashdot Mirror
Penny Black Project Investigates Sender-Pays E-mail
Anonymous Coward writes "The Inquirer reports: Microsoft contemplating charging for emails. 'MICROSOFT IS UNFOLDING something it calls the Penny Black project in which people sending emails might have to pay for the privilege.' Microsoft's explanation of the project is here: The Penny Black Project." There are a lot of things going on at Microsoft Research -- no guarantee that particular ones are going to be released in the real world. (And Microsoft isn't the only party interested in sender-pays, or at least sender-risks-paying systems.)
People are focusing a lot on the idea of paying real dollars in order to send e-mail. The thrust of the research in this article appears to be for alternative "currency" models.
So for CPU cycles, here's what I think they are doing:
Every email account has a notion of a "ticket pool". A valid ticket is very expensive to create. Say, it takes 5 minutes to make one on a fast modern machine, at 100% CPU.
When I send an email, a ticket is attached to it. This ticket is required for sending mail (say, through the Hotmail SMTP servers, for example). No ticket, it bounces back to me. When I get a reply to the mail, or perhaps some other sort of acknowledgement from the receiver that they meant to receive the mail, I get credit back for the ticket I used.
In normal circumstances, you almost never have to create new tickets. If you have 10 in your pool, and you are mostly emailing co-workers and friends, you never run out of tickets, and everything acts just like it does today.
However, if you are a spammer, and you want to send 1,000,000 emails per day to people who don't really want to get them, and are never going to reply to your email address (which, to make things worse, probably changes with every batch you send out, to keep yourself anonymous), it's too "expensive" to stay in the spam business. To send 1M unsolicited emails could cost up to 1M tickets, which you may never get credit back for. To generate those would cost 5M minutes on the client machine, which would mean 9.5 years of number crunching, to send one day's worth of email. Clearly not feasible.
Let's say we cut the time per ticket from 5 minutes to 5 seconds. Now, it's almost unnoticeable for normail email usage. An extra 5 seconds to send a mail? Totally not a big deal unless you are mass mailing. But again, to send 1M mails per day, even 5 seconds per mail costs 57.8 *days* worth of CPU crunching. Also completely not feasible.
Sounds like a great plan to me, once all the details I'm glossing over are worked out, but that's what research is for!
The only issue here, that Timothy hit on in a follow-up comment, is that there'd have to be mechanisms for valid mass-email to be sent out. Banks sending statements, Organizations sending email-newsletters, etc. Perhaps there'd be a way to give them a pool with a million tickets, and rely on whatever mechanism was used by the receiver to credit them back after the newsletter was read/received..something like that.
(Ah, the devil is in the details...)
Tricky project to get right, but it could definitely be a win/win.