Beat Spam Using Hashcash 324
Shell writes "If they want to send spam, make them pay a price. Built on the widely available SHA-1 algorithm, hashcash is a clever system that requires a parameterizable amount of work on the part of a requester while staying "cheap" for an evaluator to check. In other words, the sender has to do real work to put something into your inbox. You can certainly use hashcash in preventing spam, but it has other applications as well, including keeping spam off of Wikis and speeding the work of distributed parallel applications." If you're specifically interested in hashcash for your mail server, Camram has some interesting ideas -- their Frequently Raised Objections page may be illuminating.
Work for it? (Score:2, Informative)
Again? (Score:4, Informative)
The previous [slashdot.org] stories [slashdot.org] weren't enough?
Re:This doesn't *stop* anything (Score:5, Informative)
Did you even RTFA? If there is *any* sort of time lag from when the Supplier A generated the hashes and sent to the Spammer B and the spammer sends the mail the hash's will become invalid.
3. The date (and time) a stamp was minted. Stamps in the future and those too far in the past may be judged invalid.
Re:What about mailing lists?? (Score:3, Informative)
Jeez.
>>
How do you deal with large-scale legitimate mail sources (i.e. mailing lists, mail houses, etc.)?
There are two issues here. Mailing lists don't really have a good solution with the first generation of stamps. The traffic mailing lists generate is fundamentally indistinguishable from spammers, therefore whatever hurts spammers will hurt mailing lists. The answer for right now is to not do anything with mailing lists. Let them send unstamped mail and let the user whitelist mailing lists or deal with the trapped message issue manually.
In the future, it will become easier to deal with mailing lists because of the second generation of stamps (opportunistic signatures). If the list is signed with its own stamps, then it would be let through without problem. Spammers would still be barred because their signatures would be ignored.
The second issue is that mailing houses that deliver bulk e-mail for legitimate commercial ventures will need to generate stamps for some of their traffic. If they are sending newsletters to which users have subscribed, then the signature stamps method will work for them. Everything else is advertising mail and should be stamped. A circumstance in the future can be envisaged where mass mailers will try to cheat and use signature stamps for mailing lists to deliver commercial e-mail. Obviously there should be some method of responding, but that is not yet apparent.
In the meantime, these houses will need to generate stamps. While most of their server resources will be maxed out, they'll have idle resources on the desktop. A technique is being developed that allows a company to make use of its idle resources to generate stamps for its outbound mail. It will be up to each organization to determine what machines it wants to use and how high it wants to load them. If it's bulk e-mail with no particular need to deliver immediately, then a small number of heavily loaded machines should be sufficient. If it's urgent corporate mail, then they will want to have more machine resources than are needed for stamps.
Re:Slashdot Spam Form Response (Score:4, Informative)
(*) Mailing lists and other legitimate email uses would be affected
One word, one hyphen: white-listing.
(*) Users of email will not put up with it
Why? It's not costing them anything
(*) Armies of worm riddled broadband-connected Windows boxes
Need an order more worm riddled boxes, i.e. ONE ORDER LESS SPAM.
(*) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
None have ever been tried.
(*) Sorry dude, but I don't think it would work.
Sorry dude, I think it will not solve the problem, but will make it appr. one order less effective.
That's covered in the Article. (Score:5, Informative)
The author points out that a) a date is added to the string to be hashed and b) a database is kept for the day of hashes already used.
If you include the hash when you pass it out, step a) invalidates hashes of older days and step b) keeps the current days hashes from being reused.
So it doesn't matter if the spammers share. The hashes are one-times.
Read the other link (Score:1, Informative)
Re:Right cause, wrong solution. (Score:5, Informative)
The general idea is that it will take a relatively small yet significant time to compute. So for example (also random) 30 seconds. Joe Sixpack will not notice 30 second delay on his computer for one email. However Jack Spammer who sends a million emails will need 500,000 minutes to compute the sums. A huge difference.... until you figure out that Joe Sixpack computer's spyware is what actually doing the computing.
-Em
Re:Greylisting worked for my company (Score:5, Informative)
And my boss is not happy when even ONE important mail from a client is not reaching him.
Re:greylisting is better (Score:3, Informative)
Last time I was forced to use the product, any error on the receiving end would result in the message getting dropped (with no notification to the sender). Though perhaps they've [finally] improved their SMTP gateway.
Re:Slashdot Spam Form Response (Score:2, Informative)
And this really doesn't require more work for you unless you want it to. The goal of this project is not to damage the mailing system that's already in place, allowing for incremental upgrades. At whatever point you think it's worth it for you to use this technology, you can, and get some improvement in spam filtering. If you never want to, you can still use other spam filtering techniques or, as other posters point out, you can use this technology as one factor in your bayesian filters.
Yes, if you're willing to do lots of extra work, this technology can give you complete spam protection, but it can still give partial protection with about the same amount of effort as you're using today.
I use hashcash (Score:3, Informative)
Just to give some practical information:
I'm using hashcash in its basic form, not with Camram. I wasn't aware of Camram until just now, but will probably look into it.
All my emails are sent out with hashcash, and I have SpamAssassin lower the score of emails with hashcash.
The recommended hash length is at least 20 bits. I calculate hashes of 23 bits (per recepient), which takes about 2/3 sec on my Athlon 800. My SpamAssassin config requires at least 20 bits to lower the score, and lowers it more and more up to 26 bits (at which point it has -5).
I think that this is the most effective use of hashcash: once it becomes widely used, then spam rules can become tougher with less chance of false positives.
From reading the article, it looks like Camram is mostly a recipient-side addon to basic hashcash, which involves automated whitelisting and sending challenges to senders of "maybe-spam". Somebody sending hashcash like me will (from the look of things) get past Camram recipients without problems.
Camram seems a bit less cooperative than I'd like, such as using its own Bayesian filter instead of letting the user have an external one like SpamAssassin take a crack at the email. But these are implementational issues, not problems with the Camram concept.
Re:And further -- why this will not work. (Score:3, Informative)
Under that system, you could make the stamps as much as a minute. Very few e-mails are written in less than twenty seconds, most take a few minutes. Really short messages go via IM. You still queue it to go after the stamp is ready to deal with the short e-mails, of course.
The reason this will not work is due to the way a typical SMTP connection actually works -
Steps:
1 - User writes email
2 - User sends email to their ISP's SMTP server
3 - The ISP SMTP tranfers message to destination SMTP server
4 - Destination SMTP server delivers mail to destination mailbox
5 - Profit (just kididng)
The checksum check will actually occur at step 3. Destination server will request the checksum from ISP's SMTP server - NOT FROM USERS MACHINE. Which means that the cost to large or even medium sized ISPs will be very significant. This means unless the end user machine will start sending email out directly to destination ISPs (bypassing step 2, a practice some broadband providers block to curb spam bots), this scheme will cost significant amount of money to ISPs in processing power. This also means that what you propose - calculation of the checksum on user machine during writing of the message is impossible.
True solution to the issue (or at least BEGININGS of a solution) should start with authentication of authorized SMTP servers for domains - like what Yahoo/Google/Microsoft & others were trying to do via DNS a few months back. (Whatever happened to that, BTW??)
-Em
Re:Won't work. Zombies will generate the stamps (Score:2, Informative)
The second attack utilizes zombies as a compute array. But if you run the numbers, you'll find out that the number of zombies known, if run perfectly and full tilt, cannot generate enough stamps for all of the spam in the world today. A tremendous number of stamps would be generated, but not enough for everybody. One benefit of zombies being used to generate stamps is that the machines will become hot, slow, and probably unreliable, all of which will be noticeable to the end-user. With luck, this means some people will get their machines fixed and reduce the zombie issue. Again, if the zombies the start generating stamps, one can always change stamp definitions or value.