hashcash spam prevention & firewalls
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). (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 what we want is a filter to bounce messages without the required hashcash postage, we ideally want this to happen at the ISP or organisational SMTP server end, rather than at the recipients end, because a) it is simpler for 1 service provider to install software than 100,000 neophytes, and b) it reduces bandwidth consumption on dial up users pay per second lines as the spam is killed before they see it. 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). 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? Another approach is to try to hook in a hashcash SMTP proxy filter at the firewall. I am not that familiar with firewalls. Anyone have thoughts on the sorts of filtering you could install at the firewall level, and how portable this would be based on installed base of types of firewall? (ie It is not interesting if you can do nifty proxy functions with foobar firewall software if it is used by <1% of sites, and the function is impossible with other firewall software). 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. If the postage is valid, replay the headers to the real SMTP server (with IP masquerading so that the IP address appears to be coming from the originator, so that the SMTP server will not get upset about reverse DNS look up mismatches etc). Then act as a dumb proxy for the rest of the connection passing data through to the normal hashcash server. 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. 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. Comments? 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
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
Robert Costner <pooh@efga.org> writes:
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.
Remailers require a different strategy. With remailers you are trying to discourage spammers from using the remailer, with email you are also trying to discourage spammers, but you have to do it in ways which is easy for neophytes to cope with. With remailers people already have to get new software, and all of the source is available, so it is relatively easy for us to add requirements for hashcash postage into type I remailers, in to mixmaster, and newnym. Hashcash was originally designed for this. There is an implementation on http://www.dcs.ex.ac.uk/~aba/hashcash/ Also Andy Dustman, who is the guy who administers the efga remailer (right?) wrote a python interface to hashcash, and is keen on python hacking. I suspect efga remailer may even be written in python if Andy had much to do with it :-) So with remailers you insist that the sender generate the hashcash with all of their remailer requests, you bounce it or silently trash it if there is no valid hashcash. Also I would highly recommend that you use Ian Goldbergs exit man script for remailer delivery -- it delivers via HotMail and other such free web based email systems, via publically accessible proxies and ensures that your remailer address doesn't appear in the headers where you are the exit remailer.
Of course the Cracker mail system also runs various mail lists for EFGA.
Mailing lists you have to realistically I think not use hashcash for. The majordomo process would become overloaded if it had to generate hashcash for each recipient of each message. Similarly the poster would be over loaded if he had to generate hashcash for each recipient of the message. (I would not like to have to generate 1000 (or whatever the current readership is ) of 20 second hashcash stamps to post this message to cypherpunks for instance). The way to cope with this in hashcash filters is to exempt mailing lists from hascash requirement via a user administered allow list. (You could possibly auto detect mailing lists at the hashcash filter agent -- the subscription process could be detected -- or more risky in that spammers might work out a way to abuse this -- by recognising the pattern of mails -- lots of mails with the same Sender, and different From fields.
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
I tend to argue against this include list -- remailers become less useful if you can not send mail to anyone who can receive SMTP mail. I prefer the exit man via HotMail approach to the send notification that there is anonymous email ready to be picked up approach.
ISP's in general could handle the hashcash generation at the SMTP level by keeping databases of who sends email to whom.
Yes. This can work reasonably well because people do not reply to spammers, and most email has a to and fro pattern.
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.
Read the stuff on http://www.dcs.ex.ac.uk/~aba/hashcash/ it talks more about remailers. Adam
At 10:55 AM 12/13/97 GMT, Adam Back wrote:
Remailers require a different strategy. With remailers you are trying to discourage spammers from using the remailer, with email you are also trying to discourage spammers, but you have to do it in ways which is easy for neophytes to cope with.
I'm unsure that this is what we are trying to do at all. I'm perfectly willing to assume that a remailer gets it's mail into it. The problem is now that the remailer has to deliver the mail. Under this plan, to deliver mail there must be hashcash for the delivery to the point beyond the remailer. I'm suggesting that if the remailer sends out 3,000 messages with a 1/3 sprinkling of CC'ed addresses on equipment that is half as fast as normal equipment, the 20 seconds of hashcash will require an average of 44 hours of CPU time per day. 44 hours for the hashcash that is needed at the destination SMTP, not the hashcash to get into the remailer. HashCash has often been suggested as a method for throttling spam that would be sent to remailers. This is not what I was responding to. I was responding to a suggestion that ISPs start requiring hashcash. I'm honestly unclear as to whether the remailer must generate the hashcash for the future SMTP's or if the suggestion is that the originator is generating all of the hashcash. Since remailers mangle the messages and regenerate them, I am unsure if originator generated hashcash is to be made for the destination mail port, or if the remailer must do this. If there is in fact a requirement that the sender generate the hashcash, then I am not sure this will work. A nym reply block possibly does not lead to an exit address, but rather to another reply block. In fact, this should always be the case. There is no way for the sender of the email to know this route, or how many reply blocks there are. Any scheme which permits the same hashcash to send a message to two nym reply blocks and a destination address will also allow spammers to send spams to multiple addresses with the same hashcash. Not only with nyms, but with regular email addresses multiple hops may be required to deliver email. For instance, the address "rcostner@cpsr.org" will deliver email to me. This address forwards mail to "pooh@efga.org". The efga domain cannot be POP'ed into, so this is then remailed to wherever I'm POP'ing into this month. Since the original sender cannot know this, and since ALL email to me requires a minimum of two mail gateways to get to me it seems that this hashcash plan has some problems. Further, I highly dislike the notion of maintaining system level databases of who is communicated with. As in a quote from Adam Back's web page To solve this problem subscribers should put the mailing list address in a postage-free recipients list. Traditional "wire tapping" would require that a communications port be monitored to find out who communications are being made with. Under the "postage free list" plan, this information sits in a file waiting to be collected with no difficulty at all. Implemented on the SMTP level, we have a way of testing for who a person communicates with. After a HELO, we spoof in a MAIL FROM:, then look to see if we get a "559 HashCash Required" error. I've never been impressed with the hashcash method of thwarting spam. I'm just not really sure that a technical solution to spam will work in any event. -- 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
Robert Costner <pooh@efga.org> writes:
At 10:55 AM 12/13/97 GMT, Adam Back wrote:
Remailers require a different strategy. With remailers you are trying to discourage spammers from using the remailer, with email you are also trying to discourage spammers, but you have to do it in ways which is easy for neophytes to cope with.
I'm unsure that this is what we are trying to do at all. I'm perfectly willing to assume that a remailer gets it's mail into it. The problem is now that the remailer has to deliver the mail. Under this plan, to deliver mail there must be hashcash for the delivery to the point beyond the remailer.
Simplest thing to do for non-replyable remailers is to insist that the originator include hashcash for each remailer hop. Then remailers can just refuse to remail anything unless there is a valid hashcash postage token included. For example: Hashcash-Postage: 10208remailer@efga.orgb35b746c387ff6bc Is a 20 bit hash collision on remailer@efga.org. (Antonomasia sent me a patch sometime back for hashcash which changed the hashcash syntax to: Hashcash-Postage: 10208:remailer@efga.org:b35b746c387ff6bc which is easier to parse. (He also simplified the command line interface... mine is a bit scruffy)). To send through remailer@efga.org and remailer@replay.com, you would include a hashcash postage stamp for each remailer. So you add to the remail instructions for remailer@efga.org a hashcash postage stamp: :: Request-Remailing-To: remailer@replay.com Hashcash-Postage: 10208remailer@efga.orgb35b746c387ff6bc and to the nested encrypted remailing instructions for replay you add a hashcash stamp for it too: :: Request-Remailing-To: replay.com Hashcash-Postage: 10208replay.com05e4fee159c1cfc9
HashCash has often been suggested as a method for throttling spam that would be sent to remailers. This is not what I was responding to. I was responding to a suggestion that ISPs start requiring hashcash. I'm honestly unclear as to whether the remailer must generate the hashcash for the future SMTP's or if the suggestion is that the originator is generating all of the hashcash.
The originator must generate the hashcash for all hops.
Since remailers mangle the messages and regenerate them, I am unsure if originator generated hashcash is to be made for the destination mail port, or if the remailer must do this.
The hashcash proposal was originally focussed on remailers, and for this purpose it is suggested that the originator generate all postage.
If there is in fact a requirement that the sender generate the hashcash, then I am not sure this will work. A nym reply block possibly does not lead to an exit address, but rather to another reply block. In fact, this should always be the case.
I am not sure I understand the comment above. Why should a reply block always point to another reply block? It provides pretty good security to have a newnym address which when mail is sent to it, the newnym server looksup that nyms reply block, and mails the message with that reply block prepended to the designated first hop remailer. The reply block chain can have several hops, and can even end up in a newsgroup via a mail2news gateway, or typeI remailer. To point the whole reply block back to another newnym address adds additional protection but I would have thought most people use only one reply block.
There is no way for the sender of the email to know this route,
A good point. You have to restructure the payment to cope with this. Here are a few ideas: - One way to do it is to require the nym owner to pre-pay hashcash postage for mails he receives. When the postage runs out, the delivery ceases. However this provides a denial of service attack against the newnym user -- just have more CPU than him and you can prevent him getting any real replies by spamming him. - Another is to require postage only for the entry remailer. This however begs the question of what is a remailer. There are problems with assuming there is some official list of "remailers". For example if I am a spammer and I want to spam I will call myself a remailer, and spam via the other remailers from this vantage point apparently within the fold, it will be difficult to detect me. I might even remail the odd message to keep up appearances. - A distributed hashcash double spend database could allow remailers to accept hashcash which wasn't directed to them specifically, but rather, which was directed to any remailer. Remailers would propogate hashcash database updates. This preserves anonymity because hashcash says nothing about the person who minted the hashcash stamp. However, interestingly, it would be necessary for the remailers to anonymously remail database updates because revealing the remailer which received the hashcash token would allow the newnym reply blocks to be traced. Disruptive remailers could remove all of the hashcash tokens as the sender would be forced to send them all to be readable by the first remailer, not knowing the identity of the rest of the remailers. Not a big problem I think because remailers which do this can be weeded out statistically, and will suffer in the remailer ping league tables for such behaviour. They can already disrupt pretty well if inclined -- just discard messages. - Or more simply, but more expensively for the sender, include a couple of hashcash tokens for all of the remailers (there being only 20 or so).
Not only with nyms, but with regular email addresses multiple hops may be required to deliver email. For instance, the address "rcostner@cpsr.org" will deliver email to me. This address forwards mail to "pooh@efga.org". The efga domain cannot be POP'ed into, so this is then remailed to wherever I'm POP'ing into this month. Since the original sender cannot know this, and since ALL email to me requires a minimum of two mail gateways to get to me it seems that this hashcash plan has some problems.
This an interesting problem that I have not seen raised before. One way to get around it would be to allow mail from rcostner@cpsr.org to arrive at pooh@efga.org without hashcash, and for mail from pooh@efga.org to arrive at your pop this month without hashcash also. You would allow via a token which you would not make generally available. That is you would say set up the .forward file not to send to pooh@efga.org, but: Robert Costner c387ff6bcb35b746 <pooh@efga.org> Then instruct the ISP side hashcash based filtering agent at efga.org, to allow this token through. Similarly for the second hop from efga.org to this months POP.
Further, I highly dislike the notion of maintaining system level databases of who is communicated with. As in a quote from Adam Back's web page
To solve this problem subscribers should put the mailing list address in a postage-free recipients list.
Traditional "wire tapping" would require that a communications port be monitored to find out who communications are being made with. Under the "postage free list" plan, this information sits in a file waiting to be collected with no difficulty at all. Implemented on the SMTP level, we have a way of testing for who a person communicates with. After a HELO, we spoof in a MAIL FROM:, then look to see if we get a "559 HashCash Required" error.
This is a major danger I agree. Bill Stewart suggested hashing the database entries, which complicates things for the attacker, but not as much as we would like. I am 100% with you on the dangers of supeonaed postage free lists. How about this alternative which achieves the same functionality and removes the juicy supeona target: Turn on hashash database for all mails. That means hashcash gets put in the database to prevent double spending. (If we don't do this spammers will club together and do one mega-spam reusing the same hashcash they generated with their spam fest motivated CPU farm and hit you with spam from many addresses, or all forged as from the same address or whatever). So now when you reply to a message, on it's way out via the mail hub, you remove that hashcash token from the double spending database. This means that the sender can cache sent hashcash tokens, and re-use them when after he gets a reply. Neat.
I've never been impressed with the hashcash method of thwarting spam. I'm just not really sure that a technical solution to spam will work in any event.
Technical solutions to spam are not easy. However hashcash is reasonably flexible in what you can do with it, and real payee and payer anonymous ecash even more so, and I figure we ought to give it a go because the non-technical solutions involve low-life politicians trying to solve the spam problems for us, and introducing legislation giving jail time for forged From fields, trying to introduce internet drivers licenses, and deputising ISPs to try to enforce the mess. It is unclear how remailers would fare in such a scenario. 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
At 11:19 PM 12/13/97 GMT, Adam Back wrote:
If there is in fact a requirement that the sender generate the hashcash, then I am not sure this will work. A nym reply block possibly does not lead to an exit address, but rather to another reply block. In fact, this should always be the case.
I am not sure I understand the comment above. Why should a reply block always point to another reply block? ... To point the whole reply block back to another newnym address adds additional protection but I would have thought most people use only one reply block.
If a person sends email from the source that also houses his nym identity, then all of the eggs are in one basket. A nym that points to another nym, that perhaps points somewhere else like hotmail is needed. Using only one nym is about as safe as not using encryption. It's fine for most purposes, but can be broken. I have gotten telephone requests from police, attorney general prosecutors, private detectives, and others that ask for the identity of a remailer user to be identified. These are refused. But I don't play games. My response is always I don't know, but if I did, I wouldn't tell you. The attack on a single reply block is simple. If the remailer machine is seized, or if a VALID court order is received, we would turn the name over. (if anything about the request is incorrect, then we would refuse the request and do so legally) If we pull up the nym HashMan@anon.efga.org and discover it is aba@dcs.ex.ac.uk then the anonymity is over. If however it points to MrHash@anotherremailer then the identity is preserved a little bit longer. The only way to breach this is to seize all remailers at the same time. Better security would be had by having a public nym that receives email, and a private nym that delivers email. -- 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
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
Steve Schear <schear@lvdi.net> 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
Steve Schear <schear@lvdi.net> 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
...
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
At 02:07 PM 12/13/97 -0600, Uhh...this is Joe [Randall Farmer] wrote:
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.
Once again someone is responding to me by talking about hashcash in the internal remailer network. I don't think this is what I'm referring to. Perhaps because I do not fully understand how anti spam hashcash would be implemented on a per message basis. The idea proposed was one to limit Spam to ISPs by using hashcash to stop spam coming into an ISP. Imagine the domain anon.efga.org wishes to send 4,000 per day messages to the various domains netcom.com, aol.com, mindspring.com, etc. Each individual message is reasonably unique coming from anon.efga.org. 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. 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? Various remailers can distort a message in a variety of ways. Dropping of MIME attachments, munging of email addresses when CC'ed to a newsgroup, adding a PGP signature or timestamp, adding headers that explain it's a remailer, adding footers that explain it's a remailer. Since the actual message can change, it seems that for hashcash to be message dependent, it would have to be generated by the exit remailer. I'm not claiming I understand the concept of hashcash. I'm simply pointing out I don't see how it would truly be effective in a real world application. -- 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
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
On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:
.....
The implementation of the plan is a more or less impossible scheme.
Nyet. It can be phased in over time...people install the software, mailing lists warn their users to exempt them, and the big servers start asking for the hashcash, little servers pick it up.
.....
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. We need to find some way for users to benefit from hashcash now, not 2 years from now when 90% of sites are using it. The only thing I can think of is having servers place "Hashcash-verified" headers on incoming mail so that users can do positive filtering ("this is valid email") rather than negative filtering ("this is spam"). I don't see people adopting hashcash unless there is some intermediate benefit to doing so. -- Phelix
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."
Phelix <phelix@vallnet.com> writes:
On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:
.....
The implementation of the plan is a more or less impossible scheme.
Nyet. It can be phased in over time...people install the software, mailing lists warn their users to exempt them, and the big servers start asking for the hashcash, little servers pick it up.
.....
Yes, but if you just phase it in over time, what benefit, if any, will users see until hashcash is fully deployed.
No spam in their mail boxes :-)
Until that time, people will still have to accept email without hashcash or risk losing important messages.
You could work around this somewhat by configuring the hashcash filter to put nonces (a random number) in the bounce messages for messages which arrived without hashcash. The instructions could read: Email to this address requires hashcash postage. To generate your hashcash postage get software from here: <URL> Alternatively simply reply to this message putting this number in the subject field: 12347651324 The danger is that the spammer could abuse this by automating the reply to these bounce messages. However spammers typically don't like to include a valid reply address, so this at least makes spammers include an address where they can be replied to.
We need to find some way for users to benefit from hashcash now, not 2 years from now when 90% of sites are using it. The only thing I can think of is having servers place "Hashcash-verified" headers on incoming mail so that users can do positive filtering ("this is valid email") rather than negative filtering ("this is spam").
I don't see people adopting hashcash unless there is some intermediate benefit to doing so.
An easily observable tag in the subject field such as: [SPAM?] meaning no hashcash or [NEW] meaning you had never received messages from this address before could be useful perhaps. 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
...
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 ^^^^^^^^^^ Hashcash has a double-spending database to prevent this -- one use and you've got to wait until it's out of the database (quite possibly a long time) before you can reuse it.
...
The implementation of the plan is a more or less impossible scheme.
Nyet. It can be phased in over time...people install the software, mailing lists warn their users to exempt them, and the big servers start asking for the hashcash, little servers pick it up. ...
privacy problems with warehousing with your ISP a list of your other email addresses, or the addresses of your postage free friends.
This's already been addressed.
Changes to the "Don't charge postage" database will be awkward.
Well, it wouldn't be much trickier than a Pine address book (few things are :) or a killfile. --------------------------------------------------------------------------- Randall Farmer rfarmer@hiwaay.net http://hiwaay.net/~rfarmer
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
-----BEGIN PGP SIGNED MESSAGE----- In <v03102806b0bdff5466dc@[208.129.55.202]>, on 12/17/97 at 05:26 PM, Steve Schear <schear@lvdi.net> said:
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.
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? 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. All this talk of "educating" the user is scary. After the newspeak translation: "Lets condition the sheeple to accept a metered rate Internet even though they don't want it". Hashcash is an evil worse than a 1000 Spamfords. I will not support Hashcash now or in the future and will do my best to stop its spread. As a matter of fact I plan on writtin Declan on this personaly. I also plan to form a coalition to block any adoption of hashcash within the IETF. Hmmmmm sounds like a good BOF for LA :) This crap will do nothing but place an unnecessary burdon on users while doing *nothing* to stop SPAM. 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. - -- - --------------------------------------------------------------- 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 iQCVAwUBNJmTx49Co1n+aLhhAQLc6QP/YDyeSPwmqhKaLTyBiU236/2hlKCMRmaW tRuPhIGE76aO4JQqRIxSvVeSJsH3qvm7VW6OPn93gHQqji0OOcAbniZyYJuLJFx/ EHeuj2+FiFjVaHZNu2HhPS5x22AmeMNb0a8OtZFZVHYCobHTYpYvxzJVWCll7sCu mm3jGp16eZQ= =XLxl -----END PGP SIGNATURE-----
At 4:21 pm -0500 on 12/18/97, William H. Geiger III wrote, though not in this order,
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.
You've paid for your end of the connection, but you haven't paid for mine, and you especially haven't paid for getting your bits to my eyeballs. Neither has Spamford. I'm usually willing to read your words, but not his. Hashcash-mail is a tool for users to use to automate limiting the email they receive to mail sent out by real individuals who actually want to communicate with them, throwing away mail from spammers. Whether it will catch on or not is a social issue. There are telephone answering devices that prompt for a password and either hang up on callers who don't have one, forward them to the answering machine, or just give them a low-priority ring. I don't use one, and nobody I know currently does, because they annoy the callers you care about more than they annoy telephone spammers, who have lists of thousands of other people to spam if you're not interested. On the other ham, if PacBell offered distinctive ringing like most Bell companies do, I'd use it - not for splitting types of callers, but for my fax machine...
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.
It would be interesting to find useful problems that could be used instead of hash collisions. Factoring numbers can be distributed well, and it's possible to tell quickly that X is a factor of Y, but unfortunately it's not possible to tell quickly that the user unsuccessfully checked some range of potential factors rather than just pretending to have done so. Similarly, if the user finds the key K | C=DES(M,K), you can tell quickly, but you can't tell if the user checked a range K1..Kn except by checking it yourself (slowly.) But maybe there's some useful variant that can be checked quickly.
Well IMNSHO hashcash 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?
Digicash, maybe, though not hashcash, since hashcash is just a timewaster that's easy to verify and only takes a long time for high-volume users. As far as routers charging per packet goes, we've had X.25 networks which charge by the kilopacket for a long time; it's much clumsier and more expensive to operate than a flat-rate network. One of the reasons the Internet has overtaken X.25 so dramatically is that flat-rate pricing encourages people to use and provide free services, increasing the base of customers and the size of the flat-rate service they buy -- the ISPs also win. And many web pages _do_ charge for reading them - usually the charge is the time it takes to download and (read or) discard an advertising banner; users are generally much more willing to pay that cost than cash, though there are some services that give you abstracts of articles for free and charge you money for the full version (either charging per item or charging per month for "premium" service.) DNS charges are paid for by the domain name holder who wants to be found. TLDs and SLDs are funded by the domain name registration fees in some places, and unfortunately by Your Tax Dollars in other places, or by DNS fees laundered by the government through their subcontractors. Lower-level domain name service is paid for by the SLD holder or agents. If you don't want to pay to publish your DNS name on the servers, you can always call yourself http://192.257.23.42/ or whatever, as many spam sellers do. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
William Geiger <whgiii@invweb.net> 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----BEGIN PGP SIGNED MESSAGE----- In <199712221801.SAA00366@server.eternity.org>, on 12/22/97 at 01:01 PM, Adam Back <aba@dcs.ex.ac.uk> said:
William Geiger <whgiii@invweb.net> 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-----
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/>
Robert Costner <pooh@efga.org> writes:
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?
The latter. The originator provides all postage for one way remailers. Nym reply block postage needs other mechanisms as described in a previous post.
Various remailers can distort a message in a variety of ways. Dropping of MIME attachments, munging of email addresses when CC'ed to a newsgroup, adding a PGP signature or timestamp, adding headers that explain it's a remailer, adding footers that explain it's a remailer. Since the actual message can change, it seems that for hashcash to be message dependent, it would have to be generated by the exit remailer.
Making the hashcash message dependent is interesting in that it removes the need for a double spending database, because apart from a DoS attack it is not interesting to the spammer to send you multiple copies of the same mail, and in previous discussions someone suggested it for this reason. 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. 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
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
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
...
I find this concept to have problems.
Yah, so do I...I don't like things that allow abuse of discretion, but I thought it was necessary -- I didn't know hashcash could be prepackaged when I posted this. It's a moot point since it's not needed anyway, but if morbid curiosity overwhelms you, read on...To summarize, no single organization would certify remailers, not all hosts would need to be certified, and banning remailers wouldn't be any harder than it is today. =============================================================================== ...
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?
Well, the intention was for no single organization to certify remailers, but rather to distribute the responsibility among anyone who can be trusted not to certify a spammer. Individual gateways could choose whose certifications they trusted if they thought some authorities were too restrictive or thought spam was seeping through. Yes, I'd imagine CAUCE and Verisign (along with Infonex, nym.alias.net, etc.) would try to set themselves up as authorities. NSA wouldn't because they don't like remailers at all (except for those identity-escrowed FORTEZZA-powered Big-Brother-friendly ones, which wouldn't get users anyhow :).
How much would it cost for each of the 50K mail hosts to become certified? This is an administrative nightmare.
Not all hosts, just high-traffic ones for which other solutions (having users exempt them from hashcash [for mailing lists] and having heavy users generate their own hashcash [for ISPs]) won't work. This basically means remailers. ...
Currently remailers can send mail most anywhere. I suspect that if remailers had to get certified (say a RASCi rating of "remailer")
The certification scheme wasn't designed for rating but rather to let cracker get by on less than 44 CPU-hours a day.
most mail hosts would begin denying mail from remailers.
They could already. Get Raph Levien's list and block mail from those addresses; unlisted remailers would be found soon enough. If you also used the certification for some arbitrary non-remailer, non-spam servers, it would probably be harder to use certification to ban remailers than to use the remailer list. --------------------------------------------------------------------------- Randall Farmer rfarmer@hiwaay.net http://hiwaay.net/~rfarmer
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
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. 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.) It's hard to tell a real mailing list from a spammer's mailing list, and both of them do mail explosion and send their mail to names not listed in the To: line, so it's hard to do a technical fix. There are scads of attacks against any fix, like having disposable_user@juno.com join the mailing list for a while and them spam it. But remailers are easy. Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Bill Stewart <bill.stewart@pobox.com> 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
At 5:55 PM +0000 12/22/1997, Adam Back wrote:
Bill Stewart <bill.stewart@pobox.com> 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.
eCache is probably the best solution for remailers (and probably SPAM in general) since real value can pass anonymously from sender to receptient.
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.
Yes, especially when the list requires a hashcash 'initiation,' before allowing unlimited postings, to prevent many common list SPAM abuses. --Steve
On 22 Dec 1997 14:15:31 -0600, Adam Back <aba@dcs.ex.ac.uk> wrote:
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.
Could you throw hashcash into the reply block? This would, of course, make reply blocks non-reusable. Perhaps all remailers could agree to accept hashcash made out to a generic name like "remailer". This way, the sender can just generate X coins without worrying about which remailers the message would go through. The only problem is that the sender would have to know how many coins to generate. Actually, if the message never went through the same remailer twice, only one coin would needed. Set up the remailers so that they don't strip away a coin made out to "remailer". There could be problems with tracking the message though.
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.
Each user will probably have a list of names that he will accept coins for. Mail sent to a listserver could have a coin made out to "listserver@foo.bar". The listserver could, after checking the coin, simply pass that coin along with the message to everyone subscribed on the list. The end user will receive a coin made out to "listserver@foo.bar". If that name is on his list, the coin will be checked; otherwise the message is automatically dropped/bounced/whatever. This way, the listserver is never burdened with generating hashcash; but those who send messages to the list are (but they only have to generate one coin for each message). -- Phelix
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.) ------------------------------------------------------------------------- Bill Frantz | One party wants to control | Periwinkle -- Consulting (408)356-8506 | what you do in the bedroom,| 16345 Englewood Ave. frantz@netcom.com | the other in the boardroom.| Los Gatos, CA 95032, USA
Bill Frantz <frantz@netcom.com> 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
On 12 Dec 1997 22:44:29 -0600, Adam Back <aba@dcs.ex.ac.uk> 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
Phelix <phelix@vallnet.com> writes:
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 [...]
How does PGP do it with their policy enforcer?
Their controversial GAK ready policy enforcer works as a a local SMTP proxy. You set up your normal SMTP server on another machine, and configure the policy enforcer to forward mails to the normal SMTP server. Or presumably if you can configure your SMTP server to accept connections on a port other than 25 you could have the SMTP enforcer on the same machine. The same thing could work for a hashcash filter, and it is one feasible solution.
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)
The functionality which is lost is the possibility for the sendmail to be configured to do a reverse DNS lookup on the IP address which is connecting to it, and check that that domain is the same as the domain in the From field. Also ident lookups don't work anymore either. However I am not sure how reliable either of these mechanisms are, and I'm not sure that many people are using them because they would be unlikely to be reliable in the general case. So probably this is not a problem.
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.
A local SMTP proxy to add hashcash on the way out should work fine.
require valid hashcash on all mail, _until_ the recipient replies to a mail. This is good because people rarely reply to spammers.
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).
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?
The difference is that it allows the ISP which is hit by spam attacks to install a hashcash filter. With simple resource metering at the spammers ISP side, the spammers typically abuse other peoples open SMTP agents to forward their spams for them. Their ISPs can do little about this. Really it's best if the sender is left to generate his own hashcash, the motivation for working out ways to have the originators ISP's outgoing SMTP hub generate hashcash for them is that it is simpler to install in the short term. 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
-----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 crumbleincluding 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-----
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.
-- Phelix
--------------------------------------------------------------------------- Randall Farmer rfarmer@hiwaay.net http://hiwaay.net/~rfarmer
Randall Farmer masquerading as Joe <rfarmer@HiWAAY.net> 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<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
[I see I overlooked a major feature of hashcash in my idea for exempting remailers from it...sp'cifically, I didn't know you could prepackage hashcash. Needless to say, I don't send my good posts from this address :) ]
Randall Farmer masquerading as Joe <rfarmer@HiWAAY.net> writes:
Yep, state-of-the-art MITM techniques in action. :) ...
I think Phelix was probably viewing it from the point of view [o]f "what if all ISPs turned off non subscriber mail forwarding at their SMTP hubs"?
Nonetheless, it'd still hold that hashcash would be harder to get around than simple filtering...also, like you said, it's in the interest of the ISPs to use hashcash, whereas stopping outgoing spam doesn't do much for them. ...
(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.) ^^^^^^^^^^^
Good description, but you only needed those last two words. Ident really is a pain, especially for those of us who can't avoid it (It makes the case for crypto that much stronger, though :). --------------------------------------------------------------------------- Randall Farmer rfarmer@hiwaay.net http://hiwaay.net/~rfarmer
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
Would this work for GSM phones as well? I believe that GSM-spam is becoming a wide spread problem. In Finland the GSM phone numbers are published in online databases where spammers get the numbers and they use free Internet-to-GSM/SMS message services. Using hashcash on the smartcard in a GSM phone would be really neat! Mike.
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
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 <}+++<
participants (15)
-
Adam Back -
Andy Dustman -
Bill Frantz -
Bill Stewart -
frissell＠panix.com -
Ge' Weijers -
Mike -
phelix＠vallnet.com -
Robert A. Costner -
Robert Hettinga -
Steve Schear -
stewarts＠ix.netcom.com -
Tim May -
Uhh...this is Joe [Randall Farmer] -
William H. Geiger III