Is there any hope for e-postage?

2009-03-01

John Levine

Taughannock Networks, USA
Editor: Helen Martin

Abstract

If the senders of email had to pay a small amount for each message sent, wouldn’t it diminish the spam problem? Unfortunately, we will never find out - John Levine explains why e-postage won't work.


Unlike postal mail, Internet email has always been a ‘recipient pays’ system. That is, the cost of each message is borne almost entirely by the recipient or the recipient’s Internet provider, rather than by the sender. This historical quirk has considerable benefits, making it possible to send both individual one-to-one messages and multi-recipient mail cheaply and easily to willing recipients.

Unfortunately, it has made it equally cheap and easy to send great volumes of unsolicited mail to increasingly overwhelmed recipients. Unsolicited bulk email (UBE), informally known as spam, has become the scourge of the Internet.

Many observers have noted that the amount of postal mail we receive is limited by its cost to the sender. Bulk postal mail costs about 50 cents per piece (taking into account the printing and mailing costs as well as postage) – which provides mailers with an incentive to send mail only to recipients that are likely to be interested. If the senders of email had to pay a small amount for each message sent, wouldn’t it similarly diminish the spam problem? Unfortunately, we will never find out because e-postage just won’t work.

E-postage scenarios

E-postage has been proposed as a solution to a variety of different problems. The most often cited is the spam problem – too much unwanted mail – but it has also been suggested as a way to compensate receivers for the cost of processing wanted mail. In this regard it is somewhat like the settlement systems that real-world post offices and telephone companies use.

Different e-postage proposals have different details, but most of them follow the same general plan. Each sender buys a supply of stamps – coded tokens created by a bank – that can be sent along as part of a message. The recipient mail system checks for the presence of a stamp, verifies that it is real (which is not a simple task, as we shall see), and accepts the mail if it has a valid stamp. The recipient or the recipient’s mail system collects the value of the stamps on incoming mail.

Most proposals have some provision for waiving or refunding postage on some mail – for example, mail from regular correspondents, messages from non-commercial mailing lists and other sources of mail that the recipient welcomes. In some models, a recipient can choose to accept mail without e-postage from senders that appear on a whitelist of known correspondents. In others, all mail must bear postage, but the recipient has the option to refund the postage to the sender. Some schemes allow for negotiation of the amount of postage collected, with recipients charging more to senders they consider less trustworthy.

In effect, e-postage acts as a sort of reputation system, in which a sender who is unknown to the recipient offers some money as an indication of good faith. There are a lot of other reputation systems in use, ranging from DNS blacklists such as the Spamhaus lists, to the web-of-trust signatures in Pretty Good Privacy (PGP). Any e-postage system that professes to be a reputation system needs to demonstrate that it is a better alternative than the reputation systems already in use.

Creating electronic stamps

Nearly all e-postage schemes (with the exception of hashcash, discussed later) require a micropayment system to handle the exchange of value for e-postage stamps.

It is instructive to look at paper postage stamps and see how they serve as a model for e-postage, and how they do not.

For paper mail, each country usually has a monopoly post office from which all mailers buy stamps. The post office inspects each letter at the time it is mailed to ensure that it bears adequate postage, cancels the stamp, and sends it along through the mail system. All mail within the system is presumed to have adequate postage. International mail has to be transferred from one post office to another, with the handoffs negotiated either bilaterally or through the Universal Postal Union in Berne, but the post offices trust each other to ensure that mail they exchange has adequate postage. The 200 or so national post offices pay each other monthly settlements based on the relative volumes of mail in each direction.

Until 2000, there was a single central clearing house for all post offices, but a more complex system has since been introduced due to the failure of some post offices to pay what they owe.

How analogous is the real-world postal system to email? Other than the problem of deadbeats, not very. Twenty years ago, closed email services such as MCI Mail and Compuserve worked on the postal model, charging a fee for every message introduced. This model collapsed when the people building the Internet created an email system in which mail messages were too cheap to meter. As the closed systems connected to the Net, per-message charges disappeared.

On today’s Internet, nearly every network runs its own email post office, from the largest (AOL, Hotmail/MSN and Yahoo!) down to tiny businesses and individuals’ systems with only a handful of users. It is a triumph of the Internet’s design that these hundreds of thousands of separate mail systems all interoperate without prearrangement.

But most mail systems are strangers to each other, and any particular pair of servers will rarely exchange more than a trickle of mail. This means that setting up direct agreements between individual sending and recipient mail systems is impractical, so they need a mutually trusted intermediary, that is, a bank.

It is important to realize that, unlike paper mail, the e-postage fee is paid to the ultimate recipient or the recipient’s ISP, rather than to a third-party post office, perhaps with a cut taken by the bank. This has the benefit of potentially reimbursing the recipient for handling the mail (remember that the recipient bears the bulk of the cost), but the disadvantage that it gives recipients an incentive to maximize the amount of incoming postage they collect, possibly by unscrupulous means.

Banks and micropayments

E-postage is an example of a micropayment. We loosely define micropayments as payments that are individually too small for conventional payment systems like credit cards or bank transfers.

Online payment systems may either be book entry systems – in which every user has an account with the bank, and payments are made by the payer telling the bank to move money from their account to the recipient’s account – or bearer systems, in which the payer gives a token directly to the payee which can later be redeemed at the bank.

Bearer payments can be somewhat faster than book entry, since the bank doesn’t have to be involved in every transaction, but they present greater risk of fraud. It’s not hard for a bank to create electronic stamps and sign them with a digital signature that any user can check against the bank’s published key to ensure they are valid. (In the literature, these are usually called coins, but the application here is postage, so we’ll refer to them as stamps.) Since a sender can send the same valid stamp to many recipients, a recipient who receives a stamp from an unknown sender needs to cancel it, contact the issuing bank to verify that it hasn’t been used before, and to reissue it to the recipient so it can be used on another message or cashed.

Since the Internet is available all over the world, we can expect stamps to be issued by banks located all over the world. Thus mail will often arrive from a sender that is unknown to the recipient, bearing stamps issued by a bank that is also unknown to the recipient. The majority of banks are likely to be competently run, but inevitably some (such as the Bank of Deceased Generals of Nigeria) will (deliberately or inadvertently) issue stamps that they cannot later cash.

To look at a real-world analogy, when a customer presents a cheque drawn on an unknown foreign bank to a US bank, the usual procedure is to send the item for collection, wait a month to find out whether the cheque was good, and charge a $20 fee for the extra handling – a process that is notably neither fast nor cheap. Usable international e-postage will need a system that lets recipients decide in real time whether they’re willing to accept stamps from unknown foreign banks. I can imagine some possibilities, such as various forms of correspondent banks, deposit insurance, or organizations that will vouch for the validity of banks’ stamps and cash them if the banks can’t – but this adds another layer of yet-to-be-implemented complexity and cost to any payment system.

Since such a large proportion of mail traffic is spam (90% or more now), and assuming that most spam will have forged postage, in practice recipients will have to check with the issuing bank for all incoming stamps. This makes the verification a challenge. Imagine you’re buying a sandwich and go to pay in a world where 90% of the money offered is counterfeit. Rather than giving your cash a cursory look and tossing it in the till, the cashier would carefully and slowly scrutinize each bill and coin.

To speed up processing, many proposed micropayment systems make the digital equivalent of a cursory glance, using a statistical model that makes the amount collected close to the exact amount. But these systems all assume that most stamps are real; if most stamps are in fact fake, any approximate model will end up accepting a lot of fake stamps – a weakness spammers would surely exploit. Hence any adequately secure payment system would have to check all, or at least nearly all, of the offered stamps with the issuing banks.

The micropayment infrastructure

Knowing that each mail delivery will need to have its stamp validated with a bank, we can estimate the size of the transaction system needed. The largest mail systems, AOL and Hotmail, each report dealing with two billion or more messages a day. A conservative estimate of the number of daily deliveries in the US is 150 billion messages a day. In comparison, Visa, the largest credit card network, reports about 120 million card transactions a day.

This means that widely deployed e-postage will involve over a thousand times as many transactions as the largest credit card system. Even assuming that the transactions are a lot simpler than credit card transactions, say one tenth as hard, e-postage would still need a system 100 times the size of Visa’s system. It took many billions of dollars of investment and four decades to build the credit card system. No micropayment system that is large enough even to serve as a prototype has yet been built. One of the largest deployed micropayment systems, e-gold, reportedly has only 66,000 transactions a day [1].

Even though the number of transactions involved in e-postage would be enormous, the total amount of money involved would not be. If a stamp costs a penny, which is on the high side of proposed prices, and 10% of the total stamps presented are real (the other 90% being spam), and the bank’s cut on each stamp is 10%, the bank has only one tenth of a cent to spend to cancel each real stamp and one hundredth of a cent to reject a fake stamp. Even granting that computers are cheap and these are relatively simple transactions, this is still an awfully low budget for a transaction system where each error will cost someone real money, and seems utterly inadequate to pay for the construction of a transaction processing system in the first place.

Cancelling a stamp turns out to be a surprisingly difficult database operation. Although searches and retrievals can be handled efficiently by multiple computers with copies of the data, reliable updates of a particular item all have to funnel to a single place where the master copy of the item is kept, and that place needs to have reliable locking in place so that when a bad guy tries to use the same stamp on 1,000 pieces of mail at once, the first cancel operation works, and the other 999 don’t. Efficient, reliable database updates are difficult to achieve, and this is a problem that people have been thinking about since at least the 1960s, with no better answer than to make the update choke points as fast as possible. That’s why airline reservation systems can use racks of cheap PCs to handle fare and schedule lookups, but when it comes to making a reservation, marking a seat as sold, and marking the reservation as paid, nothing but a big expensive mainframe computer will do. Mainframes are cost effective and affordable when one is selling $500 plane tickets, but are unlikely to be either cost effective or affordable for stamps that cost six orders of magnitude less.

Virtual postage meters

One suggested variation on e-postage bears a closer resemblance to paper post offices. In this model, the sending mail system checks the stamps on all the mail it forwards (or, for small sending systems, an intermediate aggregator may do so). For large senders, the system provides each sender with a virtual ‘postage meter’ it can use to print its own stamps, and the system uses contracts and spot checks to assure compliance, much as post offices do with meters and permit holders.

Either way, this system then forwards the mail to other systems it knows, with a promise that all the postage has been paid. This might work, but if the recipient system is willing to trust the sending system enough to skip the postage verification, there’s no need to involve postage in the first place. It’s basically a web of trust and bilateral agreements between systems that know each other – a system that works fine on a small scale, but not for the hundreds of thousands of mail systems in the whole Internet.

Hashcash

Hashcash is an alternative form of e-postage that uses computer CPU time rather than real money. When a mail system receives a message from an unknown sender, it poses a complex computational problem to the sender’s computer, and won’t deliver the message until the sender’s computer provides the answer. The idea is to pose problems that take a few seconds to solve, so they wouldn’t delay mail from individual senders much, but would be impossibly slow for mail sent in bulk.

Hashcash was an elegant idea when it was first proposed by Cynthia Dwork and Moni Naor at IBM in 1992 [2] and it’s still elegant now. Unfortunately, it also suffers from technical and social problems.

The technical problems are that some computers are a lot faster than others, and that currently spammers have a lot more computer power at their disposal than legitimate senders do. High-volume senders use high-end servers with multiple CPUs that run at 3,000 MHz or more, while the archetypical grandmother exchanging mail with friends and relatives can get by perfectly well with an old PC with a 100 MHz 486. A problem that takes a second on the servers would take several minutes on the 486, whereas one that takes a second on the 486 would take 10 milliseconds on the server. There is no way to create a problem that is of appropriate difficulty across the wide range of computers that are used for mail. (Some schemes attempt to use memory bandwidth rather than CPU time, but memory speeds vary almost as much as CPU speeds.)

Furthermore, spammers have vast arrays of hijacked ‘zombie’ computers at their disposal. Blacklist maintainers report adding 10,000 newly hijacked computers to their blacklists per day. Spammers already use zombies to send most spam, and they could easily program the zombies to solve hashcash problems along the way. Even zombies that can’t send mail due to blacklisting or ISP firewalls can be used as compute servers to solve hashcash problems for spam sent from elsewhere. No legitimate mailer has anything like 10,000 computers dedicated to sending mail, much less 10,000 additional computers a day, meaning that it would be easier for spammers to satisfy hashcash than for legitimate senders.

Postage and identity games

Spammers have consistently manipulated and gamed the email system for their own ends, forging origin information to evade responsibility, and appropriating innocent parties’ equipment via open relays, proxies and deliberately compromised hosts, both to hide the origin of their spam and to pump it out faster. Many spammers also engage in plain old financial fraud with stolen credit card numbers and the like. What would they do with e-postage?

I don’t claim any great insight into the criminal mind, but I can immediately see several varieties of e-postage scam. One class of fraud lets spammers send mail without paying the postage, using missing or fake stamps, or by charging the postage to someone else. Since e-postage is collected by the recipient, thereby making mail valuable to the recipient, a second class of fraud would collect postage from unwilling senders, either by tricking people into sending mail to strangers under false pretences, or by impersonating someone to whom they do want to send mail. If successful, these frauds would make e-postage actively dangerous.

To send mail without paying postage, one might send spam with fake or duplicate stamps hoping recipients won’t check them, send mail with forged return addresses that are on recipients’ whitelists, send a little innocent mail to get whitelisted then follow up with a lot of spam, set up a fake bank that deliberately issues uncashable stamps, or trick a legitimate bank into issuing postage without paying for it.

To charge e-postage to third parties one might sneak spam into other people’s mailing lists, or use botnet software that sends spam from the third party’s computer.

To collect postage from unwitting senders, one might seed chain letters of the ‘Bill Gates will pay you $20 if you send mail to this address’ variety, or use the proven ‘click here to get free porn’ websites with web pages that send email messages. All of these tricks lead to administrative and legal problems. If someone plants a virus on your machine that sends out spam, who pays the postage? If the answer isn’t ‘you do’, who decides whether to waive the postage, and how do they tell a genuine virus victim from a spammer who planted a virus on his own system? If users do have to pay for any mail that viruses send, how many users would be willing to accept the unknown extra costs of having an email account?

Address forgery is already rampant in spam, both to defeat whitelists and to hide the spam’s origin. Although cryptographic schemes such as PGP and S/MIME that authenticate senders have existed for many years and are supported by all popular user mail programs, almost nobody uses them. DKIM (DomainKeys Identified Mail), a recently issued standard from the IETF, seems likely to gain wider acceptance, but isn’t designed to identify individual users or accounts. Even a technically secure signature that identifies an individual user is easily stolen if the user’s computer is hijacked.

No doubt it would be possible to come up with a set of laws and procedures and tribunals to deal with all the scams and for deciding when to refund or waive how much to whom, as well as rating or discount services to keep track of all the issuing banks of varying reliability. However, there is no reason to assume that the resulting situation would be any better than the current one, and since it would involve real money, the risks to individual users would likely be a lot greater. All we really know at this point is that the true financial, administrative, and social costs of e-postage are completely unknown.

Users hate micropayments

Finally, users of all kinds of communication systems have shown over and over again that they prefer flat rate to metered service, even if the flat rate service costs more. Andrew Odlyzko has published a seminal series of papers looking at the history of the pricing of mail, telephone, and other communication media including the Internet, and has found that they all consistently move from per-message or per-minute pricing to flat rate. In a 2003 paper [3] he argued that for this and other reasons, micropayments are unlikely to succeed except in small niches where they can piggy-back on a payment scheme that already exists, such as mass-transit smart cards.

One of the reasons that email has been so popular is that it is unmetered, and you don’t have to hunt – literally or figuratively – for a stamp each time you send a message. It’s hard to see users voluntarily moving backward to the metered systems they abandoned a decade ago.

Is there any hope for e-postage?

Although there is no likelihood of e-postage being deployed broadly across the Internet for general email, it may succeed in some niche applications. For mail and mail-like services that are expensive to provide, such as email to fax or paper mail gateways, or mail to satellite phone terminals, users already set up accounts and pay per-message. That’s not likely to change, but it is not a big growth market.

Another possibility is Reputation Purchase Systems (RPS) for bulk mail, in which mailers pay ISPs for guaranteed or preferred delivery of mail. Rather than each mailer and each ISP negotiating a separate agreement, intermediaries would negotiate blanket agreements with ISPs and also handle any complaints about the mail. Goodmail SystemsCertified Email program is an example of such a RPS intermediary [4]. It’s hard to see RPS as more than a niche, though. After a while, most mailers either will have earned a good reputation, in which case they will be able to get whitelisted without paying, or they’ll have bad reputations, in which case ISPs will reject their mail regardless of offers to pay, since no plausible per-message payment could come close to the cost of handling a customer spam complaint.

Bibliography

[2] Dwork, C.; Naor, M. Pricing via Processing or Combatting Junk Mail, 1999. The original hashcash proposal. http://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp.ps.

[3] Odlyzko, A. The Case Against Micropayments, 2003. A summary of all the reasons why micropayments will never be popular. http://www.dtc.umn.edu/˜odlyzko/doc/case.against.micropayments.pdf.

[4] Goodmail Systems’ Certified Email program. http://www.goodmailsystems.com/products/certified-email/.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.