At 12:59 AM 12/13/97 GMT, Adam Back wrote:

(Hashcash is a way of proving that the sender has consumed a tunable amount of CPU time. The verification process consumes negligible CPU time. This allows us to require the would be spammer to spend say 20 seconds per mail, which will slow him down considerably, over his current tactics of 1000 long Bcc lists allowing him to hand off spamming tasks to mail servers.)

So a remailer, such as Cracker, that might send out an average of 3,000 emails per day would be required to use up 3,000 * 20 secs = 17 hours of cpu time per day. Since a portion of these emails are to multiple recipients, then let's add 1/3 extra hashcash CPU time, or a total of about 22 hours of CPU time per day. Now since Cracker runs on old, antiquated equipment, easily two or more years out of date, I think we need to double this figure. (The Cracker CPU is actually less than 1/4 of the speed of many up to date desktop machines.) So, we would need about 44 hours of CPU time each day. Of course the Cracker mail system also runs various mail lists for EFGA. So we will need hashcash for these messages as well. If I wish to send out a personal email to each of say 900 nyms, then I will have to generate 900 * 20 seconds, or 5 hours of hashcash time in order to send an individual message to each nym. I certainly can setup myself as a privileged user on the Cracker SMTP port and bypass this requirement, but I'll need the hashcash for the unknown destination address of final delivery. Of course, since we might be able to delete the need for hashcash among people who know each other, we could have Cracker build a database of people who like to have privacy, and not have to generate the hashcash if we find you in our files. ISP's in general could handle the hashcash generation at the SMTP level by keeping databases of who sends email to whom. It is of course far easier to do a single database lookup than to generate the 20 seconds of hashcash. I don't know. I just don't understand the plan fully. I'll have to think about it some more. -- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key

On 12 Dec 1997 22:44:29 -0600, Adam Back wrote:

I am looking at writing some hashcash (http://www.dcs.ex.ac.uk/~aba/hashcash/) based spam prevention software. The motivation for writing spam prevention software is that spam is better combatted with technical methods than legal or political (we do not want clueless politicians coming in ham-fisted and requiring "Internet Drivers Licenses" or anti-spam legislation or anything else, such actions will be hazardous for the future of remailers, in my opinion).

I fear such draconian measures are inevitable as long as the "lobbying" group CAUCE is around. They actively discourage the adoption of technical solutions; favoring legislation. And since CAUCE was formed by "Net people", it will be seen (and spun in the press) as though we actually welcome such legislation. [... explaination of hashcash spam prevention deleted...]

The Right Way to do it perhaps is as an SMTP extension, however I consider this impractical in the short term because as far as I know there is no SMTP extension plug-in mechanism (other than access to the source code, and lots of development time) and because there are a large number of mail servers in use, and it will be expensive in developer (that's me) time to provide patches for them all (exarcebated by the fact that in many cases source will not be available).

How does PGP do it with their policy enforcer?

So these problems leave us scratching around for other more generic approaches. One method is to create a proxy which receives mail on port 25 (as the SMTP server normally does) filters examining for correct hashcash postage, and bounces if the postage is missing, and forwards the mail on to the real SMTP server if the hashcash postage is valid. The real SMTP server would then be set to run on another port... say port 26 which is reserved, and have the mail forwarded to it at that port. (You would want to disable non-local access to port 26 either at firewall or with SMTP server configuration if that is possible).

Alternatively run the real SMTP server on another machine inside the local network.

A few problems with this approach, firstly it may not be possible to configure some SMTP server software to run at ports other than 25. (I know you can do it with sendmail: OOPort=26 does it.) (If this is not possible with a given SMTP server you can still run a proxy by running the real SMTP server on another machine inside the network).

Secondly the proxy approach prevents some of the SMTP server functions from operating properly because the process on the other end of the socket is our hashcash proxy on localhost rather than the remote mail hub (modern sendmails can be configured to perform reverse name lookups on IP addresses, call ident (ident sucks anyway IMO), or block based on IP address or domain, etc.) Is this kind of thing likely to be a big problem?

I don't see why. Just have the proxy work both ways. Isn't it possible for the proxy to keep track of which message came from which address and relay server requests back to the right user? (I'm not familiary with how sendmail works, so I'm probably missing something)

This still leaves open the question of the user generating their own hashcash postage. Again this could be problematic for neophytes. One solution is to include a URL for a web page including a javascript hashcash generator -- this means that no new software must be installed, the user cut and pastes the generated hashcash into their message.

How many of the popular email pacakges have support for plug-ins? Netscape Communicator is the only package (that neophytes will use) I know of that doesn't support email plugins. Perhaps in this case a small proxy could be installed on the user's machine. The only thing it would have to do is generate hashcash for outgoing messages.

However things would be a whole lot simpler short term if the mail originators ISP created the hashcash for him at the ISPs SMTP hub where the user hands off his mail for further delivery.

The main problem with this is that the SMTP mail hub would be overloaded by the CPU intensive task of generating hashcash.

There are a few techniques to reduce the overhead of preventing spam with hashcash. One is to require valid hashcash only on the first message to a given address. (Spammers being hit and run types, and even having to generate hashcash for each spamee once would be expensive for a spam list of 10 million unwilling spam recipients). Better, is to require valid hashcash on all mail, _until_ the recipient replies to a mail. This is good because people rarely reply to spammers.

Ordinary users who chit-chat backwards and forwards in mail generate little added overhead for the hand off SMTP server -- the only overhead being to generate say 5 seconds CPU worth of hashcash for each new recipient the user sends to.

Then you add some hashcash accounting so that users who overspend (consuming more than say 1 minutes CPU consumption on the server in a 24 hour period have their email bounced with explanation of how to generate their own hashcash as a heavy user).

Figures would need tuning to see how they worked out in practice, however it seems that it would be feasible to handle the whole operation entirely at the sending and receiving SMTP servers.

What's the difference between this and simply keeping track of how many messages each user sends in a 24 hour period and blocking people who are obviously spamming? -- Phelix

Bill Frantz writes:

At 4:59 PM -0800 12/12/97, Adam Back wrote:

...

I am looking at writing some hashcash ... Neatly worked out scheme deleted ...

I think there needs to be a story for mailing lists. It might be acceptable for the first pass to allow spamming of mailing lists but not of individuals email addresses. (Apologies in advance to list moderators.)

Yes, I think this is a reasonable first pass. Naturally as you suggest the foiled spammer will then target mailing lists and newsgroups. I tend to view this as less of a problem because these forums are already noisy and tend to require filtering, or manual filtering by skimming for posters you recognize anyway. Also I understand collaborative ratings schemes like NoCeM can be configured to work for mailing lists. For people who don't want to install new software (and that is most people in my experience, myself included) can use filtering services. For example if spam became a problem on cypherpunks it would be easy for someone to set up yet another filtered cypherpunks list which promised to filter purely on the commercial spam criteria. The reputation of the available filtering services, and the paranoia of various list members would ensure that any untoward filtering would be called into question. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0

-----BEGIN PGP SIGNED MESSAGE----- The Net teaches even old dogs new tricks. From the Laissez Faire Books catalog: http://www.lfb.org/investment.html#iv7644 ***************** James Davidson and William Ress-Mogg THE SOVEREIGN INDIVIDUAL How to Survive and Thrive During the Collapse of the Welfare State by James Dale Davidson and Lord William Rees-Mogg In their newest work, the authors of Blood in the Streets and The Great Reckoning predict increased autonomy for the individual as information technologies advance and old institutions crumble—including the welfare state itself. Along with an array of provocative predictions (government will declare war on groups that try to circumvent income tax through cyberspace; central banks will lose control over the money supply as cybercash supplants paper money; the U.S. government will shrink) Rees-Mogg and Davidson offer investment advice and strategies for coping. ***************** -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBNJKcjIVO4r4sgSPhAQHLQwQAlBdYuWWoA/Q3Y6xkM1vT3iMm0HMCAuBS HYCu5NaRUfslMdbjvgqHAnc8SV+AX7fXVSfgCZ6nVtchnubgKaO22RcMlKWu423i dQrBvP0ZBK+fbWaFjZVvVVS4uZcHrUniUNj/u57Px9OmzK09zXXfJqdBuvwfm8ta X8br0rsIz48= =0opA -----END PGP SIGNATURE-----

I disagree that the best way to implement hashcash is solely via the SMTP mechanism. Almost any efficient hashcash mechanism will require some sort of history file, or "invited list," to allow mail lists and those we have corresponded with to continue to do so w/i having to supply hashcash each time. This list contains information which might have privacy implications and so should not be stored at the ISP, which can be forced to reveal such info w/o the knowledge of the client. If 'open' list policies were changed so that anyone could post if they supplied enough hashcash for each mailing list recipient for their first 1 or 2 posts, and thereafter no longer needed to supply hashcash (sort of minimum reputation capital), it might eliminate hit-and-run or throw-away account SPAMers without offering too high a hurdle to new or infrequent posters. Since most popular email clients allow plug-ins (e.g. Eudora) or extensions via Java/ActiveX, providing hashcash functionality via a plug-in and the java generators you propose would provide a simple mechanism to test its effectiveness w/o needing to involve the IETF. The shortcoming of a plug-in approach is that few newbies will know of it or install it and will therefore have to wait till its built into the new release of whatever client they use or until some or all of the features are supplied by their ISP, allowing those calling regulation to continue to blow their horns. However, if after a successful cypherpunk beta we could get the major email client companies (Netscape, M$ and Qualcomm) to include our plug-ins with all their new updates and offer them for free download from their Web sites, it could quickly steal the CAUCE folk's thunder. --Steve

...

So, we would need about 44 hours of CPU time each day.

Well, have a system of certified remailers trusted to force their users to burn up time at the sending end, so the ultimate recipient accepts their messages w/o postage. One certified remailer accepts messages from others without any postage, so only the original sender has to use up CPU time.

-- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key

--------------------------------------------------------------------------- Randall Farmer rfarmer@hiwaay.net http://hiwaay.net/~rfarmer

Randall Farmer masquerading as Joe writes:

...

What's the difference between this and simply keeping track of how many messages each user sends in a 24 hour period and blocking people who are obviously spamming?

Spammers don't have to appear to be the same person every time, nor do their messages have to be identical or even similar, so blocking of that kind can be worked around fairly easily -- at least more easily than hashcash.

I think Phelix was probably viewing it from the point of view if "what if all ISPs turned off non subscriber mail forwarding at their SMTP hubs"? Well that would work clearly enough. However I think there are a number of technical problems to acheiving this. Firstly SMTP does not include authentication. Secondly doing so reduces flexibility and many users use multiple ISPs, forward their mail to various places, etc., and this kind of stuff gets in the way. Really we I think should be discouraging the control freak "positive identification to use this port" syndrome such as the ident fuck up, (Ident is a dumb method of identifying who is on the other end of a socket on a unix box. It opens up a socket to the ident port on the originating machine, and asks who is on socket x port y? The machine can determine this from local OS tables, and sends the info back. This works if the user does not have root on the machine. Fortunately this snoopy bastardised protocol is not doing so well these days because there are more and more people who have root on their own machines, and because there are so many windows machines which don't know what a protected port number is. This is good because Ident sucks.) and moving instead towards, "who cares you are so long as you can't overload my machine". Moving longer term towards "who cares who you are so long as I profit from your connecting to this port" aka charge for port access with payer and payee anonymous ecash. Then everyone is welcome to use anywhere as a mail forwarding service -- spam becomes welcomed, and encouraged, too much custom and too low bandwidth discouraging customers, the ISP will use the profits to purchase a few more T3s. Hashcash is the interim solution. In the interim it is a fact of life that there are many many open SMTP forwarding hubs. The lack of software to configure them otherwise, and inertia will ensure things remaing this way for some time. Hashcash cuts out spam to your site (if you are an ISP), or to your mailbox (if you are a user) even in an environment of an almost unlimited supply of open SMTP hubs, and disposable ISP accounts, because it puts the onus on the sender to consume more resources than you. Authenticated the hell out of your ISP's SMTP as a forwarding hub won't prevent your users getting spammed to death, nor will it reduce the overall spam problem much because the spammers will just use one of the other open SMTP servers. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0

Steve Schear writes:

I disagree that the best way to implement hashcash is solely via the SMTP mechanism.

It is nicest to implement the blocking at the SMTP agent if this can be done in a privacy preserving manner, because it reduces the bandwidth consumption for users, and reduces the complexity of their local software -- they only need to generate hashcash for outgoing mail.

Almost any efficient hashcash mechanism will require some sort of history file, or "invited list," to allow mail lists and those we have corresponded with to continue to do so w/i having to supply hashcash each time. This list contains information which might have privacy implications and so should not be stored at the ISP, which can be forced to reveal such info w/o the knowledge of the client.

See my post to Bill Stewart with Subject: supeona immune postage free list I think you can construct ways to allow the ISP to reject messages without postage, and to allow frequent users to be exempt, and to do this such that there is no invited list which becomes a juicy target.

If 'open' list policies were changed so that anyone could post if they supplied enough hashcash for each mailing list recipient for their first 1 or 2 posts, and thereafter no longer needed to supply hashcash (sort of minimum reputation capital), it might eliminate hit-and-run or throw-away account SPAMers without offering too high a hurdle to new or infrequent pos ters.

That is an interesting thought. Well the interesting thought is that it gives us a way to block spam at the list server, because a) the spammer has to overcome the hurdle you described, and b) the list operator could punish spammers who started spamming once getting over the hurdle by blocking them. The usual trick of switching to a different address, or a remailer would not work because they would still have to generate a new hashcash coin as the list operator could block the coin. I would however think that a large denomiation coin made out to the list server would make more sense than generating lots of coins for all of the list subscribers. However there is a nasty side to the above, in that it encourages the list operator to censor posts he considers spam. It would be simpler and I think tend to less encourage censorship to introduce a third party filtering service such as Ray Arachellian's, and the other one, which had an option to have only spam filtered out. At this moment in time the spam content on mailing lists I am on is very low. I get much more in email. Doubtless this would change when spammers discovered that email spam is too CPU expensive to use. Also hashcash really doesn't work well for USENET. NoCeM's are cool things for USENET, a distributed ratings system, and I understand can be configured to work for mailing lists also.

Since most popular email clients allow plug-ins (e.g. Eudora) or extensions via Java/ActiveX, providing hashcash functionality via a plug-in and the java generators you propose would provide a simple mechanism to test its effectiveness w/o needing to involve the IETF.

You can do a lot with local SMTP and POP3 proxies. There are a couple of java ones around. Anyone know if there is code available to do SMTP and POP3 proxying? I am told by one subscriber to look at TIS firewall toolkits imap program.

The shortcoming of a plug-in approach is that few newbies will know of it or install it and will therefore have to wait till its built into the new release of whatever client they use or until some or all of the features are supplied by their ISP,

Yes, this problem is the motivation for trying to work out ways that as much as possible could happen at the ISP side for less technical users, and even for technical users, I know few people are interested to install new software. Also ISPs often seem more concerned about spam abuse than users.

allowing those calling regulation to continue to blow their horns. However, if after a successful cypherpunk beta we could get the major email client companies (Netscape, M$ and Qualcomm) to include our plug-ins with all their new updates and offer them for free download from their Web sites, it could quickly steal the CAUCE folk's thunder.

It would be cool if we could pull that one off. Do we have anyone on list who is familiar with eurdora, qualcomm and netscape plugins who would like to interface a hashcash library to these systems? Anyone who can write java applets want to implement a java hashcash library? (Should be easy.. jdk1.1.3 includes a sha1 function ... I am not sure if this is included with netscape 4 or not, but there are also numerous sha1 native java codes around, www.systemics.com being one). Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0

...

...

So, we would need about 44 hours of CPU time each day.

Well, have a system of certified remailers trusted to force their users to burn up time at the sending end, so the ultimate recipient accepts their messages w/o postage. One certified remailer accepts messages from others without any postage, so only the original sender has to use up CPU time. ... Since we need hashcash now to LEAVE a remailer, not to enter one, where does this hashcash come from? A busy remailer could not generate it's own hashcash for the destination non-remailer ISPs.

This is exactly what I was addressing: remailers only have to get themselves certified as remailers and then prove their certification to the destination server, not do the whole hashcash shtick for every message. (For example, they could publish their public key's hash signed by some anti-spam organization, then sign the hash of the server's challenge to prove that they are a real remailer, not an advanced spammer imitating one)

Does the same hashcash that allows a message to enter the remailer network also retain it's validity once the message has been rewritten by the remailer? Is this hashcash still valid for the destination mail server at netcom? Does the initial sender provide two instances of hashcash, one to get into the remailer, and one to get into the destination mail system?

Nope. The original sender provides hashcash to get into the remailer net, and the receiver, after seeing the remailer's certificate, trusts that the original sender spent some CPU time to send the message. The remailer doesn't have to while away nearly as much of *its* CPU time, and spammers still couldn't send many messages since they still have to waste their CPU cycles to do so. ...

-- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key

--------------------------------------------------------------------------- Randall Farmer rfarmer@hiwaay.net http://hiwaay.net/~rfarmer

At 11:48 PM 12/13/97 GMT, Adam Back wrote:

However, generally I have been assuming that it's easier to have a double spend database, and to make the hashcash depend only on the resource name for the kinds of problems you raise, and because it is cheaper to verify hashcash on shorter strings. By resource name I mean whatever it is that is being used. For an email address it is the email address, for a remailer it is the remailers address. Could be generalised for other purposes, for example free use of web based resources or even telnet based TCP/IP protocols in general.

As a technological fix for spam, destination address hashcash seems to be lacking. All this does is raise the wall of entry into becoming a spamhause from one PC to say, ten. It is not much more difficult to sell a CD-ROM with one million email addresses & hashcash. A 20 second hashcash expenditure on one million email addresses will take about 231 CPU days, or about three weeks if you use ten machines. Sell 500 copies of the CD-ROM for $500, and you net $250K, easily enough profit to purchase the $20K of machines or even to rent them for one month. After six months, you will have around eight million pieces of hashcash from the computational power of only ten machines. This says nothing of the profits from actually sending spam. The implementation of the plan is a more or less impossible scheme. Many people like myself exist who do not care from spam, but wish to receive email from anyone who legitimately sends it. I can only see a hashcash anti-spam plan working when you have a closed list of people who generally know each other. While the mail gateway I use could easily be converted to a hashcash enabled gateway, I have no interest in refusing email from those who do not have hashcash gateways. To be an anti-spam measure for ISPs, hashcash would have to be based on the destination email address, the text of the message in some fashion, and possibly on other factors such as a timestamp or a from address. Hashcash tied to a from address as well as the destination would do a lot for spam filters. Using all or a portion of the message body, say every 23 characters in a round robin fashion until 50 sample body message characters had been collected would make hashcash non reusable and not sellable. Any ISP hashcash plan still does not take into account the effect of services like hotmail, rocketmail, and the like who will need to generate hashcash for the destination address because they exist to shield the destination address from the sender. Changes to the "Don't charge postage" database will be awkward. There are some serious privacy problems with warehousing with your ISP a list of your other email addresses, or the addresses of your postage free friends. -- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key

This is exactly what I was addressing: remailers only have to get themselves certified as remailers and then prove their certification to the destination server, not do the whole hashcash shtick for every message. (For example,

At 06:53 PM 12/13/97 -0600, Uhh...this is Joe [Randall Farmer] wrote: they

could publish their public key's hash signed by some anti-spam organization, then sign the hash of the server's challenge to prove that they are a real remailer, not an advanced spammer imitating one)

I find this concept to have problems. I don't know how many there are, but with 4,000+ US ISPs, all of the schools, corporations, etc, there must be at least 50,000 mailhosts that would have to accept authentication. This whitelist concept, that if I am "good" I get approved and certified smacks of things which I generally oppose. And who keeps the whitelist? CAUCE? Verisign? Time Magazine? The NSA? Microsoft? How much would it cost for each of the 50K mail hosts to become certified? This is an administrative nightmare. The current alternative to this certification list is the configuration files such as domains.banned, user.banned, etc. Currently remailers can send mail most anywhere. I suspect that if remailers had to get certified (say a RASCi rating of "remailer") most mail hosts would begin denying mail from remailers. I don't believe that mail servers need to be certified. -- Robert Costner Phone: (770) 512-8746 Electronic Frontiers Georgia mailto:pooh@efga.org http://www.efga.org/ run PGP 5.0 for my public key

On Sat, 13 Dec 1997, Adam Back wrote: [...]

(Hashcash is a way of proving that the sender has consumed a tunable amount of CPU time. The verification process consumes negligible CPU time. This allows us to require the would be spammer to spend say 20 seconds per mail, which will slow him down considerably, over his current tactics of 1000 long Bcc lists allowing him to hand off spamming tasks to mail servers.) [...]

Sounds like a headache to me: people use wildly different machines to handle their e-mail. Some places use 25 MHz '486 machines, others use 300 MHz Pentium-IIs, a difference of 1-2 orders of magnitude? Collision search is also easy to parallelize over a network, so the load can be shared using, say, 50 Pentium-II 300MHz PCs, costing less than $100,000 (we don't need lots of disk or memory, just a fast CPU). Here's at least three orders of magnitude for you. The '486 may be used by a school, while the 50 Pentium-II machines are owned by Spamford W., Esq. Now we're faced with a dilemma: we either limit the school's outgoing e-mail capacity severely, or Spamford will keep on sending spam. For every thousand messages the school sends Spamford can send a million. The risk: starting a CPU arms race. Ge' Ge' Weijers Voice: (614)326 4600 Progressive Systems, Inc. FAX: (614)326 4601 2000 West Henderson Rd. Suite 400 Columbus, OH 43220 http://www.Progressive-Systems.com

Steve Schear writes:

...

I disagree that the best way to implement hashcash is solely via the SMTP mechanism.

It is nicest to implement the blocking at the SMTP agent if this can be done in a privacy preserving manner, because it reduces the bandwidth consumption for users, and reduces the complexity of their local software -- they only need to generate hashcash for outgoing mail.

...

Almost any efficient hashcash mechanism will require some sort of history file, or "invited list," to allow mail lists and those we have corresponded with to continue to do so w/i having to supply hashcash each time. This list contains information which might have privacy implications and so should not be stored at the ISP, which can be forced to reveal such info w/o the knowledge of the client.

See my post to Bill Stewart with

Subject: supeona immune postage free list

I think you can construct ways to allow the ISP to reject messages without postage, and to allow frequent users to be exempt, and to do this such that there is no invited list which becomes a juicy target.

...

If 'open' list policies were changed so that anyone could post if they supplied enough hashcash for each mailing list recipient for their first 1 or 2 posts, and thereafter no longer needed to supply hashcash (sort of minimum reputation capital), it might eliminate hit-and-run or throw-away account SPAMers without offering too high a hurdle to new or infrequent pos ters.

That is an interesting thought. Well the interesting thought is that it gives us a way to block spam at the list server, because a) the spammer has to overcome the hurdle you described, and b) the list operator could punish spammers who started spamming once getting over the hurdle by blocking them. The usual trick of switching to a different address, or a remailer would not work because they would still have to generate a new hashcash coin as the list operator could block the coin.

I would however think that a large denomiation coin made out to the list server would make more sense than generating lots of coins for all of the list subscribers.

However there is a nasty side to the above, in that it encourages the list operator to censor posts he considers spam.

It would be simpler and I think tend to less encourage censorship to introduce a third party filtering service such as Ray Arachellian's, and the other one, which had an option to have only spam filtered out.

At this moment in time the spam content on mailing lists I am on is very low. I get much more in email.

Doubtless this would change when spammers discovered that email spam is too CPU expensive to use.

Also hashcash really doesn't work well for USENET. NoCeM's are cool things for USENET, a distributed ratings system, and I understand can be configured to work for mailing lists also.

...

Since most popular email clients allow plug-ins (e.g. Eudora) or extensions via Java/ActiveX, providing hashcash functionality via a plug-in and the java generators you propose would provide a simple mechanism to test its effectiveness w/o needing to involve the IETF.

You can do a lot with local SMTP and POP3 proxies.

There are a couple of java ones around.

Anyone know if there is code available to do SMTP and POP3 proxying?

I am told by one subscriber to look at TIS firewall toolkits imap program.

...

The shortcoming of a plug-in approach is that few newbies will know of it or install it and will therefore have to wait till its built into the new release of whatever client they use or until some or all of the features are supplied by their ISP,

Yes, this problem is the motivation for trying to work out ways that as much as possible could happen at the ISP side for less technical users, and even for technical users, I know few people are interested to install new software.

Also ISPs often seem more concerned about spam abuse than users.

...

allowing those calling regulation to continue to blow their horns. However, if after a successful cypherpunk beta we could get the major email client companies (Netscape, M$ and Qualcomm) to include our plug-ins with all their new updates and offer them for free download from their Web sites, it could quickly steal the CAUCE folk's thunder.

It would be cool if we could pull that one off.

Do we have anyone on list who is familiar with eurdora, qualcomm and netscape plugins who would like to interface a hashcash library to these systems?

Anyone who can write java applets want to implement a java hashcash library? (Should be easy.. jdk1.1.3 includes a sha1 function ... I am not sure if this is included with netscape 4 or not, but there are also numerous sha1 native java codes around, www.systemics.com being one).

Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0

CC: me as I'm not presently reading cypherpunks (this was bcc:ed to coderpunks). On Sat, 13 Dec 1997, Adam Back wrote:

The required filter functionality is something like this in order of desirability:

Accept the SMTP session. Use an EHLO extension HASHCASH to say that this server expects hashcash. (Extended HELO is a method of specifying SMTP extensions (I think)). Accept the headers, and if a valid hashcash postage is not included, hand off to the real mailserver a site configurable bounce message.

I'm not sure this is doable. From what I've seen of the sendmail anti-spam stuff and the SMTP protocol, you can't just accept the headers and then decide whether not not to accept the rest; you either have to be able to (at present) a) reject the message before you receive it based on the FROM data (known spammers, bogus hostnames, etc); b) reject the messages before you receive it based on the RCPT data (anti-relaying: is the recipient at our site?); c) reject the message after you receive it. Obviously with spam, you'd like to be able to reject it before it takes up bandwidth. So, an extended protocol could require a CASH command from the client before DATA will be accepted. The client could generate the cash on the fly, or it could be grepped out of the headers. If you don't want to dink around with patching sendmail or whatever for an extended protocol, then simply use a system-wide procmailrc to enforce hashcash; procmail can generate bounces very easily (or rather, trick the MTA into generating the bounce for it). Or, make requiring hashcash a user-selectable option by having a publicly-available script which a user can have included into his .procmailrc by setting some variable.

This still leaves open the question of the user generating their own hashcash postage. Again this could be problematic for neophytes. One solution is to include a URL for a web page including a javascript hashcash generator -- this means that no new software must be installed, the user cut and pastes the generated hashcash into their message.

Two potentially simpler solutions: a) the client MTA could generate hashcash on the fly as needed (like it generates Message-IDs); b) a filter could be installed in place of the user's normal MTA which generates hashcash. The latter is probably better (easier to implement). For example, if the normal MTA is sendmail, then a fake sendmail could be installed which is just a nasty little script which parses out the recipients, generates a suitable hashcash token for each one, and inserts the appropriate headers, and then passes the message off to the real sendmail. My preferred means of spam-blocking right now is a barrage of tests for typical spams using procmail, combined with a reverse spam block. An ordinary spam block is an address munge where something is added to the address to make it undeliverable, so ordinary users have to unmunge your address before they can mail you, i.e. andy@neptune.chem.uga.nospam.edu. A reverse spam block lets you use your real address for posts but requires users to add something to your address to guarantee delivery. As my sig indicates, if you add +spamsucks to my username, various spam filtering features are deactivated. If I wanted to, I could bounce anything which didn't have the +spamsucks in it. The recipe I use also uses lists of "trusted" users (ones I don't do any spam testing on, so they don't need the password) and "spammers" (we don't spam test these either, we just make them bounce). Also will reject messages where I am bcc:ed (unless from someone trusted or the password was used) or on a huge visible list (again as before). It works pretty darn good. I hardly get any spam. Most of what I get bounces back to the sender with "User unknown". If the sender has a forged From, then this at least bounces there, or to the site's postmaster, who will likely take some action (but not complain to me because I don't exist). If the From was completely bogus, then I get the bounce, but that doesn't happen too often. I use this same system for the return address of the cracker remailer (anon@anon.efga.org) and it works pretty well, though as of late I am munging the return address for all USENET posts a la mail2news_nospam@anon.lcs.mit.edu (which has been hugely effective); you're not supposed to reply anyway... I would like to modify the nymserver so that users can set a reverse spam blocking password, but just haven't gotten around to it. I'm pretty sure it can be done, though. Andy Dustman / Computational Center for Molecular Structure and Design For a great anti-spam procmail recipe, send me mail with subject "spam". Append "+spamsucks" to my username to ensure delivery. KeyID=0xC72F3F1D Encryption is too important to leave to the government. -- Bruce Schneier http://www.athens.net/~dustman mailto:andy@neptune.chem.uga.edu <}+++<

On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote: Yes, but if you just phase it in over time, what benefit, if any, will users see until hashcash is fully deployed. Until that time, people will still have to accept email without hashcash or risk losing important messages.

If I want to send an important message to you and I get a hashcash rejection reponse and I'm given a Web site where I can get a Java applet to create the hashcash, I'll do it. We all know we must affix postage to our snailmail. Its time to embrace the postal system's paradigm and educate the reminder of the Net. Those who risk missing an email or two will totally stop their SPAM. Those who won't, won't.

I don't see people adopting hashcash unless there is some intermediate benefit to doing so.

All we need is a small, influential, group to sing the praises of hashcash. I'm sure Declan and Wired will pick up the banner if what we come up with works. After that IETF activity is a far gone conclusion. --Steve

At 4:21 pm -0500 on 12/18/97, William H. Geiger III wrote:

Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage based charges for everything done on the 'net. What will be next? FTP sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS servers charging per lookup? Routers charging per packet?

Yup, and you'll like it too. Especially if it efficiently prices net.resources so well that the cost of "administering" and "controlling" them disappears, well past the last basis point compared to our current network resource "allocation" scheme, with time-based fixed pricing, "peering" agreements, etc. ... For details of the foundations of this, cf Kevin Kelly's "Out of Control", or any e$ rant I've written in the past few years. Remember my joke about a router which saves enough out of operations to buy a copy of itself? Micromoney mitochondria, picomoney processor food, and so forth... Look, Ma, no (human) hands...

Note: In Adams proposal for hashcash only charges the user CPU cycles. The incentive for wide implementation of hashcash is going to be a real ecash based system where the implementors can make $$$ off it.

Yup. Money's fungible, and all that. In collision algorithms like hashcash and MicroMint, you're effectively using computation time as copy protection on unique digital objects, but *only* for that, like you're only using the cost of intaglio printing to create unique paper bearer certificates, dollar bills being a good example. You still have to add *value* to those unique objects, and for that you need a market to set a price. (Sorry, Adam) The parallels are even greater for things like hashcash, or at least MicroMint. Like real coins in meatspace, the first collision-coin's expensive to "mint", but the rest are vanishingly cheap. However, you *do* want to make them to be worth something besides cycle time. That's because the cost of anything is the foregone alternative, and all that. If you don't attach fair value to unique useful items, someone else will and start arbitraging them anyway. Ticket scalpers are a classic case of this. Might as well get into the business explicitly instead of creating it for someone else, I figure. Anyway, all this fun with money requires, horrors, an actual financial intermediary. Yet another private currency, in other words. Probably whole bunches of them, I bet, all competing to fill each available market niche. CryptoAnarchy, MarketEarth, Geodesic Economy, whatever...

I have *PAID IN FULL* for my Inet usage!! What bits I send over the Inet, how many bits I send, and who I send them to is NO ONE's BUSINESS but my own!!! -- Last Anarchist of the Inet.

Sounds more like an industrio-socialist, to me. :-). Naw... Just pulling your leg. Put your Glock away... Seriously, I can't imagine fixed prices for *anything* once we have instantaneously settled cash auction markets for anything you can send down a wire. Fixed pricing is an artifact of long production runs, hierarchically organized "economies of scale", and all that. Moore's "Law" creates diseconomies of scale, particularly for information goods and services on a public network. Nodes become cheaper compared to lines, which gives you geodesic networks instead of hierarchical ones, all that stuff. The, um, net, result is auction pricing and cash settlement. Not will you pay in full, Mr. Geiger, but you'll pay cheaper, too. :-). Lots cheaper, I bet... If you could have cash-on-the-routerhead packet switching, it would behoove each router to have as many connections as possible to sell it's services down. You get a *more* geodesic network. That means lots of smaller routers instead of Forbin-sized ones that we're trying to build now. Frankly, super-routers are lost cause. No switch can monopolize the traffic, or it'll choke and the network will route around it. That's the nice thing about Moore's "Law" on the net. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah@shipwright.com), Philodox e$, 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' The e$ Home Page: http://www.shipwright.com/ Ask me about FC98 in Anguilla!: http://www.fc98.ai/

At 3:26 PM -0700 12/17/97, Steve Schear wrote:

...

On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote: Yes, but if you just phase it in over time, what benefit, if any, will users see until hashcash is fully deployed. Until that time, people will still have to accept email without hashcash or risk losing important messages.

If I want to send an important message to you and I get a hashcash rejection reponse and I'm given a Web site where I can get a Java applet to create the hashcash, I'll do it. We all know we must affix postage to our snailmail. Its time to embrace the postal system's paradigm and educate the reminder of the Net. Those

This "We all know we must affix postage to our snailmail. " is misleading, as there is no "must affix postage" ontologically wired into mail delivery. Or package delivery. Indeed, package deliverers charge what the market will bear, and prices move around as competitors jockey for market share. If a private network decides to charge for packet delivery, then the price will be what the price is, determined by a variety of factors. Ditto for remailers. The solution is not at the "international standards" level.

All we need is a small, influential, group to sing the praises of hashcash. I'm sure Declan and Wired will pick up the banner if what we come up with works. After that IETF activity is a far gone conclusion.

"Far gone" is probably correct. Foregone is not. I doubt that puff pieces in "Wired" will do much. And all those cover stories showing Jaron Lanier and his dreadlocks jacking into virtual reality did exactly what for VR, besides selling some magazines? --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

William Geiger writes:

Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage based charges for everything done on the 'net. What will be next? FTP sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS servers charging per lookup? Routers charging per packet?

We already pay usage charges indirectly. That is to say, in the UK you pay per second phone line charges. It would actually save me money if the net was a bit more responsive. If I was paying packet delivery at guaranteed performance, I would spend less money on the phone charges. Flat rate charges is nice enough, and the way I would like things to stay, however I tend to think that usage charges would not be as bad as you expect, because it would put competitive pressure on ISPs to provide performance. (My current ISP has truly pitiful performance.) Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0

Bill Stewart writes:

...

This is exactly what I was addressing: remailers only have to get themselves certified as remailers and then prove their certification to the destination

You're both taking the wrong approach - make the originator of the message generate the hashcash, and make sure the remailer syntax lets them paste it in as needed. For chained remailers, generate multiple layers of hashcash. Maintaining whitelists is a losing game, but unnecessary here.

This works well enough. The more thorny problem to solve is that posed by Robert Costner: what do you do about nyms. You (the sender) can't include postage for nym reply blocks because you don't know (and mustn't know) the remailer chain pointed to by the reply block.

Mailing lists are still hard, and perhaps best handled by the user's software (or some fancy variant like user-selectable filters at the ISP mailbox.)

I think it's simplest to have the user explicitly allow the mailing list. You could possibly auto detect the pattern of a user subscribing to a mailing list at the mail filter level also. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0

-----BEGIN PGP SIGNED MESSAGE----- In <199712221801.SAA00366@server.eternity.org>, on 12/22/97 at 01:01 PM, Adam Back said:

William Geiger writes:

...

Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage based charges for everything done on the 'net. What will be next? FTP sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS servers charging per lookup? Routers charging per packet?

We already pay usage charges indirectly.

That is to say, in the UK you pay per second phone line charges. It would actually save me money if the net was a bit more responsive. If I was paying packet delivery at guaranteed performance, I would spend less money on the phone charges.

Well this is a UK telco problem not an Internet problem. I most certianly do not wish to see my rates increase in an effort lower yours.

Flat rate charges is nice enough, and the way I would like things to stay, however I tend to think that usage charges would not be as bad as you expect, because it would put competitive pressure on ISPs to provide performance.

I highly doubt it. Currently the going rate in the US is $15-$20/mo unmetered rate for a standard dial-up ppp account. This includes 1 or 2 mail boxes, 5-10Mb quota space, WebServer, NewsServer, POP3 & SMTP servers. This is fairly standard offering but will vary slightly from one ISP to another. This is what the market will bare due to fierce competition in the ISP bussiness. I doubt that switching to a metered rate system will lower prices any and more than likely will *increase* prices. There have been ISP's in the past who have offered metered rate services, they are no longer in business. People have voted with their walets and have overwhelmingly stated that they do not want metered rate services (this is why you hear some on the list talking about "educating" the users).

(My current ISP has truly pitiful performance.)

Get a different ISP. I have switched my webpages and mail accounts to a shell account so I can switch ISP's at will without any problems. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a-sha1 Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNJ9FiI9Co1n+aLhhAQI3YgP/V886btQ7hRVL1ouJc7kq92ESmveQshEo TEMzFq1lFABiuOd5cfdup92irtKWkIzZFZ+gK0Og9PR7XFVcqd1a4YgB3RKpXCcV 30185A6YtsHnvmK4FgulGNE9kKcTlqjVMLCbQduV+hTxrJy8AWO3fLdvUj70nfdp y0iv1ve+w3A= =lGTl -----END PGP SIGNATURE-----