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

[John Leslie <john at jlc.net>]

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

   Agreed.

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

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

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

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

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

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

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

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

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

   Some numbers, please...

--
John Leslie <john at jlc.net>