Slashdot Mirror
Beat Spam Using Hashcash
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.
The previous stories weren't enough?
In the future (if this takes off), these lists will simply contain the hashes along with the addresses. This temporarily makes the spammers lives a bit difficult, but doesn't have a long term impact.
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.
Your hair look like poop, Bob! - Wanker.
Thanks for RTFA
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.
(*) 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.
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.
You are checking your backups, aren't you?
Joe Sixpack wants to send a mail. If it takes him an hour to parse a key, he's not going to mail his mother anymore.
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
RelevantElephants: A Somatic WebComic...
Tried it at work - stopped loads of spam, but had to disable it because out there are too many broken smtp servers (on short inspection mostly lotus notes) that think an return code of 4xx is a permanent error and bounce the mail.
And my boss is not happy when even ONE important mail from a client is not reaching him.
c'ya haegar