Subject: Re: [Asrg] About that e-postage draft [POSTAGE]

From: David Nicol <[email-masked]>
Date: Tue, 10 Feb 2009 11:03:37 -0600

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.

---

From: John Leslie <[email-masked]>
Date: Tue, 10 Feb 2009 22:09:21 -0500

> orthogonal to e-commerce; merging them should be left to competitive

   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.)

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Feb 2009 11:58:35 -0800

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

> 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

---

From: der Mouse <[email-masked]>
Date: Wed, 11 Feb 2009 15:37:17 -0500 (EST)

> 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.

> 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		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: John Leslie <[email-masked]>
Date: Wed, 11 Feb 2009 17:45:47 -0500

> 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.)

> allow routers to sort validations and cancelations for a new type of  

   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.

> 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 <[email-masked]>

---

From: Steve Atkins <[email-masked]>
Date: Wed, 11 Feb 2009 15:23:35 -0800

> 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

---

From: John Leslie <[email-masked]>
Date: Wed, 11 Feb 2009 19:17:12 -0500

> 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.

> 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. ;^)

> discussing a per-transaction fee.

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

---

From: John Levine <[email-masked]>
Date: 12 Feb 2009 02:44:51 -0000

>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

---

From: John Leslie <[email-masked]>
Date: Thu, 12 Feb 2009 09:21:34 -0500

John Levine <[email-masked]> wrote:
> Date: 12 Feb 2009 02:44:51 -0000
> From: John Levine <[email-masked]>
> To: [email-masked]
> Cc: 
> Subject: Re: [Asrg] About that e-postage draft [POSTAGE]
> 

   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?)

> 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.

---

From: John Levine <[email-masked]>
Date: 12 Feb 2009 21:58:41 -0000

>   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

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

---

From: John Leslie <[email-masked]>
Date: Thu, 12 Feb 2009 19:12:10 -0500

> been used other than asking the issuer.

   Agreed.

> 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...

> 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.

> transactions costs, and the costs of dealing with screwed up and

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

   Some numbers, please...

---

From: John Levine <[email-masked]>
Date: 13 Feb 2009 00:47:48 -0000

>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

---

From: John Leslie <[email-masked]>
Date: Thu, 12 Feb 2009 21:08:28 -0500

> of Internet mail, which by my back of the thumb estimate is about two

   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.

> creates and sends the client a reissued token that it can cash in

   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.)

> 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.

> model to the point where we can evaluate whether a putative solution

   Ben is working on that.

---

From: John Levine <[email-masked]>
Date: 13 Feb 2009 10:09:11 -0000

>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

---

From: John Leslie <[email-masked]>
Date: Fri, 13 Feb 2009 08:38:49 -0500

John Levine <[email-masked]> wrote:
> 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.

> 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...

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 13 Feb 2009 08:40:25 -0500

> transactions costs, and the costs of dealing with screwed up and

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.

---

From: John Leslie <[email-masked]>
Date: Fri, 13 Feb 2009 09:21:21 -0500

Rich Kulawiec <[email-masked]> wrote:
> 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?

> 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.

---

From: mathew <[email-masked]>
Date: Sun, 15 Feb 2009 09:14:15 -0600

> still providing service to the rest of their customers.

Nonsense. You just make the purchased stamp dependent upon the address of
the recipient, for example by hashing the To: address inside the
cryptographic stamp when it's minted.

You know, like SSL certificates include the hostname so you can't use the
same one on multiple sites.

Sure, the spammer can then send 1000 copies of the stamp with 1000 spam
messages, but 999 of them will be rejected when the stamp is decoded,
without any network transaction being required.

mathew

---

From: John Leslie <[email-masked]>
Date: Sun, 15 Feb 2009 13:56:04 -0500

mathew <[email-masked]> wrote:
> Nonsense. You just make the purchased stamp dependent upon the address
> of the recipient, for example by hashing the To: address inside the

   Minor correction: for the POSTAGE draft, the token may cover multiple
To: addresses; thus it should be tagged with the receiving MTA, not the
To: address.

> You know, like SSL certificates include the hostname so you can't use
> the same one on multiple sites.
> 

   This might be worth adding to the POSTAGE draft -- not that it isn't
already possible, just that for this to catch multiple use of the same
token it would need to be mandatory. What do folks think?

---

From: John Levine <[email-masked]>
Date: 15 Feb 2009 23:12:09 -0000

>cryptographic stamp when it's minted.

Aw, come on.  Please don't tell me I have to explain why this model has
the exact same problem.

Really, if you're the least bit serious about doing this, you need a
performance model to help analyze proposals, many of which are likely
to have much more subtle problems than this one.

R's,
John

---

From: Bart Schaefer <[email-masked]>
Date: Sun, 15 Feb 2009 15:50:18 -0800

On Feb 15,  1:56pm, John Leslie wrote:
} Subject: Re: [Asrg] About that e-postage draft [POSTAGE]
}
} mathew <[email-masked]> wrote:
} > 
} > Nonsense. You just make the purchased stamp dependent upon the address
} > of the recipient, for example by hashing the To: address inside the
} > cryptographic stamp when it's minted.
} 
}    Minor correction: for the POSTAGE draft, the token may cover multiple
} To: addresses; thus it should be tagged with the receiving MTA, not the
} To: address.
} 
}    This might be worth adding to the POSTAGE draft -- not that it isn't
} already possible, just that for this to catch multiple use of the same
} token it would need to be mandatory. What do folks think?

John might recall that during our off-list discussion of the POSTAGE
draft, I suggested using a per-transaction token such as DSN ENVID for
this sort of tagging, but we chose to avoid becoming entangled with
the DSN extension.

Tagging per MTA isn't nearly as effective as per recipient or per
transaction, because for some MTAs (a Yahoo MX, for example) the number
of possible recipients becomes large enough that using the same stamp
on thousands of transactions is still a viable attack.

However, I'd like to remind everyone of one important aspect of the
POSTAGE draft:  It doesn't rely on the notion of "buying a stamp".

The transaction is structured such that the token presented by the
sender is more like a credit card authorization.  The token allows the
recipient MTA to make a charge of a specified amount against an account
maintained by (a bank on behalf of) the sender.  The sender does not
obtain the "stamp" from the recipient, he gets it from his bank.

If that sender chooses to present the same stamp a million times, it's
up to the sender and his bank to resolve the dispute; if the bank has
no way to detect and refuse duplicates, it can simply tally them all
up and bill the sender after the fact.

This doesn't in any way address problems of a pwned machine grabbing
tokens from a compromised bank account, but it does mean that the
recipient MTA can ignore the problem and expect to be paid no matter
what shenanigans are going on at the other end of the wire.

---

From: mathew <[email-masked]>
Date: Mon, 16 Feb 2009 09:07:00 -0600

> Aw, come on.  Please don't tell me I have to explain why this model has

Go on, indulge us. Explain why stamps that are hashed to the recipient can
still be spent on multiple spams unless a network transaction is carried out
for every one.

Let's go ahead and assume that the stamp also has an expiry date encoded
into it, mmkay?

mathew

---

From: Benjamin April <[email-masked]>
Date: Mon, 16 Feb 2009 11:25:44 -0500

mathew wrote:
> On Sun, Feb 15, 2009 at 17:12, John Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Go on, indulge us. Explain why stamps that are hashed to the recipient
> can still be spent on multiple spams unless a network transaction is
> carried out for every one.
>
> Let's go ahead and assume that the stamp also has an expiry date
> encoded into it, mmkay?
>  
>
> mathew

I think we need to go the other way. Stop assuming the token contains
*anything* useful.
It is intended to be an opaque meaningless value. This removes the
possibility of anything
but brute-force forgery.

If we have lots of complex encoding of values we open the door for
people to forge those
values. We also extend the time to clear a token through the receiving
"bank" considerably
and enter a world of crypto-library incompatibility, varying format
versions etc.

Before I get flamed I should say that a well designed DHT lookup for an
opaque token would
certainly be faster than verifying a signature then doing a DHT lookup
for the serial number.
I will also go out on a limb and say that doing a DHT insert of random
block of pre-existing
random data and monitoring the result for duplication will be faster
than marshaling and signing
a new token based on a series of values.

This is not to say that the "BANK" can't encode something they find
useful in a token, but 
I would urge them not to.  "BANKS" are also welcome to declare
number-space limitations
if the like e.g. mod 7 or prime but again this severely limits the
search-space for a brute-force
attack.

The beauty of a simple token like this is that you can keep a cache of
token's you have seen
recently. Recently being defined by the amount of disk space you wish to
dedicate to this.
If you have seen the token in the last "X" consider it invalid. MTA
implementations need
to be vigilant in looking for brute-force attacks (as should "BANKS") to
prevent cache-poisoning
attacks.

Thanks
Ben

> ------------------------------------------------------------------------
>
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg
>

---

From: John Leslie <[email-masked]>
Date: Mon, 16 Feb 2009 12:04:36 -0500

> Aw, come on.  Please don't tell me I have to explain why this model has

   Actually, it's not "exactly" the same: though the "bank" has a very
similar problem, encoding the recipient MTA would mean that there's a
test the recipient MTA could do before submitting to the "bank".

   I'm a bit open on this issue, but I'm disinclined to change the spec
before we get some research experience. I do think it wise for the "bank"
to ask what receiving MTA the token is destined for, but it seems to me
that

- whether it actually encodes that in the token, and
- whether it tells the receiving MTA how to decode it

are issues we shouldn't specify yet.

---

From: John Leslie <[email-masked]>
Date: Mon, 16 Feb 2009 12:17:38 -0500

> obtain the "stamp" from the recipient, he gets it from his bank.

   Ideally, the token is issued by a "bank" where both sending MTA and
receiving MTA have accounts. Whether those accounts are like "credit" or
"debit" cards or some other model entirely is orthogonal to the spec.

   (We envision agreements between "banks" that enable sending MTAs to
request a token from a different "bank" than the one the receiving MTA
will redeem it at; but that is out of scope at the moment, and we hope
for research where both use the same "bank".)

> up and bill the sender after the fact.

   Obviously this would make for an unhappy customer!

   But Bart is correct to say that this is an issue between customer
and "bank" -- the spec is, and IMHO should be, silent on what happens
if a "bank" redeems the same token more than once.

---

From: Steve Atkins <[email-masked]>
Date: Mon, 16 Feb 2009 09:33:07 -0800

On Feb 16, 2009, at 7:07 AM, mathew wrote:

> Go on, indulge us. Explain why stamps that are hashed to the  
> recipient can still be spent on multiple spams unless a network  
> transaction is carried out for every one.
>

If it's simply hashed then anyone can create them. That means it's  
possible to send a large number
of messages using stamps that look entirely plausible prior to them  
being looked up at the central
broker. There are obvious reasons why people would do this.

So, the next step is to use some crypto such that it's possible for  
anyone to validate that the stamp
may be plausible for the recipient, but not for anyone to generate it.  
Maybe you use public key
signatures - presumably with the private key held solely by the bank.

But that means that stamps are not interchangeable. You can't buy them  
or generate them in
advance, or at least not in bulk, in advance. Instead you have to  
purchase them (from one of a
small number of "banks") at the time you send the mail as well as  
redeem them (from that very
same bank) later.

(Given that the sending machine has to contact a central server and  
the receiving machine
also has to contact the same central server during the transmission of  
the message there are a lot
of other things you could do with it that are simpler than epostage).

Cheers,
   Steve

---

From: Paul Russell <[email-masked]>
Date: Mon, 16 Feb 2009 12:45:55 -0500

On 2/16/2009 12:04 PM, John Leslie wrote:
> I do think it wise for the "bank" to ask what receiving MTA the token is 
> destined for, but it seems to me that
> 

In other words, the sender must buy a seperate "stamp" for each message sent,
at the time the message is sent.  This precludes "buying a book of stamps"
or "filling the postage meter", and using the postage, as needed, over time.

The suggestion from Benjamin April <[email-masked]> that an e-postage token
should have an opaque value makes sense to me.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]

---

From: John Levine <[email-masked]>
Date: 16 Feb 2009 19:27:36 -0000

>But that means that stamps are not interchangeable. You can't buy
>them or generate them in advance, or at least not in bulk, in
>advance. Instead you have to purchase them (from one of a small
>number of "banks") at the time you send the mail as well as redeem
>them (from that very same bank) later.

Right -- we've just moved the bottleneck from cashing the stamps to
generating the stamps.

But actually, we haven't moved it, since the bad guy can use the same
stamp to send multiple spams to the same victim unless the bank also
cancels the stamps.

The idea of an expiration time is not terrible, but now it means that
we're putting a hard limit on how slow a recipient system can be and
not lose valid mail due to expiring stamps.  There's a tradeoff
between replay prevention and lost mail that I doubt has a satisfactory
resolution, since it's not hard to send dozens or hundreds of messages
a second, but an unavailable system is often unavailable for minutes
or hours.

If you allow senders to redeem unused expired stamps, now you have yet
another race condition of trying to use a stamp and redeem it within a
small interval around the expiration time.

It would be really nice if anyone suggesting a postage scheme do at
least a rudimentary threat analysis like this, what are likely ways
that bad guys will try to defraud it, what are the countermeasures,
and how expensive are they.

R's,
John

---

From: Benjamin April <[email-masked]>
Date: Mon, 16 Feb 2009 15:07:00 -0500

> broker. There are obvious reasons why people would do this.
KISS, A simple back-off solves this. After your third bogus token my MTA
won't accept a postage-due e-mail for 1 minute from your MTA. IMO
something like this should be done regardless of weather the token has
any encoded meaning. (insert your own values)
> signatures - presumably with the private key held solely by the bank.
My main concern here is that allowing the receiving MTA to validate the
token offers a false sense of authority. We now know it is far easier
than originally expected to create a "fake" signing cert. While some
will argue that using appropriately modern hashing etc will mitigate
that, I say it only delays the inevitable.
On the other had the only known valid attack against a truly random (and
secret) opaque token is brute-force.  We have plenty of history to look
at for reducing the effectiveness of this kind of attack.
> redeem them (from that very
I see this as a big issue.  I would find having to go to the post office
every time I needed a stamp insane. By using opaque tokens you could buy
a selection of tokens in advance and dispense them on demand.
> of other things you could do with it that are simpler than epostage).
In the opaque token model I do not see this as a required state.  You
would be able to pre-buy tokens and only the recipient would have to
have ongoing connection with the "BANK". Maybe some banks will offer
discounted fees to MTAs who provide advance notice before placing a big
order for tokens.

Thanks
Ben

---

From: Steve Atkins <[email-masked]>
Date: Mon, 16 Feb 2009 12:40:17 -0800

> any encoded meaning. (insert your own values)

OK. I have 100,000 MTAs. Now what are you going to do?

> that, I say it only delays the inevitable.

Yup.

> at for reducing the effectiveness of this kind of attack.

Well, no. There are many, many other types of attack against a system
that uses opaque cookies.

But the two obvious choices are either something involving cryptographic
authentication or an opaque cookie. They're different enough that
they should probably be considered separately, if at all.

>> them

Yes. (Or, with some limits, reuse them, but that's a different aspect).

> discounted fees to MTAs who provide advance notice before placing a  

My statement was in the context of epostage stamps which are purchased
for a specific recipient. Obviously if that's not the case you can buy
stamps in bulk (or reuse stamps you receive) rather than having to
buy them specifically for each recipient.

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 16 Feb 2009 21:22:51 -0000

>receiving MTA have accounts.

You probably don't want to do that, since the performance of book
entry transactions is worse than for bearer ones.  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.

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.

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.

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.

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.
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.

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.

R's,
John

---

From: mathew <[email-masked]>
Date: Wed, 18 Feb 2009 11:27:45 -0600

> stamp to send multiple spams to the same victim unless the bank also

Or unless the receiving system does elementary checks for the same stamp 
being used multiple times. But obviously, since your main interest is 
convincing everyone that e-postage is impossible, you're going to assume 
that the receiving system is implemented without even the most blatantly 
obvious checks.

mathew

---

From: mathew <[email-masked]>
Date: Wed, 18 Feb 2009 11:37:45 -0600

Benjamin April wrote:
> than originally expected to create a "fake" signing cert.

It was never intended to be anything other than trivial to create a 
signing cert. But just because I can create a signing cert, doesn't mean 
that anyone else is going to recognize it.

With SSL, the fact that you create a signing cert doesn't mean any 
browser software is going to accept it as valid. With e-postage, 
sensible recipients will have a policy of not accepting unknown postage 
vendors by default. Just as browsers have lists of signing certs they 
accept, so e-mail MTAs and/or client software will have lists of signing 
certs they accept.

I would imagine that to get your cert onto the standard list for a 
common MTA, you'd need to demonstrate that you actually paid out the 
postage and weren't just committing fraud. Much as you won't get added 
to the default cert list for Firefox if you irresponsibly sign any SSL 
key presented to you.

> a selection of tokens in advance and dispense them on demand.

The only reason having to go to the post office every time you need to 
buy a stamp is insane, is that the post office is a physical entity you 
have to travel to.

Millions of people buy e-postage from the USPS every day, in order to 
ship stuff they sell on eBay. They go to the online post office every 
time they need to obtain and print a stamp. So there's a real world 
example showing that it's not an unworkable way of doing things.

I don't know if the USPS makes their e-postage codes dependent on the 
address you're sending to, but clearly they *could* without breaking the 
way ordinary people use the service or making it unworkable. It would 
actually be an interesting experiment to try cutting up two USPS 
e-postage labels, switching the bar codes around, and seeing if the 
items still got delivered properly...

mathew

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 18 Feb 2009 13:00:59 -0500

I don't see how this has any possibility of working.  Economic systems
analogous to the mechanism you describe work, and are financially viable,
because the overwhelming majority of transactions that they process are
legitimate, and the transaction charges levied are sufficient to cover
the overhead of detecting and dealing with the bogus ones.  But the exact
opposite is true w.r.t. email: the overwhelming majority of transactions
are bogus.  (And the adversary can easily push "overwhelming majority"
to as many 9's as necessary or desirable at will.)

Are there any real-world examples of systems where (say) 99% of the
attempted transactions are fraudulent, yet the system remains viable?

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 18 Feb 2009 13:03:58 -0500

> the "botted-MTA" territory.

Blacklisting those 100 million IPs -- which most sensible folks did
years ago, either by subdomain, regexp, IP, DNSBL or some mechanism --
has not forced them to go through relay MTAs.  The only thing that will
force them to through relay MTAs are router/firewall rulesets on the
networks within which they reside.

However, suppose -- against all experience -- that actually happens.
(And that'd be a good thing, so I'm not arguing against; it's just
that if it were going to happen, I think it would have happened within
a few months of the rise of the zombies.)

In that case, every relay MTA you see will present "a few dozen"
bogus tokens very shortly thereafter, because some/most/all of those
100 million IPs will now be sending through them.  Do you plan to
blacklist all those relay MTAs?

If so, then you could just do that now and skip the exercise.

If not, then you're going to have to still do it the hard way.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 18 Feb 2009 13:06:15 -0500

> cryptographic stamp when it's minted.

How's that going to work with forwarding, virtual user tables, and
alias expansions?   And how will it avoid leaking information when
someone is BCC'd?

---Rsk

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 18 Feb 2009 10:47:32 -0800

On Feb 18,  1:06pm, Rich Kulawiec wrote:
} Subject: Re: [Asrg] About that e-postage draft [POSTAGE]
}
} On Sun, Feb 15, 2009 at 09:14:15AM -0600, mathew wrote:
} > Nonsense. You just make the purchased stamp dependent upon the address
} > of the recipient, for example by hashing the To: address inside the
} > cryptographic stamp when it's minted.
} 
} How's that going to work with forwarding, virtual user tables, and
} alias expansions?

It doesn't, by fiat.  The POSTAGE draft applies to an SMTP transaction,
not to an end-to-end transmission through all possible store-and-forwards
of a message from a sender to a recipient.

Maybe this oversimplifies it into uselessness, but that's how it's
structured.  It's an SMTP extension, not a format-of-internet-messages
extension.

} And how will it avoid leaking information when someone is BCC'd?

The crytpographic stamp doesn't need to survive the transaction any more
than the Bcc header itself does.

---

From: Benjamin April <[email-masked]>
Date: Wed, 18 Feb 2009 13:56:55 -0500

mathew wrote:
> signing cert. But just because I can create a signing cert, doesn't
> mean that anyone else is going to recognize it.
>
> sensible recipients will have a policy of not accepting unknown
> postage vendors by default. Just as browsers have lists of signing
> certs they accept, so e-mail MTAs and/or client software will have
> lists of signing certs they accept.
>
While that is accurate it misses the point. There is a verified attack
methodology whereby I can create my own key-pair to replace the key-pair
blessed by a trusted CA(e.g. Verisign). I can then use my key-pair as if
it were signed by the CA, and it would be trusted as such. When the CA
signs a key they only sign a digest. There are still CA's that use MD5
as their digest algorithm. Known weaknesses in MD5 make this possible.
Most CAs that were on the ball moved to a form of SHA, but that is
nothing but a delay tactic.
> buy a stamp is insane, is that the post office is a physical entity
> you have to travel to.
You've got me there. I still do not see a good reason to mandate
send-time transactions.
> example showing that it's not an unworkable way of doing things.
There are also models where you buy a quantity of e-postage and generate
your own stamps without (mint-time) contact with USPS. I don't think it
is un-workable however I don't yet see a compelling reason mandate the
linking a token to a recipient.

> address you're sending to, but clearly they *could* without breaking
> the way ordinary people use the service or making it unworkable. It
> would actually be an interesting experiment to try cutting up two USPS
Thanks
Ben

---

From: John Levine <[email-masked]>
Date: 18 Feb 2009 22:32:48 -0000

>being used multiple times. [snark]

A large mail system like AOL or Comcast has somewhere between dozens
and hundreds of MTAs handling something like two billion delivery
attempts per day.

If you know a way to do cheap fast duplicate detection in such an
environment, I know a lot of people who'll be interested to hear about
it, and not just for e-postage.

R's,
John

---

From: John Levine <[email-masked]>
Date: 18 Feb 2009 22:41:40 -0000

>example showing that it's not an unworkable way of doing things.

A few moments' online research reveals that Paypal did 214.5 million
transactions last year, of which a little under half were from eBay.
A hundred million transactions a year is under 300K per day, and I'd
be surprised if as many as half of them bought online USPS postage to
ship the order.

It's easy to believe that the USPS has a system that can handle 150K
or 200K transactions a day, but that's four orders of magnitude lower
than what an e-postage system would need to handle, and their average
transaction is probably three orders of magnitude more expensive than
an e-stamp.

It would save us all a lot of time if people proposing a design would
make at least a small attempt to get the numbers right.

R's,
John

---

From: John Levine <[email-masked]>
Date: 18 Feb 2009 22:46:23 -0000

>attempted transactions are fraudulent, yet the system remains viable?

One possible model is the .COM registrar-registry database.  Nearly
all of the registration attempts are domain sniping, attempts to grab
a domain the moment it expires, and nearly all of them fail, either
because the domain isn't free yet or someone grabbed it a millisecond
before.

On the other hand, the failing transactions aren't fraudulent, just
failures.  Every registrar trying to do a transaction is known to the
registry and there's under 1000 of them. A successful transaction is
worth $6 which can support quite a lot of unsuccessful ones.

R's,
John

---

From: John Leslie <[email-masked]>
Date: Wed, 18 Feb 2009 17:59:16 -0500

John Levine <[email-masked]> wrote:
> 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.

> two things one can do with a bearer stamp, cancel/reissue, and redeem

   Sounds good.

> 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...

> 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.)

> 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.

> 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.")

> 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?

---

From: John Leslie <[email-masked]>
Date: Wed, 18 Feb 2009 18:26:18 -0500

Rich Kulawiec <[email-masked]> wrote:
> has not forced them to go through relay MTAs.

   Nonetheless, we receive a significant amount of spam through some
ISP's mailservers...

   I think you're glossing over the difference between something
merely "unsolicited" vs. something _fraudulent_.

> The only thing that will force them to through relay MTAs are
> router/firewall rulesets on the networks within which they reside.

   Granted, reaching no recipients doesn't technically "force" them
to do anything -- that's why I said "pretty much be forced".

> a few months of the rise of the zombies.)

   Blacklists are pretty blunt weapons. We field many complaints when
a blacklist blocks email the sender considers legitimate. The balance
between a "small inconvenience" and a total failure to pass "essential"
information keeps todays blacklists on the timid side.

   If OTOH, we can point to a plainly _fraudulent_ act, the balance
becomes easier. And if we can point to a currency value, perhaps
including "treble damages", to resolve the problem, reasonable folks
would have to agree that trusting "postage" from someone who already
defrauded you is too much to ask.

> 100 million IPs will now be sending through them.

   The relay MTAs are responsible for their own postage tokens. There
is no reason for them to "trust" tokens from their users.

> Do you plan to blacklist all those relay MTAs?

   If they ship fraudulent tokens, yes.

> If so, then you could just do that now and skip the exercise.

   No I can't, because there is nothing fraudulent about what they've
done.

> If not, then you're going to have to still do it the hard way.

   Understand, we'll have to accept email without postage from some
ISPs and enterprises that don't implement the POSTAGE extension.
That's not a fault of the POSTAGE extension. Only if they imlement
it and send fraudulent tokens can we take a strong blacklisting
position.

---

From: Bill Cole <[email-masked]>
Date: Thu, 19 Feb 2009 17:38:07 -0500

> John Levine <[email-masked]> wrote:
[...]
>    Have you perhaps not noticed Moore's Law at work these last ten years?

CPU power is not likely to be the critical bottleneck for a system that has 
to do large numbers of transactions across the Internet. Network latency is 
particularly resistant to Moore's law or anything like it.

---

From: der Mouse <[email-masked]>
Date: Thu, 19 Feb 2009 18:21:53 -0500 (EST)

> Network latency is particularly resistant to Moore's law or anything
> like it.

Well, sure; we're up to the point where speed-of-light is a substantial
fraction of the latency of long-haul links.  I suspect - admittedly
without evidence - that if you subtract off the speed-of-light delay,
something rather like Moore's law will turn up.

When $DAYJOB opened an office in Thailand and people were complaining
about the network latency, I had to point out that something like half
the latency we were seeing was compelled by a combination of lightspeed
and going around (versus through) the planet.  Our planet is something
like 140 light-milliseconds around, and we were seeing quarter-second
RTTs - and I don't for a moment think packets were taking great-circle
paths to get there.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: mathew <[email-masked]>
Date: Thu, 19 Feb 2009 19:01:44 -0600

On Wed, Feb 18, 2009 at 12:06, Rich Kulawiec <[email-masked]> wrote:

> alias expansions?

(a) recipient has to know (and tell the system) which addresses he expects
forwarded e-mail from--just like with today's spam filters.
(b), (c) receiving MTA has to take its aliases and virtual user tables into
account when checking the signatures on e-postage.

>   And how will it avoid leaking information when
> someone is BCC'd?

Use a one-way hash.

mathew

---

From: mathew <[email-masked]>
Date: Thu, 19 Feb 2009 19:06:26 -0600

> be surprised if as many as half of them bought online USPS postage to

I'd also be surprised if every USPS e-postage transaction was performed via
PayPal. There are plenty of sellers who use third party services, go
directly to USPS, use Pitney-Bowes machines, and so on. PayPal users are the
minority, in my experience.

> transaction is probably three orders of magnitude more expensive than

Thank goodness nobody's proposing a single central vendor for e-postage. And
thank goodness nobody's insisting that any proposed system must be able to
handle the entire e-mail volume of the Internet on day 1.

mathew

---

From: John Leslie <[email-masked]>
Date: Thu, 19 Feb 2009 20:53:52 -0500

Bill Cole <[email-masked]> wrote:
> CPU power is not likely to be the critical bottleneck for a system that
> has to do large numbers of transactions across the Internet.

   Actually, CPU power _can_ be a bottleneck, though seldom the critical
one.

   Moores' law also applies to RAM. It has become somewhat practical to
address a terabyte of RAM. This eliminates storage latency, for all
practical purposes, which usually _is_ the critical bottleneck.

> Network latency is particularly resistant to Moore's law or anything

   Agreed, but network _bandwidth_ has benefited substantially from
Moore's law.

   The bottom line is, redeeming a million tokens per second is practical
with processing delay not much greater than network latency. (This was
not true ten years ago...)

---

From: Bill Cole <[email-masked]>
Date: Fri, 20 Feb 2009 18:25:05 -0500

>    Actually, CPU power _can_ be a bottleneck, though seldom the critical

Any component *can* be a bottleneck. Maybe my point would be clearer put
this way:  throwing more processing power at a high-volume OLTP system that
has to talk to clients across the Internet stops having returns long before
it requires the deployment of 21st-century CPU technologies.

> practical purposes, which usually _is_ the critical bottleneck.

Storage latency can certainly be a problem and I'm convinced that it is the
easiest bottleneck to create or eliminate by seemingly trivial details of
logical design and implementation. That makes it a common criticality in
deployed systems, where it is often cheaper/faster/easier to fix than design
and/or coding, but it isn't rational for the hardware aspects of storage to
be critical in a system that has to chat with clients halfway around the
world. As Mouse noted, RTT's in hundreds of milliseconds are assured by
physics for as long as the Internet operates with wires, fiber, and photons
(rather than with spin-coupled antiparticle pairs or wormholes...) When many
transactions will have one or more 100ms periods of dead time and
essentially all will have 10ms waits, there's no fundamental reason for hard
storage latency to be critical.

>    Agreed, but network _bandwidth_ has benefited substantially from

Which doesn't help much for a transactional system that ultimately has to
serialize a lot of small transactions. The standard tactical responses to
the fact that bandwidth has grown without proportional drop in latency have
been aimed at utilizing bandwidth, i.e. transferring a lot of data. Email
postage validation wouldn't seem to me to benefit from such tactics as
parallelization of sliced-up tasks or deep acknowledgement queues, but maybe
  I'm just not seeing some insight.

> not true ten years ago...)

I think I'd quibble with details on that, but they really are not all that
important.

This is a problem that should be subject to a simplified thought experiment. 
If you make extremely unrealistic positive assumptions about processing, 
storage, and bandwidth but recognize that many RTT's between redemption 
clients and servers will be above 100ms, most above 10ms, and essentially 
all above 1ms, it is very hard to design a logical system (never mind a 
collection of hardware) that will handle a million redemption requests per 
second in a worthwhile manner (i.e. not repudiate valid tokens or validate 
bogus or redeemed ones by design) when the request stream is being 
engineered to break the system by parties with tens of thousands of hijacked 
machines at their disposal.

I'm pretty sure that I'm not the best systems analyst/designer on this list.
I certainly hope I'm not the best one to have thought about e-postage. I'd
be happy to learn from a master how it is in fact possible to make an 
ideally simplified minimal system like this work as a starting point for how 
to assemble a more complex system that has more elements of reality in it. I 
think (but may be wrong!) that it isn't possible to design a system that 
will be theoretically capable of correctly handling a million redemption 
requests per second of which ~90% are the result of someone working to break 
the system.

---

From: Steve Atkins <[email-masked]>
Date: Fri, 20 Feb 2009 16:26:32 -0800

On Feb 20, 2009, at 3:25 PM, Bill Cole wrote:
> This is a problem that should be subject to a simplified thought  
> experiment. If you make extremely unrealistic positive assumptions  
> about processing, storage, and bandwidth but recognize that many  
> RTT's between redemption clients and servers will be above 100ms,  
> most above 10ms, and essentially all above 1ms, it is very hard to  
> design a logical system (never mind a collection of hardware) that  
> will handle a million redemption requests per second in a worthwhile  
> manner (i.e. not repudiate valid tokens or validate bogus or  
> redeemed ones by design) when the request stream is being engineered  
> to break the system by parties with tens of thousands of hijacked  

There are many problems with epostage - fundamentals, social problems  
and implementation - but this particular aspect isn't one, I don't  
think. It's a trivially parallelizable problem.

The reliability (SPoF), economics, business and usability issues are  
likely to be much more of a problem.

> be happy to learn from a master how it is in fact possible to make  
> an ideally simplified minimal system like this work as a starting  
> point for how to assemble a more complex system that has more  
> elements of reality in it. I think (but may be wrong!) that it isn't  
> possible to design a system that will be theoretically capable of  
> correctly handling a million redemption requests per second of which  
> ~90% are the result of someone working to break the system.

It's fun to consider, though.

Using your numbers - one million redemption requests a second of which  
at least 90% are invalid, leads to 100,000 outstanding valid requests  
per second, which would give around 250 billion outstanding stamps at  
any one time, if we expire them after a month (expiring would likely  
involve voiding the unused stamps and issuing new ones in the same  
amount, but that's a business issue, and doesn't affect the redemption  
requirements).

Use private-key cryptography to ensure that you reject any stamp you  
didn't create. This is easy to do in hardware, or to parallelize  
should you need to. Pick enough machines or asics to meet your  
throughput goal. (That might well be one).

Hash the stamp to one of a number of redemption machines. This is  
"just" a network problem.

At each redemption machine, look up the stamp  an "I've seen this"  
associative array. If you've seen it, reject the stamp, otherwise  
accept it. This is arbitrarily scalable, just by adding enough  
redemption machines that the memory access time to look up the entry  
in the associative array is enough to meet your throughput goal, and  
the size of the number of outstanding stamps fits in the storage space  
of the machine. Assuming there's a serial number in each stamp, your  
associative array could simply be 250 gigabits of RAM, so again it's  
not going to be many machines, maybe one, to do in software.

To me it feels like the hard bit of this is handling a million packets  
in and out per second reliably, along with the overhead of providing  
robustness and redundancy, rather than the redemption itself.

Cheers,
   Steve

---

From: Bill Cole <[email-masked]>
Date: Sat, 21 Feb 2009 19:07:09 -0500

> On Feb 20, 2009, at 3:25 PM, Bill Cole wrote:
[Quoting John Leslie]
>> I think I'd quibble with details on that, but they really are not all 

I guess maybe one detail is...

If the processing delay for every redemption attempt is of the same order of 
magnitude as irreducible network latencies, i.e. tens to hundreds of 
milliseconds, handling a million one-use token redemption attempts per 
second is absolutely hopeless. I'm pretty sure that a large fraction of the 
attempts would be for already-redeemed tokens and that those could be 
handled extremely fast so that a validation server can handle such requests 
  in sub-millisecond times. I would hope that the requests which succeed 
could be done in sub-millisecond time as well, but that's less critical.

>> about processing, storage, and bandwidth but recognize that many RTT's 
>> between redemption clients and servers will be above 100ms, most above 
>> 10ms, and essentially all above 1ms, it is very hard to design a 
>> logical system (never mind a collection of hardware) that will handle 
>> a million redemption requests per second in a worthwhile manner (i.e. 
>> not repudiate valid tokens or validate bogus or redeemed ones by 
>> design) when the request stream is being engineered to break the 
>> system by parties with tens of thousands of hijacked machines at their 
>> disposal.
> 

If it's trivial, I'd welcome the public humiliation of being shown how, with 
specific reference to the problem that (for example) 50k clients on the 
other end of 100ms RTT connections may present the same token almost 
simultaneously, and exactly one can be be allowed to redeem it.

> likely to be much more of a problem.

Those are all problems. It seems to me that any attempt to seriously address 
the SPoF problem makes the race resolution problem harder.

>> ideally simplified minimal system like this work as a starting point 
>> for how to assemble a more complex system that has more elements of 
>> reality in it. I think (but may be wrong!) that it isn't possible to 
>> design a system that will be theoretically capable of correctly 
>> handling a million redemption requests per second of which ~90% are 
>> the result of someone working to break the system.
> 
> 
> didn't create. This is easy to do in hardware, or to parallelize should 
> you need to. Pick enough machines or asics to meet your throughput goal. 
> (That might well be one).
> 
> Hash the stamp to one of a number of redemption machines. This is "just" 
> a network problem.

I love the quotes...

That network problem risks adding latency to every transaction, particularly 
because at first glance it looks like an obvious place to address the 
large-scale SPoF problem by giving physical location diversity to your 
subunits. Unfortunately, if you make the back end really robust by putting 
redundant parts in widely dispersed places, every transaction gets a 
multi-millisecond minimum lifetime, which is a problem.

> associative array. If you've seen it, reject the stamp, otherwise accept 
> it. This is arbitrarily scalable, just by adding enough redemption 
> machines that the memory access time to look up the entry in the 
> associative array is enough to meet your throughput goal, and the size 
> of the number of outstanding stamps fits in the storage space of the 
> machine. Assuming there's a serial number in each stamp, your 
> associative array could simply be 250 gigabits of RAM, so again it's not 
> going to be many machines, maybe one, to do in software.

I think it is a bit of a hand-wave to call this arbitrarily scalable, but 
I'm happy to stipulate for the test of my hypothesis that the entire 
server-side decision process for any one redemption transaction can be 
reliably done correctly in uniform sub-millisecond time if the stamp is 
either available for redemption or already redeemed. The problem is that 
logically you need a third intermediate state that will last for the RTT of 
the network connection to the redeeming client, and that state will defer 
the decision for other attempts to redeem the stamp.

> robustness and redundancy, rather than the redemption itself.

That was my point, because it seems to me that a redemption cannot be done 
with just one packet in and one out, but really needs two in and one out.
A legitimate stamp needs to have 3 possible states in the server's map: 
redeemed, unredeemed, and pending acknowledgment of redemption. If the 
server only has two states for a stamp, then it would end up with one of two 
flaws by design:

1. If the stamp is marked as redeemed when a successful redemption attempt 
completes on the server, it is possible that the success will not be 
successfully communicated to the client. If the client then retries the 
redemption, it will fail.

2. If the stamp is left as unredeemed while waiting for the client ack of 
success, stamp "reuse" becomes a question of how many redemption decisions 
can be made per client RTT.

The server may have to defer many thousands of clients for scores of 
milliseconds while waiting for one to send an ack. Handling a few dozen such 
events per second seems to me to be a really hard problem to address, but 
maybe I'm missing something. If the average transaction lifetime is 100ms, 
then a million-TPS system needs to be able to handle an average of 100k 
concurrent pending transactions and spikes probably twice that. I think the 
ways to handle that all include dividing the front end between multiple 
machines, but that creates a tougher problem keeping the back end 
recordkeeping fast and coherent from the viewpoints all of the front ends.

I suspect that the "solution" that will be chosen if anyone tries to create 
a real e-postage system instead of hand-waving about it will be to open it 
to lost packet damage as the cost of scalability. Network latency with 
clients becomes irrelevant if the server assumes that its redemption 
messages are always delivered. That allows for a lot of optimization. Once 
in a while a stamp that should work will fail to do so, and if such a system 
ever gets into the real world I'm sure its users will be shocked at how much 
higher the real-world failures are than in their tests...

---

From: Steve Atkins <[email-masked]>
Date: Sat, 21 Feb 2009 18:02:50 -0800

On Feb 21, 2009, at 4:07 PM, Bill Cole wrote:

>> The reliability (SPoF), economics, business and usability issues  
>> are likely to be much more of a problem.
>
> Those are all problems. It seems to me that any attempt to seriously  
> address the SPoF problem makes the race resolution problem harder.

Almost by definition. If your definition of which of two redemption  
attempts is valid is the one that arrives at a particular place first,  
then that place is a single point of failure. If that's not your  
definition, things get a lot more complex.

>> redemption machines that the memory access time to look up the  
>> entry in the associative array is enough to meet your throughput  
>> goal, and the size of the number of outstanding stamps fits in the  
>> storage space of the machine. Assuming there's a serial number in  
>> each stamp, your associative array could simply be 250 gigabits of  
>> RAM, so again it's not going to be many machines, maybe one, to do  
>> in software.
>
> I think it is a bit of a hand-wave to call this arbitrarily  
> scalable, but I'm happy to stipulate for the test of my hypothesis  
> that the entire server-side decision process for any one redemption  
> transaction can be reliably done correctly in uniform sub- 
> millisecond time if the stamp is either available for redemption or  
> already redeemed. The problem is that logically you need a third  
> intermediate state that will last for the RTT of the network  
> connection to the redeeming client, and that state will defer the  
> decision for other attempts to redeem the stamp.
>
>
>> To me it feels like the hard bit of this is handling a million  
>> packets in and out per second reliably, along with the overhead of  
>> providing robustness and redundancy, rather than the redemption  
>> itself.
>
> That was my point, because it seems to me that a redemption cannot  
> be done with just one packet in and one out, but really needs two in  
> and one out.

One in and one out will do it. The client MTA can include a nonce or  
serial number in the request. The redemption machine can keep track of  
the nonce value of the request that was accepted as valid, at a cost  
of a few times the number of machines needed. We're already keeping  
that state for a month anyway.

If any client doesn't receive a response (positive or negative) after  
a while, it can retry with the same nonce and it will still get a  
correct answer. (While the system may well need to deal with malicious  
clients, it only needs to give correct results to non-malicious  
clients). This eliminates any need to keep state for anything  
resembling packet RTT time.

The similarities of this to DNS might just betray my background rather  
than being anything particularly meaningful.

> A legitimate stamp needs to have 3 possible states in the server's  
> map: redeemed, unredeemed, and pending acknowledgment of redemption.  
> If the server only has two states for a stamp, then it would end up  
> with one of two flaws by design:

Or "unredeemed" and "redeemed for nonce value X".

> 1. If the stamp is marked as redeemed when a successful redemption  
> attempt completes on the server, it is possible that the success  
> will not be successfully communicated to the client. If the client  
> then retries the redemption, it will fail.
>
> 2. If the stamp is left as unredeemed while waiting for the client  
> ack of success, stamp "reuse" becomes a question of how many  
> redemption decisions can be made per client RTT.
>
> milliseconds while waiting for one to send an ack. Handling a few  
> dozen such events per second seems to me to be a really hard problem  
> to address, but maybe I'm missing something. If the average  
> transaction lifetime is 100ms, then a million-TPS system needs to be  
> able to handle an average of 100k concurrent pending transactions  
> and spikes probably twice that. I think the ways to handle that all  
> include dividing the front end between multiple machines, but that  
> creates a tougher problem keeping the back end recordkeeping fast  
> and coherent from the viewpoints all of the front ends.
>
> I suspect that the "solution" that will be chosen if anyone tries to  
> create a real e-postage system instead of hand-waving about it will  
> be to open it to lost packet damage as the cost of scalability.  
> Network latency with clients becomes irrelevant if the server  
> assumes that its redemption messages are always delivered. That  
> allows for a lot of optimization. Once in a while a stamp that  
> should work will fail to do so, and if such a system ever gets into  
> the real world I'm sure its users will be shocked at how much higher  
> the real-world failures are than in their tests...

Don't forget that there is no state that needs to be kept or  
transferred other than that keyed on the stamp value itself. You can  
spread the load needed across as many systems as you need to keep up  
with demand. At an extreme, you can have the client MTAs use the  
cookie in the stamp to decide where to check the stamp, and spread  
load across multiple networks and locations - I check this stamp by  
sending a packet to whatever IP address <last 16 bits of  
cookie>.stampcheck.foo resolves to. (That's what I mean when I  
describe it as embarrassingly parallelizable.)

That might end up being expensive to operate, of course.

Cheers,
   Steve

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 22 Feb 2009 12:53:18 +0100

On 2009-02-21 19:07:09 -0500, Bill Cole wrote:
> If the processing delay for every redemption attempt is of the same order 
> of magnitude as irreducible network latencies, i.e. tens to hundreds of 
> second is absolutely hopeless.

I think John meant "processing delay" as seen from the client. So this
includes a) the time to send the request (tens to hundreds of
milliseconds), b) the time it takes the server to process the request
(sub-milliseconds?) and c) the time for the response to get back to the
client (again tens to hundreds of milliseconds). 

The number of requests a server can process per second is mostly
determined by b). The communication delays only increase the number of
open but idle connections (which may also be a problem).

So if checking a single token takes 1 millisecond (rather conservative,
IMHO), one server can check roughly 1000 tokens per second, so a server
farm of 1000 servers can check 1 million tokens per second. That doesn't
seem "absolutely hopeless" to me. It's certainly technically possible,
although I'm sceptical whether it's economically feasible.

> >amount, but that's a business issue, and doesn't affect the redemption 

I expect most tokens would be redeemed pretty soon, so you won't have
to keep them around for a month, at least not for real-time checking.

> server only has two states for a stamp, then it would end up with one of 
> two flaws by design:
> 

Yes, but is this a problem which needs to be avoided at all cost? If the
redemption fails, the client can simply buy another stamp and send the
message again. Delivery of that particular message was now twice as
expensive as that of an average message, but if that only happens
infrequently it doesn't matter. If it does happen frequently for a
particular bank, the affected client(s) will probably be reconfigured to
prefer tokens from other banks. 

So if your 50k clients try to redeem the same token at the same time,
one of these 50k requests will be the first to be processed by the
server. The server marks the token as redeemed and sends a positive
reply to the client. The other 49999 requests will be denied. If
(because of network congestion caused by the 50k nearly simultaneous
requests) the reply never reaches the "lucky" client, the token will be
lost. 

Sending 50k requests with the same token is garantueed to yield at most
one positive reply in this case. It isn't viable for someone who wants
to send many messages, but it may be a viable DoS attack.

> milliseconds while waiting for one to send an ack.

Yes, but it only needs to defer those clients which sent a request with
the same token. It can process lots of other tokens in the meantime. 

Also the server doesn't have to keep the connection open. If the token
it wants to check is currently in the "pending" state, it can reply with
a temporary error and leave it to the client to retry at a later time.

> I think the ways to handle that all include dividing the front end
> between multiple machines, but that creates a tougher problem keeping
> the back end recordkeeping fast and coherent from the viewpoints all
> of the front ends.

I think it is possible to solve the coherency problem by using the token
to choose the server. Then there is always exactly one server
responsible for a specific token and no coherency problem does occur.
The draft doesn't specify the protocol used to buy or redeem tokens, so
this could be done in the client: A token might consist of two parts,
the first one identifies the server to connect to, the second is unique
within that server.

> to lost packet damage as the cost of scalability.

Yes, that's what I'd probably do.

> Network latency with clients becomes irrelevant if the server assumes
> that its redemption messages are always delivered. That allows for a
> lot of optimization. Once in a while a stamp that should work will
> fail to do so, and if such a system ever gets into the real world I'm
> sure its users will be shocked at how much higher the real-world
> failures are than in their tests...

If you are still cheaper than the competition, that doesn't matter. If
you aren't, but already have sufficient market share (because you were
one of the first), it might not matter, either. Otherwise you're out of
business.

	hp

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [email-masked]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [email-masked]

---

From: Bill Cole <[email-masked]>
Date: Mon, 23 Feb 2009 00:59:10 -0500

> open but idle connections (which may also be a problem).

Just in case anyone misconstrues your use of the term "connections":

Using one TCP connection per transaction for a system that needs to complete 
  a million transactions per second across the Internet would be a 
ridiculous design flaw.

I therefore assume that you mean "connection" in a more generic sense, and 
indeed that was the core of my argument: if the server has to retain state 
on transactions for typical Internet RTT's for a common class of 
transaction, concurrency is likely to become a problem in and of itself.

> although I'm sceptical whether it's economically feasible.

Your hand waves so elegantly when forming the phrase "server farm of 1000 
servers."

I believe that dividing the workload between multiple front-end machines 
will either create unworkable latencies in the back end to assure that all 
of the front ends see a coherent state database for tokens or else will 
create vulnerabilities that will allow any significant botnet operator to 
effectively eliminate chunks of the system at will. Hand-waving a 1000-node 
server farm doesn't persuade me that I'm wrong.

> to keep them around for a month, at least not for real-time checking.

Someone who thinks e-postage is workable should make a real specification 
that defines "pretty soon" in concrete terms that would support an actual 
protocol design that expires tokens. That "someone" won't be me, and I 
expect that it won't be anyone else who has been asking for such a 
specification. E-postage has been at the hand-waving idea stage for over a 
decade, and it's becoming a bit comical.

> Yes, but is this a problem which needs to be avoided at all cost? 

I think so, but then I think the whole e-postage concept is a misguided 
fantasy in multiple aspects. If you think it could actually survive having 
random stamps made worthless and indicative of fraud by dropped packets, I 
urge you to implement it and demonstrate that people will tolerate such a 
system.

 > If the

There's not any strong reason for such a problem to be bank-specific. It 
could just as easily be tied to where the redemption attempt is coming from.

> to send many messages, but it may be a viable DoS attack.

Botnet spammers have a history of attacking anti-spam systems. Any mailing 
tactic capable of crippling an e-postage system, even temporarily, will be 
tried.

> the same token. It can process lots of other tokens in the meantime. 

If designed correctly, that might be the case. What is that design again?

Spammers will work to break any e-postage system. They will be the indirect 
sources of most of the redemption requests, so whatever inconvenient cases 
are possible can be expected to make up almost all of the request traffic.

> a temporary error and leave it to the client to retry at a later time.

Then the system is NOT handling that redemption attempt. The million-TPS 
scaling is based on the number of redemptions that have to be completed, not 
  tried. If trying a redemption once doesn't dispose of that token, you need 
to scale up to handle the retries.

This is a problem that is familiar to many MTA admins: if you defer clients, 
you increase how many client connections you get.

> the first one identifies the server to connect to, the second is unique

So, you have something embedded in the token that tells the MTA trying to 
redeem it which one of 1000 servers to contact for redemption, each one of 
which is capable of handling 1000 redemptions per second? With spammers 
controlling botnets of 100k machines? Is there a punch line?

If e-postage is ever going to be more than hand-waving about a concept, 
someone who is able to put in disciplined, serious system design work is 
going to need to be convinced that there's enough potential in e-postage to 
put together a redemption protocol that doesn't generate derisive giggling.

> Yes, that's what I'd probably do.

Why not actually do it?

> one of the first), it might not matter, either. Otherwise you're out of

Demonstrate that *anyone* will accept a new sort of currency designed to 
randomly be worthless based on the vagaries of Internet packet reception 
before making up stories about competitive providers of such magic scrip.

---

From: John Leslie <[email-masked]>
Date: Mon, 23 Feb 2009 07:18:43 -0500

Bill Cole <[email-masked]> wrote:
> 
> ... The problem is that logically you need a third intermediate state
> that will last for the RTT of the network connection to the redeeming
> client, and that state will defer the decision for other attempts to
> redeem the stamp.

   We're getting a fair ways from the POSTAGE spec into the BANKING
spec (not yet written), or actually beyond it, since it deals with
customer interface, not internals.

   However, while you're welcome to implement your "bank" that way,
I'd pretty strongly advise against even trying to maintain distributed
state. The state of the token can be simply "redeemed" whether the
presenting customer _ever_ learns about it.

   The customer really doesn't care about the state of the token. They
care whether their account has been credited the appropriate amount.
And they don't care about which microsecond that credit happens in --
they'd be happy waiting tens of seconds.

> server only has two states for a stamp, then it would end up with one
> of two flaws by design:
> 

   As it should, IMHO. It's just as abusive for the receiving SMTP
server to multiply redeem tokens as for the sending SMTP client to
send multiple copies of the same token.

   (Obviously, the customer interface with the bank should consider
how to work around communications failures; but a simple retry is a
particularly bad way to do so.)

>    redemption decisions can be made per client RTT.

   RTT, alas, is a variable. :^( An abusive customer could draw it out
way beyond reason.

> be to open it to lost packet damage as the cost of scalability.

   That is a business decision. (More exactly, to what extent the "bank"
tries to adjust for packet loss is a business decision.)

> that its redemption messages are always delivered.

   Yes, and it may be the case for many "banks" that standard TCP is
considered sufficiently "reliable".

> That allows for a lot of optimization. Once in a while a stamp that

   No doubt some will be...

---

From: John Levine <[email-masked]>
Date: 23 Feb 2009 13:58:21 -0000

>customer interface, not internals.

A fair point.  But I think it would be a good idea to write down what
the banking requirements would be, e.g., what sorts of transactions it
would have to handle, at what sorts of transaction rates, and what
kinds of attacks it is likely to have to withstand.

R's,
John

---

From: David Nicol <[email-masked]>
Date: Mon, 23 Feb 2009 16:38:33 -0600

On Mon, Feb 16, 2009 at 3:22 PM, John Levine <[email-masked]> wrote:

> entry transactions is worse than for bearer ones.

But bearer system cannot be done securely, implying book entry system
anyway, so let us hear no more on bearer systems.

> If you're doing

So what?

Imagine a coin minting/redemption protocol in which central
authorities issue book-entry tokens and associate them with value
which is transferrable.  The primitive operations available include

   mint  here is some value from my account into a coin account and
give me the coin.
   bite   here is a coin code, what if anything is it worth?
   melt  here is a coin code please transfer its value into my account

knowing a coin code implies a capability to melt it, but it can only
be melted once.
Scalability happens by creating as wide an array of mint operations as
is needed.

Minting/melting takes fewer read/write operations than delivering an
e-mail by several orders of magnitude, and even if a paid e-mail took
ten free e-mails to implement that would not be a problem.

The problems are political not technical.

So anyway in SMTP terms, toward e-postage drafts, I see senders,
spf-authenticated envelope return addresses (ERAs), so we can work
this all out prior to the DATA phase, using mint/melt to deliver value
in a form trusted by both the ERA and the recipient, to the receiving
MX, along with a concise statement of their payment policy.

There doesn't have to be any imposition or zero-day, just restriction
of access by the receivers of paid e-mail until senders adapt.

---

From: John Levine <[email-masked]>
Date: 23 Feb 2009 23:43:51 -0000

>anyway, so let us hear no more on bearer systems.

Huh?  Bearer systems are just as secure as book entry, but they have
different performance characteristics.

>> 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.

>So what?

locks -> bottlenecks -> slow.  It's a basic problem of any concurrent system.

>ten free e-mails to implement that would not be a problem.

This is a non-sequitur.  Delivering mail is inherently very parallel,
postage operations are not.  The whole point of postage is to apply
global limits to the number of messages that someone can send, which
means that all those parallel deliveries have to funnel requests to a
limited number of banks/postoffices/whatever to find out whether the
senders have any mail-fu left.

>The problems are political not technical.

They're political AND technical.

R's,
John

---

From: David Nicol <[email-masked]>
Date: Mon, 23 Feb 2009 18:02:28 -0600

On Mon, Feb 23, 2009 at 5:43 PM, John Levine <[email-masked]> wrote:

>  The whole point of postage is to apply

Now we're getting somewhere.  I see the whole point of postage as a
mechanism for the recipient to monetize their attention.  And since
there is money involved, suddenly substantially complex machine loads
can be afforded, as the transaction costs can be a small fraction of
the cost of someone's restricted attention.  The purchase of
additional mail-fu as required will be a cost borne by the senders,
who will aggregate it at various levels opportunisticly depending on
reality.  The first step is to have some recipients demand to be paid
for delivery to them.

An interesting proposal is
 http://wiki.qpsmtpd.org/plugins:spam:autowhitelist_captcha
although it has the obvious problem of being a c/r system rather than
issuing smtp rejection codes referring to an http address for the
authen piece.

---

From: John Levine <[email-masked]>
Date: 24 Feb 2009 01:00:14 -0000

>the cost of someone's restricted attention.

Well, OK.  How do you see this relating to the current mail system?
Do you expect a system where all mail is paid?  If not, how do you
decide what to accept for free?  How much do you expect advertisers to
pay for your attention?  (See goodmail and e-rewards for some current
examples.)

A draft explaining what your model is would be nice.  The existing
draft (I think) is more intending to use e-postage to limit mail
volume, not to pay end recipients.

R's,
John

---

From: der Mouse <[email-masked]>
Date: Tue, 24 Feb 2009 00:13:38 -0500 (EST)

> decide what to accept for free?

Surely the answer to that will be "it's up to the recipient ('s
postmaster)", just as most filtering decisions are now?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: John Levine <[email-masked]>
Date: 24 Feb 2009 19:11:55 -0000

>postmaster)", just as most filtering decisions are now?

Actually, I meant in a more technical sense.  There's a flood of mail
coming at you; how do you decide which ones to accept and which ones
to do the postage thing?

R's,
John

---

From: der Mouse <[email-masked]>
Date: Tue, 24 Feb 2009 14:37:04 -0500 (EST)

>>> [H]ow do you decide what to accept for free?

That's what I meant too: it'll be "whatever the relevant mail admin
decides to implement" - just like today's filtering.  Ideally, this
will bear at least some relation to what the end user wants, in most
cases, but that's no more necessarily so here than it is in today's
filtering decisions.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "Peter J. Holzer" <[email-masked]>
Date: Thu, 26 Feb 2009 00:16:09 +0100

On 2009-02-23 00:59:10 -0500, Bill Cole wrote:
> Using one TCP connection per transaction for a system that needs to 
> complete a million transactions per second across the Internet would be a 
> ridiculous design flaw.
> 
> I therefore assume that you mean "connection" in a more generic sense,

I was generally deliberately vague, but in this paragraph I actually
meant a TCP connection. I assume that many requests can be sent over the
same TCP connection (just as you can send many emails over a TCP
connection using SMTP, and many HTTP/1.1 requests can be sent over a TCP
connection). But many clients won't need to do that. For an MX for a
small personal domain it simply makes no sense to keep permanent TCP
connections to all banks, just because it might need to redeem a token
some time in the next hours. It would close the connection after a
single request unless it needs to redeem another token within a very
short time. For such single-request connections the minimum time is
determined by the RTT.

> and 
> on transactions for typical Internet RTT's

It doesn't, except at the TCP level - naturally, the kernel needs to
keep state for all open TCP connections. But the redeeming agent doesn't
nee

> for a common class of 

;-)

> Someone who thinks e-postage is workable

I don't think e-postage is workable. AFAICS an early adopter has no
advantages, but a lot of disadvantages. Therefore, e-postage won't
happen in the SMTP world.

> should make a real specification 
> protocol design that expires tokens.

As a purely academic exercise, here's a sketch of a protocol and a
server implementation. If anybody wants to run with it, feel free:

Protocol:

    Based on TCP. Simple request/response structure, Server and Client
    can close the close the connection at any time.

    A token consists of two parts, the first is a domain name, the
    second is opaque.

    The server for redeeming a given token can be found via a SRV
    lookup.

    Requests:

	redeem token account

	    the token is redeemed and the value is transferred to
	    account.

	    responses:

		redeemed (+ value)
		unknown token (possible reasons: forged or mangled
		    token, token has already been redeemed, ...)
		temporary error (possibly with an estimate when a retry
		    might make sense)

	mint account amount
	
	    Create a new token with given value and deduct the amount
	    from the account. (This needs some kind of authentication,
	    of course) There may be a variant which creates $n tokens at
	    once.

	    response

		new token
		insufficent funds
		account doesn't exist or client doesn't have access
		temporary error

Implementation of redemption server:

    Keep all valid tokens in memory. Multithreaded to take advantage of
    multi-core systems (but almost certainly not 1 thread per connection
    - because there will be lots (hundreds of thousands?) simultaneous
    TCP connections).

    When a redemption request is received, the look up the token in
    memory. If it isn't there, send an "unknown token" reply.
    Otherwise attempt to lock the token. If this fails, send a
    "temporary error" reply to the client.
    Otherwise write a "this token has been disabled, transfer $value
    $currency to $account" record to a journal, invalidate the token in
    memory and unlock it, and finally send a "redeemed" response to the 
    client.

    I think current PC hardware can easily handle several tenthousand
    requests per second. I'm less sure about the number of concurrent
    TCP connections and connection requests a modern OS can handle.

Redemption Client:

    If the client (=SMTP server) needs to redeem a token, it extracts
    the host name and does a SRV lookup to find the server. If it
    already has a TCP connection to that server, use that, otherwise
    open a new connection. A temporary failure can be passed on to the
    SMTP client.

Minting:

    Each server only mints tokens which it will redeem itself - this
    eliminates the need to distribute knowledge about the tokens, but
    may create an uneven load. Load balancing is left as an exercise for
    the reader.

> could just as easily be tied to where the redemption attempt is coming from.

If client C has a problem communicating with bank B1, but not with bank
B2, it doesn't matter whether it is the fault of B1 or of C. C will
prefer to use B2.

> tactic capable of crippling an e-postage system, even temporarily, will be 

Of course. But there is no system which is immune to DoS attacks, and I
think DoS attacks and double-spending are sufficiently different
problems that they should be considered separately.

> >>success, stamp "reuse" becomes a question of how many redemption 
> >>decisions can be made per client RTT.
> >>

See above for a few ideas. I won't do a more detailed specification for
two reasons:

1) As I mentioned above, I don't think e-postage has a market in the
   SMTP world, so I won't waste time to implement it, and I won't waste
   time thinking about details of something I don't plan to implement.

2) If I did change my mind and wanted to implement it, I wouldn't post 
   a detailed description to a public mailing list :-).

	hp

---

From: David Nicol <[email-masked]>
Date: Thu, 26 Feb 2009 19:49:14 -0600

>   a detailed description to a public mailing list :-).

yeah, that's had me discarding drafts a lot of late ;)

-- 
The vents emit burning methane thought to be of metamorphic origin,
which in ancient times were landmarks that sailors could navigate by,
and which today the custodian uses to brew tea.