ietf-asrg
[Top] [All Lists]

[Asrg] Re: "HashStamp" == hashcash? (Re: Stamping)

2003-03-23 22:48:46
On Sun, 23 Mar 2003 23:30:12 -0500, Kee Hinckley 
<nazgul(_at_)somewhere(_dot_)com> writes:

At 9:53 PM -0600 3/23/03, Scott A Crosby wrote:
 > Ah.  So unsolicited email needs CPU-generated stamps.  Solicited just
 needs a one-time random token.  Thanks, that makes sense.


Fundamentally what you are doing is saying that the pain of sending
only needs to happen once, and from then on you've given tokens that
represent a consent to communicate.  I certainly like it better than
the pure hash-cash/sender-pays solutions.  And as it represents less
up-front pain, it's more likely to be accepted.

Hashcash seems utterly ineffective if its anything less than
60ghz*seconds, and more likely 600ghz*seconds. Secondly, for
legitimate bulk-mail senders such as ASRG, that is too high a cost to
put on every message. It would also be nice to send mail to my mother
without burning 10 minutes of CPU. Ergo, if hashcash is to be used,
there *must* be a way to spread around 'cheap' tokens that let those
legitimate bulk senders escape.

For the most part, everything else is just tentative mechanisms to
make it possible to spread around such 'cheap' stamps.

Not that I think this mechanism is great, but I don't think many of
the others that I've heard about are all that practical or desirable
either.

That said, I don't see yet how it could get past the early-adopter
phase.  Like the other systems, it offers no real benefits until a
substantial number of people adopt it.

I can speculate one way. Remember, I haven't stated any policy as what
other means may be available to obtain stamps. I give two required
ways to obtain stamps, but others exist. For instance,
auto-reply-robots that do a two-way handshake or CAPTCHA website
challenges.

One could build this as a 'side' mechanism into a auto-reply robot
whitelisting mechanism similar to TMDA that IETF seperately
standardizes. The robot-replies sucks for older clients, but work. We
make the the stamp-missing control message machine-readible to make
conforming clients check for other valid stamps (or expend the CPU to
create a new stamp). They're also human-readible telling people to
reply to the robot and complete the handshake.

That way conforming clients are actually a benefit for
recipients. Either a sender is sending from a known-good address, or
they implement this protocol. They're also more convenient for
senders, a sender never sees those bounce messages
anymore. Eventually, in 5-10 years we depreciate the white-listing
robot and make all stamp-missing bounce messages only
machine-readible.

Conforming senders interoperate with old recievers, they just attach
some extra headers that get ignored.

Conforming receivers interoperate with old senders. During initial
deployment, they can whitelist based on completing a handshake by
replying to the stamp-missing-bounce-message. Or they can obtain nonce
stamps from a website, or an included CAPTCHA. There's no
authentication, but no worse than current by-sender whitelists.

Eventuallly most recievers will become conforming and the
stamp-missing bounce messages would not be shown to the users anymore;
clients would burn the CPU and resend automatically.

Conforming mailing list systems would keep track of whether a client
appeared to be running this system based on whether a stamp was
attached to the subscription request. Thus switching between a
non-conforming mailing list client and a conforming mailing list
client might cause one to lose list subscriptions, which isn't TOO
bad.

This might almost be the best case. If nothing happens. I can imagine
large ISP's doing the part of this (putting a auto-reply robot
whitelister), and then we'd never get the second half of the
protocol. IMHO, that'd be a horrible mess. We might as well try to use
such an auto-reply whitelister as a bootstrap mechanism to something
better.

The other interesting thing though, that just came to me, is that
there is a whole class of solutions (of which this is one) that change
the nature of email in an interesting way.  Currently email is not
really a protocol.  It's a one way communication.  (Bounces are the
exception that prove the rule.)  These solutions change email into
something that is actually a protocol.  The act of communicating, at
least initially, involves automated back and forth communication.  The
reason I find it interesting is that it introduces a whole new set of
failure modes you need to worry about. Network latency, bounce
messages, message-delayed messages, lost messages, vacation messages,
vacations themselves...  All of these things could have interesting
impacts on the system that we've never really had to think about
before.

Good point. 

It seems that almost any consent mechanism must make email become a
two-way system.

Scott

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg