micropayment email

I think the only way to eliminate spam is to eliminate the economic condition that encourages it. Currently the cost of sending spam to milliions of email addresses is negligilble. However, we don't want to get ISPs or the government to impose fees on email; instead we want senders to pay recipients.

In the past, the cost of electronic transactions has been too high to do this sort of thing (on the order of $.50 to $1.00 per transaction), but there's a lot of research on micropayment systems.

On the receiving side, you would establish a fee that you charge for unsolicited email, and a list of addresses from which you're willing to accept email at no charge (or at a reduced charge). For instance, you would put the mailing lists you voluntarily subscribe to onto your "free" list, since they're not likely to be willing to pay you. Also, if you receive unsolicited email that you like, you could choose to refund all or part of the charge.

On the sending side, you would configure your software with a default maximum that you're willing to pay to send a piece of email, and the software would notify you if that proved insufficient.

Even a very small fee, less than one cent, would probably deter the vast majority of spam.

Of course, for this to work, it needs to be widely deployed, so it must be developed as an internet standard. What can be done to provide incentive to the leading email software providers to support such a system?

Since someone has to operate the micropayment system, and will need to skim a fraction to cover operating costs and make some profit, it would be good for the system to support multiple competing micropayment systems. Should the sender and receiver negotiate a mutually acceptable micropayment system? That probably would have too much overhead. Maybe it's sufficient for the receiver to specify a single micropayment system, and that system would take a cut of the receiver's "advertised" rate. Then the receiver is motivated to use the micropayment system that takes the lowest cut.

What if the micropayment system is down? Perhaps the receiver should specify multiple acceptable systems.

I'm sure that there are lots of other details that need to be worked out, but a low-overhead micropayment system is obviously the one vital part that isn't here yet.