About that e-postage draft [POSTAGE]

[John Levine-3]

About a month ago, some ASRG members published this draft:

http://tools.ietf.org/html/draft-irtf-asrg-postage-00

Since then I haven't heard a peep about it.  Since this is
the asRg, the least we could do would be to try to do another
version that adds some discussion of where it might be used and
what the deployment issues are.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

John Levine <johnl@...> wrote:
>
> About a month ago, some ASRG members published this draft:
>
> http://tools.ietf.org/html/draft-irtf-asrg-postage-00
>
> Since then I haven't heard a peep about it.  Since this is
> the asRg, the least we could do would be to try to do another
> version that adds some discussion of where it might be used and
> what the deployment issues are.

   I hardly think all that needs to be in the draft...

   Nonetheless, we have perhaps been too quiet about it.

   Usage, of course, _could_ be on every email transaction. If the
extension were implemented for the popular open-source MTAs, widespread
adoption would be feasible. (Of course, any actual exchange of value
would require a "banking" structure: Ben April is working on that, but
I haven't asked him for a progress report.)

   I don't believe it appropriate to tie asrg-postage to any particular
"banking" structure. It needs only to deal with transfer of opaque
tokens between MTAs. I have jokingly suggested we do an inital deployment
using Zimbabwean dollars -- which nobody in his right mind could actually
want to redeem. ;^)

   One side of deployment is getting at least one commonly-used MTA to
implement it. I am trying to entice college students into doing that.
Another side of deployment is getting at least one party to put some
(currency) value into the system. A bit counter-intuitively, that part
looks easy: many mass-emailers would happily pay some small fraction of
snail-mail postage to get past spam-filtering (which silently drops
their "crucially-important" emails).

   It's important to understand that any real "banking" system is
going to deal in "settlements" -- only exchanging actual value between
banks based on the net differences of transactions. Thus, recipients'
banks will accumulate value as mass-emailers add it to their banks,
leaving recipients' MTAs' accounts with a surplus "too small to redeem"
available for paying "postage" on their outgoing emails that might
get caught in spam-filters.

   So long as mass-email remains well over 50% of email, there's no
need for average ISPs to put any net value into email postage!

   I think that's enough exposition for one email. There are bunches
of research topics in how to set postage rates, and maybe how to
shame larger ISPs into actually "paying", which I'd be happy to
discuss in _other_ emails.

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>> Since then I haven't heard a peep about it.  Since this is
>> the asRg, the least we could do would be to try to do another
>> version that adds some discussion of where it might be used and
>> what the deployment issues are.
>
>   I hardly think all that needs to be in the draft...

We're a research group -- if you want to do standards track, the IETF
is right down the hall.  I think it would be quite useful to have
something that describes a well thought out e-postage system, and all
the reasons it failed.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[David Nicol]

This has been sitting in my drafts folder for a three weeks so here it is:


i believe that the mechanisms for e-postage should be completely
orthogonal to e-commerce; merging them should be left to competitive
marketplace.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

David Nicol <davidnicol@...> wrote:
>
> i believe that the mechanisms for e-postage should be completely
> orthogonal to e-commerce; merging them should be left to competitive
> marketplace.

   My sentiments exactly!

John Levine earlier wrote:
]
] We're a research group -- if you want to do standards track, the IETF
] is right down the hall.  I think it would be quite useful to have
] something that describes a well thought out e-postage system, and all
] the reasons it failed.

   (I was tempted to reply, "It ain't dead yet!" ;^)

   I am willing to write up _a_ usage case, _if_ that will encourage
folks to actually _do_ research on this. But I don't believe it should
be part of an ePostage extension spec. There clearly are multiple
possible usage cases.

   As far as "deployment" plans, that seems premature; but I could
respond to specific questions about how it might deploy. (Keep in
mind that mass-email isn't all spam, and there are quite a few
mass-emailers that currently pay "vouching" services to improve their
delivery rates.)
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On Feb 10, 2009, at 7:09 PM, John Leslie wrote:

> As far as "deployment" plans, that seems premature; but I could  
> respond to specific questions about how it might deploy. (Keep in  
> mind that mass-email isn't all spam, and there are quite a few mass-
> emailers that currently pay "vouching" services to improve their  
> delivery rates.)

It would seem any e-postage system requires international arrangements  
similar to what now accommodates the exchange of physical mail.

Perhaps some type of random number exchange and cancelation process  
may involve the IETF.  Making random numbers the size of IPv6 might  
allow routers to sort validations and cancelations for a new type of  
postal router.

The next question might be how would countries be compensated for the  
dispersal of e-postage tokens, and their collection of fees?  The  
token itself should encode the country of origin.  Perhaps e-postage  
could be priced at one-tenth the price of international first-class  
stamps.  How can discount e-postage be prevented, since there would be  
a profit motive to cheat?  Perhaps this could be seen as a charity for  
third-world countries that have the cheapest stamps.

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[der Mouse-3]

> It would seem any e-postage system requires international
> arrangements similar to what now accommodates the exchange of
> physical mail.

I'm actually inclined to disagree with that.  There would be
international agreements required, because email crosses national
boundaries, but I think drawing the analogy to the agreements involved
for paper mail places the emphasis in the wrong place.  It makes it
sound as though the agreements would be between countries, when I think
the actually would need to be between providers, making them
international only when, and because, the providers involved are in
different countries.

> The next question might be how would countries be compensated for the
> dispersal of e-postage tokens, and their collection of fees?

Would they?  That works for postal mail, but (I believe) only because
postal mail is a governmental monopoly.  I doubt email will ever be a
national monopoly for more than a tiny fraction of the world's email
users, or mailservers.  (Postage-bearing email might, but my guess, for
what it's worth, is that that would kill postage-bearing email.)

s/countries/providers/ and the question is still reasonable, though it
requires thinking about in a rather different way because the entities
involved are so different.

/~\ The ASCII  Mouse
\ / Ribbon Campaign
 X  Against HTML mouse@...
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

Douglas Otis <dotis@...> wrote:

> On Feb 10, 2009, at 7:09 PM, John Leslie wrote:
>
>> As far as "deployment" plans, that seems premature; but I could  
>> respond to specific questions about how it might deploy. (Keep in  
>> mind that mass-email isn't all spam, and there are quite a few mass-
>> emailers that currently pay "vouching" services to improve their  
>> delivery rates.)
>
> It would seem any e-postage system requires international arrangements  
> similar to what now accommodates the exchange of physical mail.

   Actually, no: the arrangements are "inter-bank" not international.

   (There is the question of currency exchange rates, but banks do
that today.)

   Also, "bank" deserves to be in quotation marks, since there's no
essential advantage to having postage-issuing "banks" regulated by
national governments. (Only settlements between banks would be
visible, and presumably regulated.)

> Perhaps some type of random number exchange and cancelation process  
> may involve the IETF.  Making random numbers the size of IPv6 might  
> allow routers to sort validations and cancelations for a new type of  
> postal router.

   Not sure I see your point... ePostage-Banks issue postage, and the
same bank redeems it unless there's an agreement between "banks".
I see no role for IETF in designing such "inter-bank" agreements.

> The next question might be how would countries be compensated for the  
> dispersal of e-postage tokens, and their collection of fees?

   "Banks" would be compensated by debiting a customer account more
than the amount of ePostage issued and/or crediting a customer
account less than the amount redeemed. Or, perhaps there would be a
per-transaction fee (in the thousandths of cents, presumably). I
see no role for IETF in saying which model a "bank" uses.

   (It's even conceivable that each major email receiver might issue
its own ePostage instead of going through a "bank", and hide the
"banking" charges entirely.)

> The token itself should encode the country of origin.

   Encode the _issuer_, yes. There might be an IETF role in saying
how to encode it.

> Perhaps e-postage could be priced at one-tenth the price of
> international first-class stamps.

   Clearly there are some mass-emailers that would pay that; but I
expect the actual amount to settle on a much smaller number. That's
a research issue. ;^)

> How can discount e-postage be prevented, since there would be  
> a profit motive to cheat?

   What do you mean, "cheat"? The receiver says what's acceptable,
and cries "TILT" if s/he doesn't get it.

   I do expect _any_ "standard" ePostage amount to be undercut by
some receivers: left to myself I'd skip the step of setting a
"standard" amount.

> Perhaps this could be seen as a charity for third-world countries
> that have the cheapest stamps.

   I do expect some receivers to choose to accept charity-issued
stamps. It will appeal to some folks' sensibilities. :^)

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Steve Atkins]

On Feb 11, 2009, at 2:45 PM, John Leslie wrote:
>
>   "Banks" would be compensated by debiting a customer account more
> than the amount of ePostage issued and/or crediting a customer
> account less than the amount redeemed. Or, perhaps there would be a
> per-transaction fee (in the thousandths of cents, presumably). I
> see no role for IETF in saying which model a "bank" uses.

Just to throw some arithmetic onto this.

A large consumer ISP might send 50 million emails a day externally.  
Assuming that
there isn't "one bank to rule them all" it seems reasonable to assume  
that
any given "bank" wouldn't handle much more than that. A thousandth
of a cent banking charge would be about $500 / day or $182,500 / year.

That's not a plausible budget for running any organization with the  
level
of reliability and backing that would be needed, not by at least one  
order of
magnitude.

So "thousandths of cents" doesn't seem realistic language when  
discussing
a per-transaction fee.

Cheers,
   Steve

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

Steve Atkins <steve@...> wrote:
> On Feb 11, 2009, at 2:45 PM, John Leslie wrote:
>>
>> "Banks" would be compensated by debiting a customer account more
>> than the amount of ePostage issued and/or crediting a customer
>> account less than the amount redeemed. Or, perhaps there would be a
>> per-transaction fee (in the thousandths of cents, presumably). I
>> see no role for IETF in saying which model a "bank" uses.
>
> Just to throw some arithmetic onto this.

   Very welcome!

> A large consumer ISP might send 50 million emails a day externally.  

   That sounds low to me.

> Assuming that there isn't "one bank to rule them all" it seems
> reasonable to assume that any given "bank" wouldn't handle much more
> than that.

   I'd agree that depending on more than 100 million per day in
drafting a business plan would be risky.

> A thousandth of a cent banking charge would be about $500 / day or
> $182,500 / year.

   I did say "thousandths" (plural). Will you allow me two?

   And IMHO, there are two transactions per email. We've passed
$500,000 per year, anyway.

> That's not a plausible budget for running any organization with the  
> level of reliability and backing that would be needed,

   What level of reliability _is_ needed?

   I figure five-nines on losing track of a token is marketable.
Tokens outstanding needn't exceed, say, a billion. Guessing one cent
tokens, we've got perhaps $10 million "outstanding", but in fact
only settlements ever need to change hands.

> not by at least one order of magnitude.

   That's "close enough" -- I was a physics major. ;^)

> So "thousandths of cents" doesn't seem realistic language when  
> discussing a per-transaction fee.

   If so, the market will support a higher fee. (I don't mind!)

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>>   "Banks" would be compensated by debiting a customer account more
>> than the amount of ePostage issued and/or crediting a customer
>> account less than the amount redeemed. Or, perhaps there would be a
>> per-transaction fee (in the thousandths of cents, presumably). I
>> see no role for IETF in saying which model a "bank" uses.

>So "thousandths of cents" doesn't seem realistic language when
>discussing a per-transaction fee.

I did a similar calculation for my white paper, and even a penny a
message isn't enough, particularly if you have to budget for large
numbers of spams with fake or duplicate postage that will require most
of the work of verifying a real stamp, but provide no revenue.

I hear that a lot of research involves models.  Perhaps a model of
where the money will have to go would be useful.

R's,
John

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

John Levine <johnl@...> wrote:

> Date: 12 Feb 2009 02:44:51 -0000
> From: John Levine <johnl@...>
> To: asrg@...
> Cc:
> Subject: Re: [Asrg] About that e-postage draft [POSTAGE]
>
>>> "Banks" would be compensated by debiting a customer account more
>>> than the amount of ePostage issued and/or crediting a customer
>>> account less than the amount redeemed. Or, perhaps there would be a
>>> per-transaction fee (in the thousandths of cents, presumably). I
>>> see no role for IETF in saying which model a "bank" uses.
>
>> So "thousandths of cents" doesn't seem realistic language when
>> discussing a per-transaction fee.
>
> I did a similar calculation for my white paper, and even a penny a
> message isn't enough, particularly if you have to budget for large
> numbers of spams with fake or duplicate postage that will require most
> of the work of verifying a real stamp, but provide no revenue.

   By "per transaction", I meant per _transaction_, not per _email_.
(Is it possible we're not discussing the POSTAGE draft? It doesn't
contain "stamps" that are carried in message headers, but a "token"
passed between MTAs.)

   A receiving MTA asking its "bank" to redeem a token is a transaction
whether or not the token is forged, and the "bank" needs to recover
that transaction cost. I suspect sending MTAs that deliver bad tokens
will get blacklisted quickly; but I can imagine ways to reduce the
need for a "transaction" with the bank to verify that a token is
plausible.

   (Need I remind our readers that receiving email _already_ provides
no revenue?)

> I hear that a lot of research involves models.  Perhaps a model of
> where the money will have to go would be useful.

   Hmm...

   I can imagine many models.

   Clearly, in almost any model, "banks" will have to cover transaction
costs, and receiving MTAs will want to recover costs of transmission
(including support costs).

   I expect most receiving MTAs will also want to cover POSTAGE for
their normal volume of outgoing email. (Charging end-users for
POSTAGE will only be practical for users with a large volume of
outgoing email.)

   But I wouldn't preclude some portion of the POSTAGE being credited
to the end-users -- I just don't expect that to be workable.

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>   A receiving MTA asking its "bank" to redeem a token is a
> transaction whether or not the token is forged, and the "bank" needs
> to recover that transaction cost. I suspect sending MTAs that
> deliver bad tokens will get blacklisted quickly; but I can imagine
> ways to reduce the need for a "transaction" with the bank to verify
> that a token is plausible.

My standard spam model is that the bad guy buys one stamp and uses
that one genuine stamp on a thousand messages (transactions, whatever)
at the same time.  It's really easy to verify that a stamp is real
using digital signatures, but there's no way to tell if it's already
been used other than asking the issuer.

It is possible to defend against this threat, but not cheaply, since
the defense requires a robust transaction system that can serialize
the thousand requests, approve one, and reject the other 999, while
still providing service to the rest of their customers.  Through the
magic of botnets, the thousand messages come from a thousand different
MTAs, of course.

>   (Need I remind our readers that receiving email _already_ provides
> no revenue?)

Indeed, but banks don't work for free.  (Well, not deliberately.)  You
want someone to provide stamps, you've got to make it worth his while.

>   I can imagine many models. ...

Indeed.  Now beef some of them up with some realistic estimates of
transactions costs, and the costs of dealing with screwed up and
fraudulent transactions.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

John Levine <johnl@...> wrote:

>
>> A receiving MTA asking its "bank" to redeem a token is a
>> transaction whether or not the token is forged, and the "bank" needs
>> to recover that transaction cost. I suspect sending MTAs that
>> deliver bad tokens will get blacklisted quickly; but I can imagine
>> ways to reduce the need for a "transaction" with the bank to verify
>> that a token is plausible.
>
> My standard spam model is that the bad guy buys one stamp and uses
> that one genuine stamp on a thousand messages (transactions, whatever)
> at the same time.  It's really easy to verify that a stamp is real
> using digital signatures, but there's no way to tell if it's already
> been used other than asking the issuer.

   Agreed.

> It is possible to defend against this threat, but not cheaply, since
> the defense requires a robust transaction system that can serialize
> the thousand requests, approve one, and reject the other 999, while
> still providing service to the rest of their customers.

   I'm not clear which party you're talking about here. The "bank" takes
redemption requests serially and acts on them serially. The list of
valid tokens can be kept in RAM. That amounts to no measurable delay.

   The receiving MTA takes email transactions, possibly in overlappping
threads, and as each token is decoded, queries the agreed "bank". We
have all the transmission time of the DATA to get a reply. Short of the
"bank" suffering a DoS attack it's hard to imagine that not being long
enough. If there are multiple copies of the same token provided to a
single MTA, I suspect they'll get around to blacklisting the sending
MTA, but that's an economic decision: the "bank" will accept no more
than one of them.

> Through the magic of botnets, the thousand messages come from a
> thousand different MTAs, of course.

   Of course. Will the economic incentive cause all 1,000 to be
blacklisted? Possibly...

>> (Need I remind our readers that receiving email _already_ provides
>> no revenue?)
>
> Indeed, but banks don't work for free.  (Well, not deliberately.)  You
> want someone to provide stamps, you've got to make it worth his while.

   One way or another, I expect banks to cover these transaction costs.

>> I can imagine many models. ...
>
> Indeed.  Now beef some of them up with some realistic estimates of
> transactions costs, and the costs of dealing with screwed up and
> fraudulent transactions.

   I believe I have done so. It will take more than calling my
estimates "unreasonable" to make me abandon them.

   Some numbers, please...

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>> It is possible to defend against this threat, but not cheaply, since
>> the defense requires a robust transaction system that can serialize
>> the thousand requests, approve one, and reject the other 999, while
>> still providing service to the rest of their customers.
>
>   I'm not clear which party you're talking about here. The "bank" takes
>redemption requests serially and acts on them serially. The list of
>valid tokens can be kept in RAM. That amounts to no measurable delay.

Um, you might be surprised.  Locking systems that just serialize
everything into one queue are unlikely to be fast enough to be
interesting, particularly if you hope to handle an interesting fraction
of Internet mail, which by my back of the thumb estimate is about two
million messages/second.

Also, unless the bank is planning to keep all the money for itself, it
needs to have some way for the client presenting the tokens to collect
the money eventually.  That means either a book entry system where
each client has an account and the bank has to mark the token as
having been paid into that account, or a bearer system where the bank
creates and sends the client a reissued token that it can cash in
later.

People have been thinking about micropayments for 15 years, and
transaction systems for 50 years (really), and you are assuming a
cheap solution to a long-term unsolved problem.

That's why I think it would be a good idea to at least develop the
model to the point where we can evaluate whether a putative solution
is good enough.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

John Levine <johnl@...> wrote:

>>
>> I'm not clear which party you're talking about here. The "bank" takes
>> redemption requests serially and acts on them serially. The list of
>> valid tokens can be kept in RAM. That amounts to no measurable delay.
>
> Um, you might be surprised.  Locking systems that just serialize
> everything into one queue are unlikely to be fast enough to be
> interesting, particularly if you hope to handle an interesting fraction
> of Internet mail, which by my back of the thumb estimate is about two
> million messages/second.

   I see no problem handling one million queries per second in a
RAM-based system. Locking is likely overkill -- the tokens in RAM are
known-good (or already deleted): the debit/credit need not be real-time.

> Also, unless the bank is planning to keep all the money for itself, it
> needs to have some way for the client presenting the tokens to collect
> the money eventually.  That means either a book entry system where
> each client has an account and the bank has to mark the token as
> having been paid into that account, or a bearer system where the bank
> creates and sends the client a reissued token that it can cash in
> later.

   That choice should be up to the bank. I was thinking book-entry
with credit/debit lagging token redemption by perhaps a few seconds.
(Locking for the book-entry part is worth doing.)

> People have been thinking about micropayments for 15 years, and
> transaction systems for 50 years (really), and you are assuming a
> cheap solution to a long-term unsolved problem.

   I'm assuming the problem is defined wrong if it takes 50 years
to solve. Once you separate token creation/redemption from _all_
other accounting (by journaling the creation/redemption) it becomes
much simpler. And once you move the token database into RAM, timing
problems pretty much disappear.

> That's why I think it would be a good idea to at least develop the
> model to the point where we can evaluate whether a putative solution
> is good enough.

   Ben is working on that.

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Levine-3]

>> People have been thinking about micropayments for 15 years, and
>> transaction systems for 50 years (really), and you are assuming a
>> cheap solution to a long-term unsolved problem.
>
>   I'm assuming the problem is defined wrong if it takes 50 years
>to solve. Once you separate token creation/redemption from _all_
>other accounting (by journaling the creation/redemption) it becomes
>much simpler. And once you move the token database into RAM, timing
>problems pretty much disappear.

Sigh.  There are lots of transaction systems that work well, and have
been since about 1964.  But there are no transaction systems that
handle a very high transaction rate, most of which are rejected and
provide no revenue, at a cost of a tiny fraction of a cent per
transaction.  We haven't even started to consider how the transactions
get in and out of the systems with the RAM, and I don't think it would
be productive to do so at this point.

That's why I really think it would be a good idea to figure out what
sort of performance and what sort of cost an e-postage system would
need, as a prototype or as a production system, so in the even that
someone came up with a concrete design, we could tell whether it's
within an order of magnitude of being workable.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

John Levine <johnl@...> wrote:

>
>>> People have been thinking about micropayments for 15 years, and
>>> transaction systems for 50 years (really), and you are assuming a
>>> cheap solution to a long-term unsolved problem.
>>
>> I'm assuming the problem is defined wrong if it takes 50 years
>> to solve. Once you separate token creation/redemption from _all_
>> other accounting (by journaling the creation/redemption) it becomes
>> much simpler. And once you move the token database into RAM, timing
>> problems pretty much disappear.
>
> Sigh.

   ... psi-star dV

> There are lots of transaction systems that work well, and have
> been since about 1964.

   OK, the problem still might be defined wrong if it takes fifteen
years to solve...

> But there are no transaction systems that handle a very high
> transaction rate, most of which are rejected and provide no revenue,
> at a cost of a tiny fraction of a cent per transaction.

   Then, let's stop trying to do all that at once.

   We need the high transaction rate.

   We need to be able to reject, say, 99% of the requests.

   We don't need to charge nothing at all for a rejection.

   Being a bear-of-small-brain, I prefer to have the "bank" charge
for rejected transactions. This allows the receiving MTA a wide choice
of strategies for deciding how quickly (or even whether) to present
tokens for redemption. (Tarpitting is still a useful tactic.)

> We haven't even started to consider how the transactions get in and
> out of the systems with the RAM,

   Quite true -- and that's a more serious bottleneck, IMHO...

> and I don't think it would be productive to do so at this point.

   Nor do I -- it's an unrelated problem with standard solutions.

> That's why I really think it would be a good idea to figure out what
> sort of performance and what sort of cost an e-postage system would
> need, as a prototype or as a production system,

   I believe we could do useful research with a million-per-day volume,
but it seems pointless to me not to design the "transaction" portion
to handle a million-per-second (leaving network I/O as the bottleneck).

   By "transaction" I mean:

- a customer with sufficient credit balance asks for a token; or

- a customer with an existing account asks to redeem a token.

In neither case does the "transaction" need to debit or credit the
appropriate account at the microsecond of the "transaction" -- these
could be batched for processing an hour later if necessary. The
"transaction" involves only the creation and redemtion of tokens
issued by the "bank" and redeemed by the same "bank".

   The actual per-transaction pricing is an open issue -- I'd guess
an upper limit is around a tenth of a cent per "transaction", but
I expect competition to drive that well below a hundredth of a cent.
(For research, a goal of a tenth of a cent seems fine.)

> so in the even that someone came up with a concrete design, we could
> tell whether it's within an order of magnitude of being workable.

   Be my guest...

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

On Thu, Feb 12, 2009 at 09:58:41PM -0000, John Levine wrote:
> Indeed.  Now beef some of them up with some realistic estimates of
> transactions costs, and the costs of dealing with screwed up and
> fraudulent transactions.

Along those same lines, such an estimate must take into account a minimum
of 100M botted hosts, and correspondingly, a minimum of 100M compromised
sets of email credentials. [1]

Thus, such an estimate must be able to cope gracefully with the case
where (say) 1M systems simultaneously (or nearly so) present the same
token to (say) 100K mail systems -- and must do so without permitting on
an effective DoS on the transaction processor.  (And note that, modulo
the token, this is a routine occurence.  It could reasonably be expected
to become more so if abusers found it effective.)

---Rsk


[1] These estimates may be much too small to reflect reality; for example,
a compromise of my system would eventually expose over 30 sets of such
credentials, each picked up in turn as it was used.  Personally, I think
"250m" and "1.5B" are probably more realistic numbers.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[John Leslie]

Rich Kulawiec <rsk@...> wrote:
> On Thu, Feb 12, 2009 at 09:58:41PM -0000, John Levine wrote:
>
>> Indeed.  Now beef some of them up with some realistic estimates of
>> transactions costs, and the costs of dealing with screwed up and
>> fraudulent transactions.
>
> Along those same lines, such an estimate must take into account a
> minimum of 100M botted hosts, and correspondingly, a minimum of 100M
> compromised sets of email credentials. [1]

   Reasonable numbers...

> [1] These estimates may be much too small to reflect reality; for
>     example, a compromise of my system would eventually expose over
>     30 sets of such credentials, each picked up in turn as it was
>     used. Personally, I think "250m" and "1.5B" are probably more
>     realistic numbers.

   Can I deal with those estimates separately?

> Thus, such an estimate must be able to cope gracefully with the case
> where (say) 1M systems simultaneously (or nearly so) present the same
> token to (say) 100K mail systems -- and must do so without permitting on
> an effective DoS on the transaction processor.

   I take "simultaneously" to mean "within one second".

   First, from the "bank's" viewpoint: it receives 100K requests to
redeem, at worst; credits one and refuses the rest. All 100K get charged
a transaction fee.

   From the receiving MTAs' viewpoint: each starts an SMTP session,
requests postage (probably in differing amounts) and gets a token.
Since the sending MTA is on a suspected-bot blocklist, it either
presents the token as quickly as possible (in hopes of being the first
to present), or tarpits long enough to see whether the IP address
shows up on a confirmed-evil-bot blocklist.

   Remember, presentation of a bad token is a much clearer indication
of evil intent: a few dozen should suffice for blocklisting. It's
quite practical to blocklist 100 million IPs, at which point the
problem will start to disappear. Computers blocklisted this way will
pretty much be forced into going through a relay MTA with which they
have a contractual relationship -- which removes the problem from
the "botted-MTA" territory.

> (And note that, modulo the token, this is a routine occurence. It
> could reasonably be expected to become more so if abusers found it
> effective.)

   Agreed.

--
John Leslie <john@...>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg