ietf-asrg
[Top] [All Lists]

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

2008-11-20 09:59:45
On Thu, Nov 20, 2008 at 1:51 AM, Bart Schaefer 
<schaefer(_at_)brasslantern(_dot_)com>wrote:

On Nov 19,  2:50pm, Gerald Klaas wrote:
}
} Personally, I believe that there should be a standard method for
} deriving a URL from e-mail addresses. That stamp generators should
} be placed at the derived URL

We've come at this from the point of view of creating an economy.
It doesn't have to be a cash economy, although I think that would
be best if the goal is to translate it into meatspace gains and
losses that might grab the attention of the losers or of law
enforcement, but it has to be something measureable.


Correct.


What's the
economic incentive for the recipients to expend the resources
necessary to generate a stamp for anyone who asks for one?


Better control of their incoming mail stream.


If the recipient makes some kind of decision as to who is allowed
to ask for stamps, he might as well simply apply those same rules
to SMTP connections and not worry about the stamps.


Except that SMTP is a store and forward system.  An out-of-SMTP-band
stamp negotiation can make decisions based on the originator rather than
what a header claims is the originator.


 I suppose one
could be a little more magnanimous in allowing connections to the
stamp generator because of an expected payment, but the recipient
still has to recoup his costs.


The recoup of costs is a savings from the cost of the current way of
dealing with SPAM.  There may be a micropayment revenue stream
created within such a framework, but as you pointed out above,
it's not necessary .



If the incentive is that recipient is to be paid before generating
the stamp, then there has to be a standard way of paying, or you're
back to the N*M problem.  If this is a cash micropayment, then why
not have the known standard payment vendors issue the stamps?


Promise of payment is probably not the motivator, promise of keeping
interlopers out of your inbox is.  Indeed, I would expect that existing
payment vendors would find some creative way to use such a
framework (if one existed) to allow their customers to leverage their
"new" ePostage system.   (And abate the N*M problem.)


 Each
recipient who wants to participate is already going to need to have
a relationship with a vendor (or a proxy for such a relationship), so
the stamp can still be tailored to be single-use for that recipient.
A stamp is nothing more than proof of payment, after all.


Yes, a stamp is proof of payment, but that "payment" isn't necessarily
cash.  It may be proof of passing through various checks, such as
having established a connection to a stamp-generator (and leaving your
real IP address behind in the logs).


That's the Goodmail model, isn't it?  With the substitution of some
known and advertised set of vendors so that recipients and senders
can negotiate on who handles the transaction and whether to require
a payment transaction in the first place.  I'm sure Goodmail has
some attorneys who'd love to have discussions with other potential
vendors about licensing the patents.


It's similar to the Goodmail process in the way that "stamped" or in
Goodmail's terms "certified" mail bypasses other filters.  It's not like
Goodmail in the sense that it doesn't require anyone to use a particular
stamp generator.   I could envision small ISP's running their own
generator as a PHP script on their website.  Since it's their stamp,
no one else should care how "strong" the stamp is.


Regardless, is whether Goodmail is successful a valid test of this
theoretical economy?  (Except nobody uses lack of Goodmail as a full
delivery block, and everyone has sworn that they won't do so.)


I don't believe that Goodmail is a valid test.  It is, after all, a closed
system.
What I'm suggesting is discussion of a standard way of requesting and
applying a "stamp".



OK, suppose it's not a cash payment.  "Payment" in the form of the
sender's computing resources has already been tried ("hashcash") and
not worked out so well.  Suggest something else?


Hashcash was never widely adopted and didn't require real-time TCP
connection to a receiver's host (that could be tested and logged).

Gerald
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg