ietf-asrg
[Top] [All Lists]

[Asrg] Re: the e-postage argument

2004-04-20 07:04:40
Hi.  It's me, Mr. epostage-can't-work.

I need to keep rewriting my epostage paper to make the fundamental points
clearer.  The three big issues are transaction costs, settlements, and
identity.  Another is that no postage scheme in the history of mankind has
existed to deter use rather than to pay delivery costs, but let's skip
that one and decide to innovate.

The transaction cost issue is the simplest: any kind of e-postage system
is going to need a transaction per message to check the stamps.  Spammers
are going to put bogus e-postage on their mail, and the only way to see if
an e-stamp is valid is to check with the issuer.  Even if you use a crypto
signature scheme to see if the stamp is real, you still need to ask issuer
if it's already been used somewhere else.  I have yet to see a faintly
plausible plan that would build and pay for a transaction system big
enough to handle the world's e-mail.  I'm not talking about settlements
here, just whether the stamp is OK.  The biggest transaction system to
date is the one for Master Card and Visa, and it's both too small and too
expensive by several orders of magnitude each.

You settle at the ISP level ...

Settlements: You run an ISP, you tell us.  There are something like 5000
ISPs in the U.S. and probably at least that many outside the U.S.  Are you
going to send out 5000 checks every month for your settlements?  (Or net
it out with each, so it's on average only 2500.)  How are you going to
keep track of whether the other ISPs have paid up, and if they don't, what
will you do about it?  You can't wave these issues away, these are the
nuts and bolts that make a payment system work or not, and if you don't
shut down the deadbeats, the e-postage stops being real money.

If the ISPs do the settlements on behalf of their customers, the ISPs are
acting as banks, with all of the fraud and default problems that regular
banks have, and which they spend a lot of money to handle.  Real banks
handle the clearing problem with centralized clearing systems they all
join, Mastercard/Visa for credit cards, NYCE, Cirrus, and PLUS for ATM
transactions, and the Federal Reserve for checks.  These all cost a lot
more per transaction than any likely e-postage system will collect, and
are designed in a world where the vast majority of transactions are OK and
you handle the bad ones as exceptions, which doesn't impress me as a good
model for an environment where spam is 80% of all mail and growing.

Even worse, what about the ISPs that aren't in the US?  How do you send
50 cents to each of five ISPs in Bangladesh?  Credit cards?

Identity: lots of people have pointed out the zombie problem, that
spammers will hijack Aunt Betsy's computer and charge the postage to her.
The response I usually hear from epostage enthusiasts is that Aunt Betsy
won't let the zombies on her PC once she's had to pay a few hundred bucks
in spam epostage.  Based on my observation of the real world, that's not
gonna happen.  Every month you see the predictable story about some loser
whose PC got misconfigured or got a Moldavian dialer installed or
something, and was shocked to get a thousand dollar phone bill.  Do they
actually pay the thousand bucks?  Never.  They negotiate it down, stiff
the phone company, or something.  ISPs would be stuck in a no-win
situation where their customers will hate them if they try to collect, and
their e-mail peers will hate them if they don't.


Howsabout the whole damned phone system? Isn't that essentially a
"micropayments" system in many aspects?

In some, yes, in others, no.  It differs from e-mail in that it's a closed
system, with relatively few players, rather stringent barriers to entry
and really complicated financial settlements that start with the
difference between "bill and keep" and "reciprocal compensation" and get
worse from there, with the ITU, an impenetrable government
meta-bureacracy, in the middle.

Don't people feel a little silly arguing that the entire phone system
as currently constituted among several billion people world-wide
represents a charging/payment model which is easily (in a few pages of
this paper, apparently) ``proven'' to be completely untenable because
someone, somewhere might defraud it etc?

You must have read some other paper than the one I wrote, because I never
said or implied that.

Here's a thought experiment: imagine that you run a store in some part of
the wild west, and 90% of the cash that people offer you to pay for stuff
is bogus.  How are you going to handle transactions?  How long will you
spend examining each coin?  Will you refuse to do business with anyone
who's offered you bogus money?  What about people who've gotten it in
change somewhere else and didn't notice?  This is the environment
e-postage has to face, not a little fraud, but vastly more bogus
transactions (at least attempted ones) than real ones.  I don't know of
any financial system that works in an environment like that.

It's time to go for an e-postage system that simply reflects the
resources being used.

OK, so build one.  I don't know how to build one where the transaction
costs aren't 10 times greater than the costs that the transactions are
supposed to cover, despite a decade of micropayment research, but maybe
we've overlooked something.  I think we all agree that it's not going to
sit on top of SMTP mail, so someone should take a tip from the phone
system, build a closed system that you can only get into by spending a
hundred grand and being approved by the club that runs it, and give the
end users a nice point and click program that runs on Redmond Crudware yet
isn't going to be instantly subverted through the weekly egregious system
security hole.  People will rush to use it.  Right?

Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>