John Levine <johnl(_at_)taugh(_dot_)com> wrote:
Ideally, the token is issued by a "bank" where both sending MTA and
receiving MTA have accounts.
You probably don't want to do that,
For the sake of keeping research simple, I do.
since the performance of book entry transactions is worse than for
bearer ones.
You can think of this as a bearer system if that helps. Tokens
created are very like bearer tokens (except that the "bank" might limit
which customers are eligible to redeem them. They sit unrelated to
any existing account until "presented" for redemption, or until they
expire. The amount redeemed eventually works its way into the
receiving MTA's account.
Or, of course, someone could invent a totally different "banking"
system -- the POSTAGE spec is (intentionally) quite silent on how
"banking" transactions are performed. (I'm sure the three authors have
three different ideas of many details of the "banking" system: we
merely satisfied ourselves that there existed at least one way to
accomplish the function.)
If you're doing book entry, you need at least a journalling system to
log the entries to be added to each account, if not locks on each
account to maintain the balance.
I prefer journaling. IMHO, the actual balance _can_ never be stable
for receiving MTAs -- they'll just decide what's a comfortable cushion
in the account. There's really no good reason why senders shouldn't do
likewise.
Here's the least awful way I know to do small value online payments:
Sender goes to his bank and buys a bunch of bearer stamps. There are
two things one can do with a bearer stamp, cancel/reissue, and redeem
it.
Sounds good.
Cancel/reissue simply creates a new stamp worth the same as the old
stamp (or maybe a little less if the bank keeps its cut) but promises
that the new stamp is good. If the old stamp has already been
cancelled, this fails. This transaction is supposed to be fast, since
it needs only check the one bit to see if it's been used and generate
the new stamp or maybe take one from a precomputed list of them.
I'm not sure how much call there will be for this...
Redeeming is a batch process, collect a whole bunch of stamps, send
them in to the bank, and in a while you get a credit for all of them,
maybe in an account in that bank, maybe sent to your real bank.
There's no particular reason to collect a "whole bunch" unless the
"bank" makes a charging system to encourage that. Any such financial
benefit needs to be weighed against the possibility that someone else
will redeem it first. (Regardless, you should expect a lag before the
credit shows up in your account: this is not a problem so long as you
know whether the token was honored.)
The point of bearer stamps is that the bank doesn't try to track who's
got them, they're like cash and whoever presents a stamp first wins.
Exactly. For example, a bad sender might buy a good stamp, then race
to the bank to redeem it before he finishes sending the DATA.
So when you get those reissued stamps for incoming postage, you have
to keep those private, since if someone else finds out what they are
and sends them to the bank first, he wins and you lose.
(You may have noticed the spec mentions "The SMTP client and server
may wish to use TLS to secure the amounts involved.")
None of this is new, this was all worked out a decade ago. But it's
all still way too slow to keep up with an interesting amount of e-mail.
Have you perhaps not noticed Moore's Law at work these last ten years?
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg