Paying Artists and Writers Online

new design for grassroots e-commerce

AntiSpam: Recipient Sets a Price

What RepliCounts brings to the table is payment codes (worth actual money), which can be sent openly through ordinary, insecure email, without any encryption.

Analysis

The spam deluge is not exactly what people often imagine. Spammers seldom get email addresses that are only used privately, and with reasonable care.

Spam happens when we want to get email from strangers (including businesses we deal with but do not know well). We want to hear from people we don't know, for valid reasons -- and we want them use judgment, courtesy, and common sense. But the spam economic model, which lets someone send ads to hundreds of thousands of people almost free, creates strong incentives to send massively and indiscriminately, with no courtesy or sense at all. And the huge multiplier lets each spammer do considerable damage.

This analysis highlights an additional, less visible cost of spam -- making legitimate communication with strangers more difficult, which tends to suppress both business and cultural development.

In 2006 AOL floated a terrible idea to charge senders for email delivered to its users; after furious opposition the proposal sank in the same year. Free AOL email would have continued as well, but it was widely expected to become largely unusable, since AOL would have had a permanent incentive to deliver poor service on the free system, especially poor spam control, to force more users into the paid version. The result would have greased the skids for corporations that could pay or negotiate costs for mass emailing, but priced out low-budget groups like the cancer organization that sent emails to thousands of people who had asked for them. This flop suppressed much of the interest in charging for email.

Proposal: Let Individuals Set Any Price to Receive Email at Special Addresses (and Keep the Money) -- for Antispam and Other Uses

The idea of a price to control spam could make sense if done right. Two suggestions:

With such services available, people could better manage spam by gradually migrating their risky email uses to their new address, so that they could be more careful about giving out their private (ordinary) email addresses. A flexible whitelisting system would let users allow colleagues or businesses to send email free. One option for whitelisting would be to give a unique code to each free user (which could include a group, on a list serve for example). In case of abuse, the recipient could turn off that particular code at any time, without affecting any other senders. See more on this below.

Possible Uses of This Premium Email:

PayPal, etc. already work well for most uses of high and medium prices, so the low-cost uses may be especially important. We expect that payment to receive email is not widely used already due to the difficulty of managing large numbers of small payments.

How RepliCounts (or Other Reproducing Accounts) Could Help

Imagine that you could instruct a payment code to require your approval for any payment over, say, 10 cents, and then simply put that code into your email signature (or anywhere else in the email), letting it go out in paid and unpaid correspondence alike. The payment for email that requires it will automatically goes into an account of the recipient, minus a fee for the service that manages the codes.

For security, a code you set up for personal use might also be instructed to require your approval for any payment that would send the total from that account to over $1 per day. These and other limits could be made completely irrevocable; that particular code on that server could never pay more without your approval -- and the phone number or whatever where the account contacts you can be set to never be changed as well. In addition, you might put only $5 in the account, and set the account to never receive any more money. Then no one can change these restrictions, even with complete owner's access to your account. These restrictions would apply to any future owner of that account name after you had closed the account -- except that there will never be a future owner, since the server will never assign that account name again. There's no shortage of names; a 12-digit code gives more than a trillion names, even if the code name can only include digits.

Suppose you lose your phone and change the number; then due to the irrevocable restrictions, the account cannot be updated to contact you for approval or anything else. But you (or anyone else who has the account name) could kill that account, instantly closing it and returning any remaining money to you, at a separate RepliCount, or other secret (and irrevocable) destination you had set up in advance. Someone who stole the account name could kill the account as well -- but would get no benefit, since the money would still return to you. Closing the account could be done at its dashboard. Alternatively it could be done by telephone to a number maintained at the server, using a secret one-time-only kill code, which would not need any encryptions since it would be worthless seconds after it was sent (and even in that interval, it could only be used to do what you wanted to do anyway). This kill call could be programmed into a mobile phone; accidental use could cause inconvenience, but no financial loss.

In addition, the account (the code) could have an irrevocable lifetime, whatever you want to set -- say one year. If you lose all access to the account, or just forget it and don't do anything, whatever money was left from the $5 it started with would come back to you automatically at that time, possibly with interest.

You can have any number of such accounts (codes) created whenever you want, at negligible expense or inconvenience -- by having one breeding account that you keep, to new produce "children" accounts whenever necessary. At the creation of the new accounts, you can change any of their default settings (including those that will be irrevocable once the account has been born) -- or change the defaults themselves, stamping the new settings irrevocably into future accounts in this series. You can pay for the $5 or whatever starting value in each emailing account from a larger, more flexible RepliCount that you own, or by credit or debit card, PayPal, mailing a paper check to the organization that provides your RepliCounts services, or using some other means of payment. Companies that provide RepliCounts will likely make a point of learning how to accept payment in many different forms, including foreign exchange, virtual currencies, and some more traditional alternative currencies as well.

There are many other possible controls that will make it hard for criminals to harvest and use masses of these small accounts (such as $5 or less) used to receive your own premium emails. First, you can set up these accounts to only pay certain destination RepliCounts, and these destinations could be secret; therefore the accounts harvested from emails could only be useful to spammers trying to send email to recipients who require such payment, since there is no other way to get any money or other value out of the account. In addition, the accounts could collect the email headers, allowing email to be traced. And since money will have been stolen in order to send this spam, there is no legal doubt that a crime has been committed.

There could be other secret security restrictions as well. For example, an account might be able to pay for up to 100 emails -- but only as a batch within five minutes, say, of when the first email went out -- after which the account closes itself forever, and automatically returns any remaining money to its owner, in whatever way the owner requested.

Note the role of account reproduction. Each new account can be "born" with hundreds or even thousands of services and settings, all set up and ready to go -- including the security services we noted above. Yet each account owner can change any services as he or she wants (except the irrevocable ones), and these changes will be inherited. Any number of different accounts can easily be created at any time; any account can self-destruct when and if programmed to, or be killed easily by the owner. Owners can live with irrevocable settings because they can easily kill the account and start over with a new one. Criminals with stolen owners' access can kill the account, too, but will not benefit, since any money will return to the owner at a secret, irrevocable destination.

Whitelisting Email Addresses You Give to a Business

Suppose a company you do need to business with requires an email address -- and you cannot be sure they will not sell it to third parties, or otherwise handle it improperly. Assume this company will not cooperate by putting a whitelisting code you provide into their email signature, let alone paying 5 cents to reach you.

In this case, the forwarding server that receives your email could give you as many unique, whitelisted (free) email addresses as you want, by adding perhaps a 6-digit random code number to the email address you set up. So at any time, you could have it give you 10 or any number of guaranteed unique email addresses; you can keep a few handy on your computer desktop, and even a few in your wallet, maybe on gummed labels, and optionally record who gets each one. For example, if I set up a premium email address jsj@nospam2u.com at an anti-spam email forwarding service, these coded addresses would look like jsj856237@nospam2u.com, jsj973301@nospam2u.com, etc.

To the business that demands your email address, this is just an ordinary address, and it's good for unlimited free emails (forever, or until you cancel it). Then in case you start getting spam, you can cancel that address any time and know who misused it. Six digits gives a million different combinations; if you have given out 100 to various businesses, then a spammer's chance of guessing any of the 100 valid 6-digit numbers is less than 1 in 10,000 per guess -- and if spammers ever do get one you can just cancel it, and give a new email address to the authorized user if appropriate.

Comparison with Other Spam Control

The many different methods of spam control have their own pros and cons. Two that have uses closest to our proposal are temporary email addresses, and challenge-response systems (which email the sender, who needs answers a question, or sometimes just reply to the email, to get it delivered and get on the recipient's whitelist).

Our proposal has the advantage of paying the recipient any amount requested to receive an email. Its flexibility is limited only by the imagination used to program the server that offers RepliCounts (or similar reproducing accounts). For example, the system could let a consultant charge a small amount, such as $1, to receive an email and decide to reject the job, or $50 to answer the question or otherwise do the work -- in either case, by the advertised deadline, such as 48 hours (or maybe just one business hour, in the case of a consulting group that always has an expert on duty and others on call); imagine the value to business projects of being able to get immediate, expert answers to almost any question, from a choice of thousands of experts. Alternatively, a code given to a list serve or other group might allow 50 or whatever emails to be sent free, by anyone; if someone in the group is careless and spammers get the code (and go to the trouble of using it, which seems very unlikely), the recipient can cancel it; otherwise, when only 10 (say) free emails are left, the recipient will get a reminder to consider adding more, postponing the need for a new code until someone does get careless with the existing one. Note that in this second case, no money changes hands, so the email sender who uses the code does not need to have an account anywhere.

When money is charged, the sender will need a way to pay it. Payment could be through a usual shopping card accepting credit cards, PayPal, etc., requiring no special account; this could work well for larger payments, such as $50 for a consultant to answer a question. For small amounts (like 5 cents to deter spam), anyone could pay the 5 cents with PayPal, etc. in an emergency; but most would choose to pay more, such as $5, to send their mail and also receive a code with $4.95 in it. This code could be used for sending future emails -- or to make any other payment where a RepliCount is accepted, to any RepliCount server within the same network of trust as the email server.

Note that these email addresses that require codes (whether to pay for sending premium email, or for free authorization to bypass the payment) will all be at a few domains that specialize in coded-email services. Senders will seldom be surprised -- especially since the recipients who give out these addresses will naturally explain to potential senders that a code somewhere in the email is required. And of course senders who do not know, or otherwise leave out the code, will get an email explaining the bounce, and what they can do about it.

Page updated 2009-09-30

Creative Commons License
This RepliCounts software design by John S. James is licensed under a Creative Commons Attribution 3.0 United States License.