John Levine <johnl(_at_)taugh(_dot_)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(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg