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

[John Leslie <john at jlc.net>]

John Levine <johnl at taugh.com> wrote:
> Date: 12 Feb 2009 02:44:51 -0000
> From: John Levine <johnl at taugh.com>
> To: asrg at irtf.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.net>