Re: hash cash and email

> AG::  No change in the installed plant is required at all.  The resulting
> action can be taken in your Mail User Agent as mail filtering on your personal
> node.  Those messages which are from a) a known good correspondent or b)
> someone who took the trouble to follow the protocol will get binned
> differently
> and read by you in preference to the others.

>> SNIP <<

> The overall point is that you will find it very, very, hard to get the
> Internet
> at large to agree to _reject_ a message for transport.  That would require a
> clear and compelling automatically discernable "open and notorious evil
> liver."  So don't try to get emessages blocked at the transport gate.  If you
> come up with a mail reading prefilter that is so effective that the
> preponderance of email readers use it, then the commercial users of email will
> conform to its requirements, and pay whatever it reasonably takes.

I see what you are saying, but I still prefer doing it at the transport
level.  The advantage is that it reduces the overall amount of traffic
on the internet.  I know that that doesn't seem like much as most of the
traffic is pure text, but I've been getting an increasing amount that
has HTML embedded in it, and I had one piece that had a movie file
embedded in it.  Although the message itself didn't have the movie in
it, if I had a HTML enabled email client as many clients are becoming
these days, I would have been stuck with the download.  This does use up
resources, at the very least on the end users connection which might be
quite slow.  I'm trying to come up with a solution that is relatively
easy to deploy that filters out the garbage without making
communications impossible.  Hash cash is a relatively easy modfication.
The broken key can be sent back as one of the xheaders of the message,
or as a mime entry.  Any server on the way back can look at it and
decide to drop it if it doesn't match (this is relatively quick; if it
just has the hash and the key, it just needs to check if the key matches
the hash) If it doesn't understand the hash cash idea, the server would
just send it on down the line.  Eventually it would get dropped by
someone.  

> There is some belief on the business side that email advertising is a proven
> success -- it is a going concern.  To change the rules of email transport, you
> will have to overcome opposition from the business community.

I know, and unfortunately, they won't adopt this idea as email
advertising is simply to convinient.  Hash cash will make it far less
so, which is directly counter to what they want.  The trick is to get
ISPs in on it.  I'm not sure how to do that.

> So implement whatever scheme you wish as an enhancement to the mail filtering
> that people already do on the client side, and you have a ready path to
> adoption.  Don't try to change the transport rules until you have an open and
> shut case.

While this is possible for the filtering end, there still needs to be a
mechanism for sending out the keys.  That mechanism most likely will
need to reside on a server of some sort, which means that the rest of
the service may as well be implemented as well; writing the programs are
relatively easy.  Its getting ISPs to accept it that is hard.

Received on Monday, 30 April 2001 08:33:34 UTC