A receiving MTA asking its "bank" to redeem a token is a
transaction whether or not the token is forged, and the "bank" needs
to recover that transaction cost. I suspect sending MTAs that
deliver bad tokens will get blacklisted quickly; but I can imagine
ways to reduce the need for a "transaction" with the bank to verify
that a token is plausible.
My standard spam model is that the bad guy buys one stamp and uses
that one genuine stamp on a thousand messages (transactions, whatever)
at the same time. It's really easy to verify that a stamp is real
using digital signatures, but there's no way to tell if it's already
been used other than asking the issuer.
It is possible to defend against this threat, but not cheaply, since
the defense requires a robust transaction system that can serialize
the thousand requests, approve one, and reject the other 999, while
still providing service to the rest of their customers. Through the
magic of botnets, the thousand messages come from a thousand different
MTAs, of course.
(Need I remind our readers that receiving email _already_ provides
no revenue?)
Indeed, but banks don't work for free. (Well, not deliberately.) You
want someone to provide stamps, you've got to make it worth his while.
I can imagine many models. ...
Indeed. Now beef some of them up with some realistic estimates of
transactions costs, and the costs of dealing with screwed up and
fraudulent transactions.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg