John Levine <johnl(_at_)taugh(_dot_)com> wrote:
Date: 12 Feb 2009 02:44:51 -0000
From: John Levine <johnl(_at_)taugh(_dot_)com>
To: asrg(_at_)irtf(_dot_)org
Cc:
Subject: Re: [Asrg] About that e-postage draft [POSTAGE]
"Banks" would be compensated by debiting a customer account more
than the amount of ePostage issued and/or crediting a customer
account less than the amount redeemed. Or, perhaps there would be a
per-transaction fee (in the thousandths of cents, presumably). I
see no role for IETF in saying which model a "bank" uses.
So "thousandths of cents" doesn't seem realistic language when
discussing a per-transaction fee.
I did a similar calculation for my white paper, and even a penny a
message isn't enough, particularly if you have to budget for large
numbers of spams with fake or duplicate postage that will require most
of the work of verifying a real stamp, but provide no revenue.
By "per transaction", I meant per _transaction_, not per _email_.
(Is it possible we're not discussing the POSTAGE draft? It doesn't
contain "stamps" that are carried in message headers, but a "token"
passed between MTAs.)
A receiving MTA asking its "bank" to redeem a token is a transaction
whether or not the token is forged, and the "bank" needs to recover
that transaction cost. I suspect sending MTAs that deliver bad tokens
will get blacklisted quickly; but I can imagine ways to reduce the
need for a "transaction" with the bank to verify that a token is
plausible.
(Need I remind our readers that receiving email _already_ provides
no revenue?)
I hear that a lot of research involves models. Perhaps a model of
where the money will have to go would be useful.
Hmm...
I can imagine many models.
Clearly, in almost any model, "banks" will have to cover transaction
costs, and receiving MTAs will want to recover costs of transmission
(including support costs).
I expect most receiving MTAs will also want to cover POSTAGE for
their normal volume of outgoing email. (Charging end-users for
POSTAGE will only be practical for users with a large volume of
outgoing email.)
But I wouldn't preclude some portion of the POSTAGE being credited
to the end-users -- I just don't expect that to be workable.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg