- From: Cem Karan <Cem.Karan@usa.alcatel.com>
- Date: Mon, 30 Apr 2001 08:32:45 -0400
- To: Al Gilman <asgilman@iamdigex.net>
- CC: www-talk@w3.org
> 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