This article was written in September 2002, but I update it with corrections, small remarks and new pointers when I have the opportunity. I notably added an appendix on USENET newsgroups in April 2003. If you send me pointers to free software or articles, I'll include them. This article is available under the bugroff license.

Abstract: I propose a plan to eliminate the bulk of unsolicited commercial messages from electronic mail services by shifting the cost of spam back to bulk emailers. The plan is based upon the principle of senders of unsolicited messages demonstrating their good will by paying some kind of postage: either a small amount of caution money paid electronically, or a sacrifice of a few seconds of human time at answering a simple question. The discussion includes many technical issues, but considers them from the general praxeological point of view of how postage could or couldn't be actually feasible and desirable. Implementers sought.

UCE (Unsolicited Commercial Email), also known as Spam, is a notable annoyance for all users of email. A single UCE message usually only wastes but a small bit of time and attention from the recipient. Occasionally, a spam message will fool the recipient by attracting the recipient's sustained attention and will maybe even succeed in defrauding him. Sometimes, an actual important message may be lost in the bulk of spam, never to be read by its recipient. All in all, though the expected cost of any single spam message is low, the sheer volume of spam being received combines up into a tremendous waste of resources for all email users, system administrators, etc.

Many different methods have been attempted to fight spam, but their success so far has always been limited, for deep structural reasons: indeed they are all after-the-fact reactive measures that require a lot of involvement from those who refuse spam, for limited inconvenience to the spammers if at all. First, there are purely technical approaches:

1. Content-based filtering by the recipient. This method keeps all the burden on individual recipients, and is just a way to reduce the cost of individual spam by investing part of the expected cost reduction in a semi-automatic spam-detection systems. Spam senders are unaffected, and automation is never completely reliable ^[1], thus still implying a irreducible manual filtering cost on the email user. So far, this method is only helpful to the most proficient users, who can handle the required automation.^[2]
2. Point-based filtering by the recipient. The recipient refuses messages from detected spammers, and from open relays that allow spammers to hide their identity. Unhappily, this method results in a hide-and-seek game where the spammers always have the advantage, and where system administrators waste their time going after spammers.
3. Use of a shared filter database by the recipient. This method allows users to pool resources into filtering spam, either in a content-based ^[3] or point-based way ^[4]; but the cost of administrating such databases, mining them, using them, integrating them into user's environment, is still born by the victims, and so far these cost have made it a rather little used method.

• Trying to deny network access to spammers. This method is but the physical extension of point-based filtering: have the detected spammers' Internet Access Providers cut their access. It is slightly more efficient than point-based filtering, but also costs more, since it requires the help of IAPs (and a proper clause in the access contract); it also results but in a hide-and-seek game whereby spammers activate a new access each time a previous access was cancelled.
• Prosecution of spammers. Because there is no way of contacting all the actual victims of a given spammer (and trying to contact them would create inconvenience worse than the spam itself generated), the legitimity of prosecution on damages provably inflicted is limited. The cost and uncertainty of the legal system, and the refuge of spammers out of the reach of courts, also make this method rather inefficient.
• Legal regulation of UCE. This method of fighting spam is the most disastrous. It wastes a lot of resources in lobbying, public marketing. It legalizes some forms of spam, thereby preventing prosecution. It generates or legitimates new government spendings and new restrictions on public liberties, new arbitrary powers to irresponsible administrations, and only results in spammers operating from countries where they are out of reach of these administrations, while the administration remains to harass lawful users.

In contrast, I hereby propose a proactive method to eliminate spam; this method is neither purely technical, nor purely socio-legal, though it has technical and social implications; it is an praxeological method, based on economics. Recipients will demand all senders of unsolicited email ^[7] to pay the equivalent of a stamp before to actually accept email for reading. Senders of unsolicited email may pay postage either by leaving caution money using some monetary payment method, or by spending a bit of time on a web page authenticating themselves as humans. Acceptance of this small sacrifice demonstrates their good faith, so that a normal conversation may ensue. Such a scheme allows email users to shift the cost of spam back to the bulk emailers, thereby discouraging their very practice; however, it also raises the cost of legitimate use of email, in a way that must be kept below the cost of spam, for the system to be effective.

The challenge of such a plan, is thus that the annoyance of paying postage should be noticeably less than the annoyance incurred by receiving spam. In particular, a major constraint on any plan to enhance a legacy system is that it should provide a seamless upgrade path that it should allow for interoperation with users of these legacy systems while bringing immediate benefits to early adopters.

I will thus discuss the feasability of this plan from a praxeological point of view: the ultimate question will always be whether email postage can or cannot be actually adopted, considering the costs and benefits of the techniques involved to the individuals who may choose to adopt it or not.

The principle of stamping email is conceptually quite simple: when sending email to someone else, particularly a new correspondant, the sender attaches a stamp to his message, a token that is costly to the sender, and demonstrates his good faith. Note that the recipient's acceptance of this token doesn't bind him to to anything but to process the email message. In processing said message, the recipient is free to take any appropriate action, including trashing the email immediately without further notice, depending on his own criteria, among which he might or might not consider the amount of postage attached. When a message is received that isn't properly stamped, is stamped with an insufficient amount, (according to the recipient's own criteria, with some sensible defaults), or is stamped using a method not accepted by the recipient and his software, the default behaviour of the system will be to return a standard automated administrative reply (unstamped). This reply will enjoin the original sender to install stamping software, to retry with a higher postage, and/or to pay by a different method, pointing him to proper webpages whence to do any of these. Thus, people sending in good faith messages not properly stamped have a second chance, while messages without a proper sender are screened off.

The most obvious, though not forcibly most promiseful, postage payment method would be some monetary payment ^[8]. The stamp would either be some cheque redeemable as money by the recipient's stamp-processing software, or it would be a receipt for some money already paid to the recipient's previously identified postage account. In a normal conversation, postage will be returned in the first reply, and no further payment will be necessary as each correspondant will be in each other's ``whitelist´´ of people whose email is considered as solicited. Also, in case a message remains too long without a reply and has been marked as not being spam, the default procedure would be to automatically return the postage <sup>[9]</sup>. Thus, monetary postage serves the purpose of caution money paid by senders of unsolicited mail to prove their good faith. In a standard installation, standard amounts will be required for the message to be accepted in various categories of ``urgency´´ (with something like $.40 for normal first-class email, and a default minimum acceptation threshold of say $.10 for low-urgency third-class email). Each user is of course free to setup his own fee structure, and take his own arbitrary decisions depending on the postage paid. People in high demand may require a much higher caution to people wishing to interview them by email (of course, if you don't trust them to return the caution money, you won't contact them, and so shouldn't you). In marginal cases, such a monetary postage processing system may even be used as a way to sell services that are paid for with email stamps; of course, administrative messages signalling that an email has been rejected by lack of postage ought to specify it clearly if they are asking for a payment rather than for a caution. Currently, the biggest obstacle to such postage payment method is the security problems related to any kind of ecash (see section Problems With Monetary Payment below).

Another method of postage payment that has been suggested in the past is postage payment in terms of computing resources: the sender's software would make some kind of computationally expensive computation the result of which is relatively easy for the recipient to check ^[10]. This has notably been implemented by the CAMRAM project, based on the hashcash method of payment through computational resources. However, the wide difference between computing powers of internet-connected machines means that this would either phase older machines out of email (although the burden of being up-to-date could be shifted on these machine's email relay servers) and put considerable burden on mailing-list users or owners, or become ever more inefficient against spammers as machines become faster and cheaper (some spammers may even specialize in building farms of computers, pirated or not, to answer challenges). All in all, it is not clear how to usefully calibrate the amount of computational postage in presence of both ever faster computers and a vast farm of legacy computers. This method could nevertheless be used, at least up to point, in complement with other methods, so as to prevent simple DoS attacks exploiting the computational cost of stamp checking to recipients. The biggest obstacle to spreading this software is that it has no way to market itself: it brings little benefits to early adopters who are still forced to use reactive filtering techniques until enough people adopt the system so that they can just drop unsolicited email that isn't properly stamped.

Now, the postage payment method that seems most promiseful to me is payment in human time. As told by an automated reply from the recipient's software, the sender would connect to a webpage and authenticate oneself as a human spending time by answering a simple ``Turing test´´: a challenge known to be currently impossible for a computer to fulfill (like, recognizing a simple visual or audio pattern) <sup>[11]</sup>. A plugin in the senders' mail system could also proactively fetch the challenges for messages being sent, and present them in a way that saves time with respect to waiting for an automated reply and going to a web page. Human time being the ultimate scarce resource, this method will always be costly to the sender, even for a small time. Unlike monetary payment, human time postage is not beneficial to the recipient, and cannot be sent back; on the other hand, this non-monetary payment eschews all the intrinsic security problems of monetary payment systems. Most importantly, this postage payment method doesn't require any new software to be installed by senders (though software can help make things smoother), since it can be done with a web browser. This method is thus perfectly suited for use during the transition period from unstamped email to stamped email, and maybe even afterwards. With such a method, however, the high cost of ``stamping´´ means that it should be limited to the strict necessary: there ought to be a seamless whitelist management system so that you only pay once when initiating conversation, and afterwards you're identified by your party as a human being. Actually, a variant of payment in time, that integrates perfectly with whitelist management, and brings privacy as a side benefits, is to require correspondants to use GnuPG and to spend time with you exchanging (or at least confirming) OpenPGP public keys, either face to face or by phone. A Turing-test webpage could also have a form to send your key, that would be automatically filled by software proactively using postage payment — but of course, the authenticity of such keys shouldn't be trusted until it is confirmed by some independent means. All in all, payment in time seems most promiseful to me, but is currently not automated. To become useful and maybe successful, it requires the definition of a standard protocol and its implementation into some robust, usable, learnable and featureful software that integrates well with legacy software.

Of course, in a polite email exchange, the recipient will return the same postage to the original sender together with his reply. In a friendly email exchange, both participants will then add each other to a ``whitelist´´ of people whose mail will be accepted without requiring or banking stamps. In the case of monetary stamping, polite people will nevertheless continue stamping all their messages, as a mutual sign of good will and/or friendship, depending on the postage being banked or not. Email software ought to recognize and help implement such stamping patterns. Thus, with whitelist management and proper procedures, postage payment — either in money, human time or computer time — is only required once, when initiating communication with an unsolicited message; with other exchanges, monetary postage due evens out, and/or further postage is not due anymore. All in all, the total credit you ever need to spend (either in money or else) will be determined by the number of unsollicited mail you send that the recipient deserves not worthy of reply — which is exactly the point of postage as a spam deterrence technique. The fact that some impolite people won't return monetary postage, or will volontary take steps in their software to reply to you without putting you in their whitelist, is also a feature: it's a great way to detect people to put in your blacklist. If your time is worth anything, the time you save by not dealing with such nogoodniks is well worth the postage lost in your last email to them. To conclude, email postage constitutes not only a way to deter spammers, but also a way to build and maintain interpersonal relations between email correspondants.

The first technical part of our plan to stamp email will be to standardize an Email Postage Payment Protocol (EPPP), so that email software can cooperate in processing stamps. This protocol should be an extension of existing protocols (RFC 2822), so as to allow for interoperation with legacy unstamped email.

Technically, one advantageous way of achieving an EPPP would be to modify the SMTP protocol or QMTP protocol so as to take stamping into account at the Mail Transport Layer; this would allow for a versatile stamp negociation protocol, that could include fine-grained real-time negociation of both postage due and payment method. However, such an option requires all participants to support the protocol extension down to a very low level of operation; it cannot provide seamless interoperation with legacy infrastructure, and thus, due to network effects, can never take off by itself. However, once a EPPP has been widely adopted, it could provide a good opportunity to scrap SMTP and replace it with a more sensible protocol for Mail Transport Agents (MTAs).

For stamp payment, we must thus rely on negociation to happen at the application level — inside Mail User Agents (MUAs). Since the whole point of postage is to not be transparent to the user, some MUA integration is necessary, in any case: monetary payment requires fine user control so as to remain safe, human time payment obviously involves user action, and so does whitelist/blacklist management. Now, we'll see that MUA integration already allows to bring most of the advantages of spam control, even without support at the MTA level (indeed, spam may still cause encumbrance of network and waste of computer ressources, but hopefully, this encumbrance will decrease together with the incentive to send spam).

Thus, stamps will be attached with emails in the envelope and headers ^[12]. Care should be taken to pick an encoding convention that will be respected sufficiently by existing mail processing software (MTAs and MUAs). The stamp will be identified as such in conformance with the EPPP standard, will specify the postage payment method being used (and variant if any), and contain binary data specific to the payment method being used. So as to prevent stamp reuse, the stamp will be clearly associated to the message, using on a message identification number obtained as the checksum of the concatenation of recipient's address, the message sending date, the message ID, and the checksum of the message contents ^[13]. An expiration date for checking the stamp will ensure that spam cannot be paid for once and sent many times at long time intervals, while the stamp checking software won't have to keep more than a week or two worth of stamp data.

In the case of monetary payment, the method-specific data may be a certified cheque to be drawn from the sender's account by the recipient, or a receipt referring to a payment already done to the recipient's postage account. The recipient's postage software will then bank the cheque or check the receipt before to accept the email for actual processing. To reduce the number of unnecessary transactions, the recipient may also refrain from banking the cheque before its expiration date, or return the stamp money immediately (hopefully, the monetary payment system will make such null transactions very cheap or free). In the case of payment in human or computer time, the data will be an identifying cookie returned by the certification website where the sender spent time; this cookie was given depending on the message identification number, and is easily checkable by the recipient even without access to the website where payment is done (e.g. the message identification number, optionally combined by cryptographic means with a secret number known to the recipient only). In case the message didn't have proper postage, the automatic administrative reply will point to URLs where to pay postage for the message without having to resend; or the sender's software may send a subsequent administrative email that contains postage for the previous message.

Given proper software to handle automatic administrative mail and/or handle postage at the mail transport layer, the original sender does not even need to care about postage: if any postage is due, the recipient's mail system will initiate a stamp transaction, and the sender's system will react accordingly. Thus, recipients not using stamped email will not be annoyed with attachments they do not recognize, while everything will go seamlessly for recipients using EPPP.

We saw that keeping the inconvenience of email postage relatively low greatly depends on having good whitelisting software. Whitelisting in turns depend on senders being properly authenticated.

Identifying the sender from his declared address is a first measure, that is immediately compatible with sender using legacy software. However, faking the declared sender could be easily done by spammers if they have to (and some already do): they will guess who your correspondants are from mailing-list archives, or from your email address itself. They will otherwise send multiple versions of messages with a variety of fake senders.

With a sophisticated MUA, the recipient's software may also track other headers from whitelisted individuals, and automatically require confirmation (payment in time) from the sender in case of suspect headers (with actual payment leading to not considering said headers suspect anymore).

More robust authentication methods require senders to upgrade their software. A simple method is to include in the headers a cookie given by the recipient during the first postage payment.

Finally, a more intrustive, but much more robust method is to use the OpenPGP protocol (and we saw that requesting OpenPGP key confirmation by phone or else could constitute the required payment in human time).

Actually, monetary postage payment also requires robust identification of the person to which to send money. It could be an interesting idea to add an optional field for email stamp payment coordinates to OpenPGP public keys, so as to declare in one's public key how to pay for postage. With a similar extension, stamping could also be attached as unencrypted fields inside the OpenPGP metadata.

The usual issues with Public Key Infrastructures apply as to exchanging keys and building trust around them. However, as far as identifying where to send payment for stamps of messages sent to a given address, it suffices to send an unstamped message, and process the automatic reply returned by the recipient's stamp processing system. Such method is susceptible of man-in-the-middle attack, where someone intercepting and tampering with both messages and key exchanges could try to steal postage; however, in a conversation between polite people returning postage in replies, this theft wouldn't go unnoticed, while being limited to postage paid, and leaving traces to follow so as to catch the thief (at the very least, the account number used to receive stamp payments).

As long as the postage protocol is not fully integrated at the message transport level, messages will have to be exchanged at the application level. Hence, our postage system will imply automated administrative messages to be sent, and handled either automatically (if the receiving party uses proper software) or else manually by senders not yet using the postage system. So that these automated message will not create inconvenience, or worse, reply endlessly to each other into an uncontrolable havoc, there must be some clearly-defined and standardized control protocol.

Indeed, a general problem with any automatic mail engines is the way it interacts other automatic mail engines. Legitimate such engines particularly include mailing-list relay robots, postage handling robots, robots to automatic manage contact list, robots to send away messages, robots to return requested acknowledgment receipts, robots that handle virus and suspect email, robots that enforce some policy on the format or contents of email, robots that manage workflow inside a company, etc. Illegitimate mail robots include all those spambots that we hate, and more (I'm not going to make suggestions).

Thus, legitimate automatic reply engines should take extreme steps to never send unsolicited email, and to drop unsolicited mail from other robots. Mailing-list relay robots are a particularly sensitive target, since they multiply the number of persons (and potentially robots) involved: when a robot message is sent to a mailing-list, it may create endless an explosion of robots replying ever more automatic messages to each other, with all the human members of the list being victims of this deluge. Now, to avoid sending any administrative reply to a mailing-list address, means being able to detect which messages come from a mailing-list. Morever, even this detection is not always enough, since bogus or malignant messages may contain a mailing-list address (or the address of another robot) as their return address. So mailing-list robots and other robots must be prepared to deal with bogus administrative mail that is send to them, and take appropriate measures or lack of measure: to drop the bogus mail, to log the event, but not to reply to it, not to relay it to subscribers, etc. ^[14]

Of course, for interoperation with legacy software, there needs be a census of existing robot software (particularly mailing-list software and other kinds of robots listed above) to determine a way to detect robot posts. But the correct technical solution to all these problems would be that a standard be defined for robot mail control, and that new robot software follow the standard, while old ones be upgraded or deprecated. This problem deserves a RFC of its own. independently from all our discussion about either spam or stamping. If such RFC it doesn't exist yet, it is cruelly absent ^[15]. There should be a standard way whereby mail sent by legitimate robots may be clearly identified as such by users and robots alike. Thus, other robots can properly ignore and drop automatic administrative messages that they are not explicitly meant to process, instead of blindly relaying them or replying to them. Of course, the definition of such RFC is out of the bounds of this document; but it will have to be done as a matter of course if the plan hereby proposed is to be implemented.

I have mentioned mailing-lists while discussing automatic email processors in general; but they also deserve special consideration from the point of view of postage payment. Indeed, since mailing-lists multiply the costs and benefits of email by the number of people subscribed to them, so is the question of postage multiplied. We may consider separately two issues: on the one hand, there may or may not be some postage payment between a poster and the mailing-list robot; on the other hand, there may or may not be some postage payment between the mailing-list robot and the subscribers. In each case, there may or may not be filtering and rejection of email, based on postage paid or not paid.

Firstly, let us examine the relationship between a poster and the mailing-list robot, as controlled by its owners and moderators. The owners and moderators of the list, being legitimately in control of it, may impose to posters their arbitrary conditions before to accept messages for relaying to members of the list. Among these conditions, there may be the payment some kind of postage payment, in some kind money, computer time, human time or whatever. Spam may be deterred by requiring such a postage payment from people subscribing to the list, from people posting to the list, and particularly from people posting without being subscribed. In the case of postage as monetary payment of caution money, the list could send the money back after the message or subscription was positively moderated (either accepted or rejected, but not marked down as ``spam´´), or after it wasn't negatively retromoderated (marked down as ``spam´´) for a certain test period. Also note that since a list robot never initiates a conversation with a poster, it can start with an empty postage account, and the account never needs to be credited by the owner. Some or all members subscribed to the list may or may not be exempt from postage; preferrably not unless they are also properly authenticated. As for people not subscribed to the list, they should probably have to pay postage everytime — that is, if their messages are to be accepted at all. Finally, in some cases, some lists may choose to relay even some messages that haven't been properly stamped, although marking them as such, for individual subscriber to choose to filter or not.

Now, let us consider the relationship between the list robot and individual list members. List robots typically won't pay any postage to subscribers when relaying messages. Indeed, either the subscribers do solicit being sent messages for the robot, and the robot is on their whitelist, or they don't, and the robot is on their blacklist (or soon will be if it doesn't pay postage, and maybe even if it does). That said, when a subcriber wants to filter the list out, he probably also wants to unsubscribe from it, too. This brings about the slight technical problem with synchronizing the state of the MUA's whitelist and blacklist with the actual subscription status of the user according to the robot; this problem once again will be better solved if and when a RFC standardizes a protocol to manage mailing-list subscription and unsubscription from each user's MUA. But there again, the fact that mailing-list robots would pay postage in their subscription confirmation message (by returning postage from the user, in case of monetary payment) may be a good trigger for the MUA to propose the mailing-list for addition in the user's whitelist rather than in the user's blacklist. In any case, in normal mailing-lists, neither senders nor the list robot will have to pay individual postage to every single list subscriber. ^[16]

Note that, of course, individual list members may do further filtering, beside the postage status of messages — after all, he also is in legitimate control of his own mailbox. Not only may he add the whole mailing-list to his whitelist or blacklist, he may also filter each message from the list according to its poster, its contents, etc. But this is independent from postage; for postage can only warrant proper solicitation, not interesting conversation.

There are several additional technical issues that postage software ought to solve if postage is to become widespread.

An immediate problem is to handle newbies who will face the system for the first time: this would be done through an administrative message notifying that they have to click on some page so as to be on the whitelist of some person they just contacted. Such an administrative message must be written in such a way that newbies will understand it, and will actually click on the right place to be added on the whitelist. This problem is all the more tricky as you have to guess which language (and which level of language) to use in the administrative message from the initial unsolicited message they sent to you. This can be done by analyzing the contents of the message sent, by considering the usual language of the person's correspondant, and by considering the geographical location of the machine from where the message was sent. It is technically feasible, but is not a trivial task. As a way to simplify things, however, since the recipient only speaks a certain number of languages, any correspondant would have to speak at least one of these languages for an email exchange to be useful — so the user could select those languages when configuring his software. In any case, there is a wealth of details like this that will have to be overcome for a postage system to be fully successful.

Then, there is a problem of education. To solve the problems that arise with postage payment, with monetary payment, with whitelist management, with cryptography and security, whatever software we propose must provide easily available contextual help to making the right decision whenever there is a decision to be taken. This means that a tutorial on how to use passwords, when to type them, how to manage trust, etc., must be made available, in a way specially cross-referenced so that the right section appears when asking for help from a given menu in user interface. The surest way to enhance the world we live in is to educate people. The problem of spam is no exception in this case.

Another issue is that users often change their computer environment: they move from machine to machine, they use machines from friends, from the office, from a remote hotel, they upgrade their hardware and software, they try different software, etc. If the postage system means any excessive burden for users as they modify their computer environment, it will encounter considerable resistance, and will not be adopted. Thus, so as not to inconvenience users and their correspondants, there better be some way for the whitelist information et al. to persist across these constant changes in hardware and software. This calls for standardization of a protocol to transport user profile information across machines, in a safe way, that allows for merging information gathered at different locations. The discussion of such a protocol is out of the purpose of this article, but the development of such a protocol and the interoperation of postage software with profile management software may be instrumental in gathering support for the postage payment system. Even without a standard, migration of existing profile information, analysis of existing addressbooks and mail archives so as to reconstitute whitelists, is important to bring users as seamless an email experience as possible.

More generally, it is an important to implement decent tools, with a usable user interface, that integrate well in the environment that users like, and are not incompatible with features that users demand. Even with a great protocol and robust secure working tools, postage won't be accepted unless it is implemented in a way that suits users.

The biggest problem with any computerized payment system is that the user needs control over what he pays, and wants no one else, people or program, to be able to ever spend any money from any of the user's account without the user's explicit consent.

Whenever there is a big amount of money gathered at one place, thieves and robbers will try to take that money away. Whether the risks that they succeed be born by the user, or whether measures be taken to reduce the risks, there is an intrinsic, irreducible cost, associated to the mere fact of using money. Now, if a system of monetary payment ever becomes widespread, being present on the computers of a lot of people, all using identical or similar software, it will be just like a big bank waiting to be robbed. And considering the security found in the average computer, this is a considerable risk that shouldn't be neglected.

In an ideal world, computers would come equipped with some robust and secure operating system, such as EROS, with a fine-grained capability model and system-wide secure session management to protect sensitive data, and a system-enforced WYSIWYS (What You See Is What You Sign) interface for online transactions, including postage payment. In absence of such a system, a pseudo-secure system must be emulated on top of such intrinsically unsafe operating systems such as Unix or Windows. Such emulation may use cryptography to prevent normal programs from unduly accessing secret information, but it won't be safe against a malicious program taking over or faking its user interface so as to steal passwords from unsuspecting users.

As a measure to mitigate risks and to make the system less brittle in case of a break-in, users may use a small postage account containing but a limited amount of money, so that in the worst case, there isn't much that a thief can steal. Indeed, as we saw earlier, one only needs credit one's postage account of an amount proportional to the total number of unsolicited email one intends to ever send. If you ever have one hundred pending unsolicited email sent to new correspondants, with a $.25 stamp each time, that's a $25 grand total. As a comparison, one million spam letters sent at $.10 each would be $100,000 to pay in advance for the wannabe spammer. Of course, the payment system must make dealing with such small accounts an easy thing for such a measure to be worthwhile. Another feature of a payment system that will make life more difficult to malevolent people is to allow to track who receives money so as to catch any potential rogue after his act.

All in all, monetary stamping of email might or might not be feasible right now. It probably requires computer security to be considerably enhanced so as to become a valid option.

Note that even in absence of ecash, security is always an issue: whitelist, contact information, private email, etc., also ought to be protected against reading or tampering by malware. But the issue is less problematic than with monetary information, since there is less incentive for malicious behaviour in this respect.

As Clay Shirky clearly exposed in an article, The Case Against Micropayments, any kind of payment has an intrinsic transaction cost in terms of human time and attention that has to be devoted to considering whether to pay, and to actually engage in paying. Shirky concludes that micropayments (as in, payment of tiny amounts of money) are not worthwhile, because these oft neglected transaction cost make them inefficiently expensive as compared to the stated value of the services being bought. As far as postage is concerned, this implies that it is a bad idea to attach stamps of too small a value — which would also be a bad idea in that it wouldn't deter spam as much. It seems a much better idea that as a matter of standard, polite procedure, someone initiating conversation would have to pay some relatively high postage value, with the recipient returning postage and both participants including each other in a whitelist.

Now, transaction costs are not specific to monetary payment, and exist in the case of payment in time too, although they may arguably be higher when money is involved rather than ``mere´´ time, due to the risks with money being stolen without the user noticing (it's much harder to profitably steal one's time without one noticing). Such costs must thus be taken into account when evaluating the inconvenience of a postage system, even with the payment in time method. However, let us not forget that the existence of a cost to posting email is precisely what postage is all about to begin with. Certainly, an ideal system would have low overhead, and most of its cost would be reversible by the recipient back to the sender, but the main point of postage as a way to deter UCE is not that the recipient would receive money (though that'd be swell and would enable all kinds of services), but that the sender express his willingness to sacrifice something worthwhile, albeit small, the value of which is superior than that of a spam to a spammer.

On the other hand, transaction costs also exist in reactively filtering mail with content-based content analysis, instead of proactively filtering it with payment. Because one missed mail could potentially mean a great loss, you'll either take that risk (and maybe lose one day) by not checking what your filter refused, or you'll spend time going through the garbage looking for the hidden pearl. Thus, all in all, transaction costs might (or might not) be an argument in favor of email postage rather than against it; indeed, the whole idea of email postage is to reduce transaction cost for the recipient by increasing the transaction cost to the sender.

Another cost issue not to be neglected is the cost of installing new tools to handle the postage payment, of learning to use them. This cost is particularly important if these tools involve monetary payment systems, and even more so for large corporations. In any case, corporations also have to face the cost of spam, in terms of productivity lost for their email users and system administrators, so if one variant of our postage scheme is valuable in terms of costs/benefits, we can expect some corporations to eventually adopt it — selling integration of such systems in companies' IT centers can be a service sold to them. Hopefully, once proper software is developed, this installation cost will decrease, and eventually become marginally zero, as all email software comes preequipped with it.

In this article, I proposed some technical means to eliminate spam. Then comes the question of funding the software development, the marketing, etc., required for such means to appear and disseminate.

Of course, assuming our technical means are any good, word-of-mouth (or rather word-of-electron) marketing will provide us with a community of early adopters among the technically inclined people, including some people most important for spreading our plan: administrators of email services. And if our plan already allows some of them to be saved from being drowned into spam, it will already have been successful, even if it isn't spread further. But let us nevertheless discuss how to secure a widespread adoption of an email postage system among non-technicians.

Here are a few sources of potential revenues for the development and deployment of email postage system:

1. Sale of services to IT departments: email automation software is not just for fighting spam and viruses, it more generally can help smoothen and control the workflow of people within a company, to make the company more productive. If suitable standards exist for email postage, that have proven useful in avoiding email havoc, they will probably be adopted by companies as they modernize their software infrastructures.
2. Sale of ready-to-use software: as spam becomes ever more of a problem, and as advanced message programs bring ever more useful features, it may become possible to sell email software to end-users, either as shareware or as off-the-shelf boxes.
3. Integration with online payment systems: email postage may be just one of the many features used to otherwise promote some robust and flexible online payment system that would have solved the risks and costs tied with monetary payment as previously discussed. I believe that people who have invested in online payment systems should be interested in promoting email postage as a natural source of transactions for their systems, as well as as a testbed and showcase for the development of usable payment tools. ^[17]
4. Investment of deposits on postage account: if a lot of people have a postage account, each with a few dollars permanently sleeping in it, then whoever manages the postage accounts can make a living out of interests earned by investing the total amount.
5. Sale of marketing services: if the websites where users ``pay in human time´´ include some advertisement, this advertisement may be used as a small source of revenue to finance the development of postage software. At the same time, each such page constitutes advertisement for postage payers to acquire and use postage-aware software that will make their correspondance more seamless and spamless, thus providing automatic viral marketing for the postage system.

Only time will tell whether our plan can be successful at deterring spammers. There is definitely a technical challenge in implementing our method, and maybe some good business opportunities in spreading it. In any case, this plan doesn't depend on any legal measure, or global change in email exchange technology. It is something that can be done now, and it is just a SMOP ^[18]. Once the programming is done, anyone can unilaterally use such a system and enjoy a completely spam-free mailbox, without waiting for other people to switch. And that is maybe the single most important feature about email postage.

Broadcast media in general, and USENET newsgroups in particular, are by their very nature different averse to interpersonal methods of flow control. Thus, stamping mostly cannot stop spam on unmoderated newsgroups. Yet, it can and will work on moderated newsgroups, including retro-moderated groups. Moreover, postage allows for competition in moderation, with individual choice by posters, readers and relayers of whom to trust and whom not to trust as for (retro)moderation in each newsgroup, without a monopoly central control.

Wholly unmoderated newsgroups can't be efficiently protected by any kind of payment. Monetary payment to each reader isn't feasible, for leeches would jump on the opportunity to automatically collect such payment. Now, it seems that web advertisement is a variation on this theme. But this model doesn't match the purpose of newsgroups, where laypersons are meant to communicate on a common topic of interest. As for payment in human-time (to a moderating server set up by some group members), or in computer-time (based on message contents, date and destination), they can only deter spam in groups with a very limited readership, least the stamp cost so much as to deter regular posters, too. Still, payment in computer time could be thought as a ``better than nothing´´ way to deter non-targetted spam to newsgroups where spammers don't expect much readership.

On the other hand, regular (proactively) moderated newsgroups are very much like mailing-lists, and the previous section applies to them. In this case, all postage methods work, because bad messages are filtered out before they reach the readers at large, so that their cost to the spammer corresponds to no gain. On the other hand, such newsgroups may have unacceptable moderation latency that discourages people from posting, so that retro-moderation is usually preferrable for newsgroups as opposed to mailing-lists.

Retro-moderation can be easily combined with postage. Posters pay a stamp to the moderators' account, and in the case of monetary payment, the stamp is sent back after some delay if the message wasn't marked down by the moderators. Since a few readers may read the message before it was retromoderated, the price of the stamp should be high enough so that spammers will be discouraged to pay it so as to be able to reach the readers in the window between the emission and the retro-moderation; yet, it should be low enough to enable anyone to enter the conversation. Hence, retro-moderation is only worthwhile for newsgroup whose readership is not too large. Postage in human time or in computer time may also work if the retro-moderators are responsive enough to cancel messages before they reach enough public to make it attractive to spammers. If retro-moderators are responsive, but not quite so fast as to fully deter spammers, readers may improve deterrence by having their newsreaders delay their displaying of messages. On the other hand, all these considerations will only deter spammers if they actually know about the behaviour of moderators and readers.

As an optimization of the infrastructure, that allows for newsgroups with still larger readership, brokers may accept monetary stamps on behalf of moderators of many newsgroups. They will be paid out of interests in hoarded stamps, as well as out of unreturned stamps from refused messages. Brokers can also serve to enforce rules for newsgroups where the agreement of several moderators or the success of a certain kind of ballot is necessary to reject a message. Finally, brokers can act as an instance of flow control that save unnecessary and risky monetary transactions: by having a one-time open account at a brokers', you can send a certain number of simultaneous messages per unit of time, with your account serving as guarantee fund for retromoderation. Then, regular posters don't incur the risks of being stolen associated with doing a lot of transactions on computers that can be compromised by crackers; spammers on the other hand, have a larger chunk of money to be seized should they break the basic rules of the broker.

Now, a same group could have several groups of moderators or retro-moderators, with posters choosing to whom they send stamps, and relayers and readers choosing from whom to accept moderation. Actually, this is very much like having several newsgroups with mostly the same name, except that at times, readership may massively switch between moderators. In newsgroups with monetary payment through a broker who has rules against moderation abuse, and newsgroups with payment in time, posters could pay postage to several groups of retro-moderators, and readers and relayers could pick which retro-moderators to trust, thus allowing for competition in moderation and hence saner moderation in newsgroups that are currently controlled by political cabals. There can also be several brokers in competition, in case the usage rules of one broker are unadapted to market demand.

Note that while postage can work as a way to eliminate spam from newsgroups, the dynamics of postage acceptance is not quite as good with newsgroups as with regular email or mailing-lists: whereas with regular email and mailing-lists, acceptance can be achieved through incremental gains by recipients, newsgroup readers have no incremental gain in filtering based on stamps, if most senders in the newsgroup don't use stamps. Therefore, though postage can definitely help fighting spam in newsgroups, it will have to be popular already, and the infrastructure widely deployed, before whole newsgroups switch to using it. On the other hand, as a few specialized newsgroups begin to switch, and the infrastructure becomes cheap to deploy, the costs for other newsgroups to switch will get lower, and newsgroup postage can participate in accelerating acceptance of postage at the margin of Internet usage.

I wrote this article mainly between 2002-09-17 and 2002-09-19. I claim no particular originality to any single idea developed here, only in the overall way of putting things. As for the main idea of this article, I first heard about the notion of stamping email messages in some comment posted on Slashdot many months ago; however I have been unable to find that comment since. I also wish to thank the people who sent feedback, from the cybernethics mailing-list, advogato or kuro5hin.

Although the idea of using stamps against spam may have been found independently many times, the earliest reported inventor of it, as far as I know, is James B Robinson, who has been talking about it at computer law conferences and EFF Austin events since about 1994. He has even built a site for this idea: spamstamp.org. Other people who have proposed similar ideas include Brad Templeton, Scott E. Fahlman, Robert X. Cringely, Jon Udell. See also the Penny Black project at Microsoft Research.

Until a plan like the one hereby proposed is implemented, if it ever is, proper credits should go to all those whose efforts help make spam less of an annoyance that it would otherwise be: many thanks to CAUCE and other organizations that try to filter spam, as well as to the authors of spam-filtering software such as Paul Graham. As for my personal spam filtering experience, I wish to thank my friend Tril for his set of procmail filtering rules, upon which I built my own. Various versions of it achieved various results at filtering spam, but unhappily, the combinations I tried always either let some spam through, or caught some legitimate email.

The real credits will go to whoever actually implements such a postage system in a way that is convenient for anyone to install, or actually any efficient system that will make spam a nightmare of the past. Since I'm more of a speculative thinker than a doer, I fear this won't be me. But if you're interested in implementing it, or know someone who could be, or know a place where to advertise these ideas, please contact me — I'm ready to help getting such a system up and running, by giving advice, testing, and even petty coding.

Oh, and let me spit my contempt at those people responsible for my mailboxes being filled with tens of daily messages of spam, not to talk about viruses. (November 2004 update: I now get over 300 spam messages per day.)

Notes

Faré Rideau

Faré on Computing

Site by Faré Rideau — Donate: bitcoins or paypal