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.)
This is an anti-spam tool that doesn't need to be paid in cash. This also presents /. with an interesting juggling act: we hate Microsoft, but we also hate spam.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
Except for messing up mailing lists, a neat way to limit spam would be to require the mail sender to factor a large number provided by the SMTP host. It wouldn't need to take too long - only 3 or so seconds on a decent computer, but it would really slow down spammers. If you need to send out an email to 20 hosts, it would take a minute, which isn't that bad. But if you were trying to spam 100000 addresses, that would require a good amount of time to crunch... Of course, the number to factor would need to be a good random number.
No, I don't trust in god. He'll have to pay up front, like everybody else.
Here is an idea, it is borrowed from the way ISP's pay for bandwith.
Why not make networks pay for the e-mail that originates there? Subtract the e-mail that arrives. For most companies/networks - that will be just about an break even proposition. For the ones who allow spammers - well... that is going to get expensive pretty quickly. Sooo... they will either boot the spammers off, or get them to pay it. Either way, we win!
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.
I'll tell you why this would never work - or actually maybe why it *will*. Because big business can afford a penny per message and little guys can not.
For instance, I run a popular auction site and on your average day my system sends out about 1,500 auction-won notices, 1,500 auction closed notices, 2,000 auction closed without a winner notices, 200 account related notices (new accout, lost password, etc) and about 500 misc emails for other various reasons.
This comes out to almost 6,000 messages per day from my system (which is 100% free by the way). This doesn't even count personal correspondance.
Now there are a few questions. First, I run my own mail server for the auction site. Do I pay myself $60/day to send email? Or do I pay my ISP even though it isn't their server? Or do I pay microsoft for the right to send email from myself through my own server to my own users who are expecting to get these messages?