ietf-asrg
[Top] [All Lists]

Re: [Asrg] Email Postage (was Re: FeedBack loops)

2008-11-19 19:46:36
On Tue, Nov 18, 2008 at 3:32 AM, John Levine <asrg(_at_)johnlevine(_dot_)com> 
wrote:

You're suggesting that each sender has to negotiate with each recipient
before it can send mail?  Man, if there's a faster way to kill e-mail,
I don't know what it is.

Yes, that is what I'm suggesting.  But since it's up to the recipient to
determine if they want to enforce it, I don't see how it would "kill
e-mail".  So what I'm really suggesting is that there should be a standard
for the exchange of "stamps", but not the algorithms required to frank or
verify stamps.

Such a standard method would allow senders to determine if a recipient
requires a stamp, and if so, how to obtain one, and would include a standard
method for packaging a stamp into a message.

In practice, it would be totally up to a recipient whether they insist on a
"stamp".  It would also be totally up to the recipient to determine how they
will verify stamps.



overhead.  The recipient would need to balance their risk of accepting
duplicate cookies with the amount of resource they wanted to dedicate to
generating unbreakable cookies.

The issue isn't counterfeit stamps, it's real stamps being used more
than once.  The only way we know to prevent double spending is to have
a bank that remembers which ones have been spent and cancels them in
real time as requests come in.  That turns out to be an extremely
difficult database problem, high speed consistent updates.  We have to
assume that spammers will be as hostile as possible, so they'd buy a
hundred stamps, than mailbomb you with a hundred thousand messages,
each of which had one of the hundred genuine stamps.


Yes, preventing "double spending" or "duplicate cookies" is a difficult
problem, but I don't see that it is necessarily a giant database problem, or
that a single solution is required for all recipients. Certainly, if the
algorithms for franking and verifying "stamps" are left to the
implementation, there will be some that are formulaic and do not require a
database at all.

I believe we should talk about a very limited standard method for how stamps
might be exchanged, i.e., how does a sender know that a recipient requires
one?  How is one acquired?  How is one attached to a message?  Then let the
franking and verification routines and algorithms evolve within specific
implementations.  If a sender knows that a recipient requires a stamp and
knows how to get one and how to attach it to a message, there's no reason
they need to know how the recipient generated the stamp or is planning to
validate it.  The recipient can choose any generation/verification algorithm
that works for them, complete with all the risks and rewards of balancing
their level of effort against the algorithm's effectiveness.

True, a giant database might be the approach most effective at preventing
duplicate spending, but it is certainly not the only approach to generating
and verifying "stamps".  Some recipients might decide to use time-dependent
stamps, or sequence dependent stamps, or stamps based on an elliptic
formula, etc.  If the standard is only about the *exchange* of stamps, then
recipients get to evaluate the cost and benefits of whatever
generation/verification implementation they choose and change it over time
to find the cost/benefit balance that works for them.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg