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.
Hashcash got me arrested... (Score:5, Funny)
Re:Hashcash got me arrested... (Score:5, Funny)
Work for it? (Score:2, Informative)
hashcash.org is down..? (Score:3, Interesting)
Please post mirrors.
Again? (Score:4, Informative)
The previous [slashdot.org] stories [slashdot.org] weren't enough?
Re:Again? (Score:3, Funny)
HashCash? (Score:4, Funny)
Slashdot Spam Form Response (Score:4, Insightful)
(*) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(*) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(*) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
(*) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(*) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(*) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
Re: Slashdot Spam Form Response (Score:5, Insightful)
Re: Slashdot Spam Form Response (Score:3, Insightful)
But the mailing list server would have to take on additional load since they send mail to so many users.
And using zombies to do the hashing has a point as well, although the author points out that loading the zombies with additional work isn't such a bad thing
Re: Slashdot Spam Form Response (Score:3, Insightful)
-Complexity
-Time (not as much as doing it by thyself, or it would be pointless)
-Something that can be used as a unique trait to distinguish zombies from normal machines
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.
Re:Slashdot Spam Form Response (Score:2, Insightful)
(*) Mailing lists and other legitimate email uses would be affected
One word, one hyphen: white-listing.
"""
One word, one hyphen: header-forging
"""
(*) Users of email will not put up with it
Why? It's not costing them anything
"""
It costs them CPU cycles.
"""
(*) Armies of worm riddled broadband-connected Windows boxes
Need an order more worm riddled boxes, i.e. ONE ORDER LESS SPAM.
"""
What language is that in?
"""
(*) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
Re:Slashdot Spam Form Response (Score:3, Insightful)
For normal use (except mailing lists), the cpu-cycles to calculate the hash are non-consequential. Modern day computers are too powerful for everyday needs anyway, who cares that it takes 20 extra seconds to send a single email, if its done in the background, no one would notice. If you need to send to 100 addresses, it takes 2000 seconds, still no big deal.
What language is that in?
Mathematical English.
If so, it's
The real problem here is not header forging. (Score:5, Insightful)
Re:The real problem here is not header forging. (Score:3, Interesting)
Re:Slashdot Spam Form Response (Score:5, Insightful)
As a USER of email, I find the need to maintain a white-list simply because spammers are fucking assholes is UNACCEPTABLE. I won't do it. Right now, my Bayesian filters completely hide spam from me. I will not move from that system to a system which requires MORE WORK FOR ME, i.e., maintaining a whitelist.
Feel free to sit there and feel smug about your "solution" which requires you to waste your time.
I find that the people who most strongly advocate sender-side blocking, like HashCash, invariably are network administrators who don't want "their" bandwidth wasted. Guess what: I'm a customer. It's my bandwidth. I really don't give a fuck if spammers are violating the sanctity of your precious network. I am only interested in not seeing spam, not thinking about spam, and not worrying about spam. HashCash is a horrid solution in those respects, and I won't accept it.
Put it this way (Score:3, Interesting)
Someone with a valid stamp is less likely to be a spammer. Simply include it as a factor when calculating probabilities!
Or ignore the X-Hashcash field completely. As you choose.
If you read the article, you'd see that this was precisely the way in which SpamAssassin uses hashcash [ibm.com] : as one factor amoungst many in a general system of spam classification.
Re:Slashdot Spam Form Response (Score:2)
The 'bayesian' filters are actually very naive. Spammers do get through to them. For me it's about 10% that gets through. This still amounts to about 20 emails a day that I have to throw into m
Re:Slashdot Spam Form Response (Score:3, Insightful)
That's nice as far as it goes, but I think you may be failing to consider what happens behind that Bayesian filter hiding all the spam from you. Your bandwidth is being consumed by spammers; you
Re:Slashdot Spam Form Response (Score:3, Insightful)
Just because you can't see it personally, doesn't mean it isn't affecting you behind the scenes. It is.
Most large ISPs have to maintain a full-time staff dedicated just to handling abuse issues like these. Who do you think is paying their salary?
Re:Slashdot Spam Form Response (Score:2)
If this is the answer to that objection, why bother with HashCash at all? Why not just use an "accepted sender" (white-list) to block out all of your spam?
Re:Slashdot Spam Form Response (Score:2)
Re:Slashdot Spam Form Response (Score:2)
He he he. It reminds me of .. (Score:2)
grab a backbone (Score:2)
If it works, users of email will put up with it.
Ideas similar to yours are easy to come up with, yet none have ever been shown practical
The only argument I see against the practicality of this solution is the point above, which is circular. An argument which depends upon a circular argument is also circular.
Armies of worm riddled broadband-connected Windows boxes
In my opinion, this is a strength of hashcash rather than a defect. Consider the ratios. I send maybe a few hu
Re:Slashdot Spam Form Response (Score:3, Funny)
Leave the poor misguided fools alone. Seriously, if they're putting in the effort to do this anyway, just let them try. They can even start demanding HashCash if they want - and it's their problem when the rest of us just decide it's not worth the additional effort to send them email.
Your idea will not work. Here is why it won't work.
There is one foolproof approach to ensure you never, ever receive another spam email again. Shut down your mail serv
Re:Slashdot Spam Form Response (Score:3, Insightful)
* Messages come to you rather than you having to go to them (server push rather than client get, and depending on the list, this can mean basically real-time receipt).
* Easy offline access to the messages
* Not subject to network restrictions in almost any company
* Can be delivered directly to portable devices (eg, Blackberry)
* Can be alerted based on criteria (alert me whenever I see Critical Flaw in
Right cause, wrong solution. (Score:2, Insightful)
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.
If a spammer has to spend an hour processing the key, he's just going to invest more of his time getting zombie PCs to get the work done for him.
Who wins here? Certainly no one.
Disclaimer: the hour was used as an example. I've no clue how long it takes, but the point should still hold.
The moral being, don't make the end use
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:Right cause, wrong solution. (Score:5, Insightful)
Re:Right cause, wrong solution. (Score:2)
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 t
Re:Right cause, wrong solution. (Score:2)
Joe Sixpack will take a second, maybe two to send the e-mail. I doubt that he could type fast enough for this to be an issue...
Now, a zombie can only send one e-mail every second vs. the usual ten. Not perfect, but I would settle for 3 spams per day vs. my current 30.
Yes, it does require some changes to e-mail software, but the article points out that the changes can be slowly phased in. If an e-mail client includes the code and this idea never catches on, then the worst thing to happen is that t
Re:Right cause, wrong solution. (Score:2)
Re:Right cause, wrong solution. (Score:2)
You obviously don't know many PC users. Everybody I know just buys a new computer when theirs "gets slow" figuring that there are some mechanical parts that are simply wearing out inside of it. If zombies start having to work harder, Joe Sixpack will just go buy a shiny new Dell.
Re:Right cause, wrong solution. (Score:2, Interesting)
I d
Stupid idea (Score:3, Insightful)
For example, Sourceforge sends site-wide update messages about once a month or so. They have tens, if not hundreds of thousands of users. If every one of those users used HashCash, Sourceforge would practically need a dedicated server farm computing hashes simply in order to send out its update notices.
This is a really, really stupid idea.
Re:Stupid idea (Score:2, Insightful)
Re:Stupid idea (Score:3, Insightful)
Shit, pun not intended.
FP.
Re:Stupid idea (Score:2)
"v=spf1 mx a:mail.marblehorse.org a:sshgate.sourceforge.net a:smtp.vasoftware.com a:newcastle.devrandom.net -all"
Problem solved.
Re:How about.... (Score:2)
Re:Stupid idea (Score:2)
Re:Stupid idea (Score:3, Insightful)
Don't you already get "magic emails" and go through a convoluted process for most mailing lists to confirm that you want to be on the list?
POPUP: "Do you wish to receive mail from the sender 'V|4GRA-= CIA7IS =CHEA
Re:Stupid idea (Score:2)
Re:Stupid idea (Score:2, Insightful)
Blah. Whitelist it if you want it.
Re:Stupid idea (Score:2)
Sorry. I refuse to waste my time maintaining such a list simply because spammers are assholes, and those who advocate HashCash are blind. Instead of being happily unaware of spam as by Bayesian filter silently tosses it, I now have to consciously manage a white list.
No thanks.
Not so stupid idea (Score:2)
Whitelisting is a simplifying concept, which one can understand more subtly as another factor to be accounted for in calculating probabilities, making your Baysian engine that much more efficient.
Re:Stupid idea (Score:2)
Re:Stupid idea (Score:2)
Are you trying to suggest that if spam were eliminated, the price of bandwidth would suddenly drop dramatically? Instead of jacking my rates up each year, Comcast will actually start decreasing them?! Wow, where the hell do I sign up?
Ain't gonna happen, so where's my incentive?
It's easily solved (Score:2, Funny)
It's easily solved. Just buy the CD of pre-calculated prime factors from the spammers.
Hashcash is a whitelisting protocol (Score:3, Insightful)
Only unsolicited mail needs a hashcash field.
now what? (Score:3, Funny)
I had to quit smoking... (Score:5, Funny)
cf Penny Black (Score:4, Interesting)
Oh yeah, so there is [microsoft.com], along with papers explaining how it works. So much for giving credit for prior work.
Re:cf Penny Black (Score:3, Insightful)
This article is about the first correct (supposedly) Python implementation of hashcash.
Won't work. Zombies will generate the stamps (Score:3, Interesting)
If you want a virus built to generate stamps on zombies, just go over to Spamforum.biz [spamforum.biz] and advertise for one. New ads over there this week include "PushMail Webmailer v1.0.2 ~ New, Fast WAP Webmailer for Sale (Gets by Filters)". There's even a banner ad for a firm that wants spammers [s-rx.com]: "3 different sites - Pharma - OEM - Cigarettes".
Re:Won't work. Zombies will generate the stamps (Score:2)
You're right, but putting additional CPU load on zombies isn't such a bad thing, is it? Spammers pay for zombies so it still increases their actual costs.
This idea actually has merit. Admit it.
Re:Won't work. Zombies will generate the stamps (Score:2)
Basically, the click-through license will make you agree not to sue anyone affiliated with the site, or any contributors, etc. Leaving out the question whether click-through is valid, this is not something that I would want to risk.
I advise anyone that is concerned against spam, and possibly want to contribute to the fight against spam at some point, to not enter this site , if you want to avoi
Re:Won't work. Zombies will generate the stamps (Score:2)
It would be great if they sued. They'd have to disclose their identity.
Greylisting worked for my company (Score:5, Interesting)
Basically what it does is temporarily block suspicious emails. If it's a real SMPT server it will resend the message and the second time it will be allowed to go through. Spammers never use RFC compatible SMTP servers and simply send once in bulk and forget about it. This cut down our spam by over 90%.
Re:Greylisting worked for my company (Score:2)
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.
That's Odd (Score:3, Interesting)
It's a temporary bandaid, not a solution (Score:5, Insightful)
Spammers never use RFC compatible SMTP servers
And spammer tactics remain static, so the same techniques that worked five hours or five years ago will continue to work indefinitely. Not.
Reactionary hyperbole (Score:3, Interesting)
You're being silly. I dare wager that I've expended considerably more effort in administering email systems than you have. But just to be clear : I *want* to solve the problem of Unsolicited Bulk Email. *Solve*, that is, not mitigate. And re-read my post. Would you conclude from it that I don't use such tactics on my own mail servers? Or indeed a range of other measures that sure, work quite effectively today, but likely won't work tomorrow?
Another example : some spamware chokes on multi-line 220 gr
How many numbers would that be? (Score:4, Funny)
Fur sail 2 u nou: 5 mil-leeun facter numberz
Yuz cun b-u-l-k f4ster wit dis CD uv all-ready calcoolated leest uf numbors. Fer onlee $99.95, u getz ohver fiv milyun numz ant wee tos in freeee a miliun fresh A-O-L addys. Vizut us @ hotprimefactors.biz to ordur.
can't stop it.. (Score:2)
Re:can't stop it.. (Score:2)
Waste of perfectly good CPU time (Score:3, Insightful)
Maybe for once zombied Windows boxes will be more productive than they would be under their users' control.
Re:Waste of perfectly good CPU time (Score:2)
And how *exactly* does the receiving mail server verify the work unit without computing it itself?
Besides, doesn't dropping spam via other methods typically involve network traffice to blacklists and CPU cycles spent?
Face it; the time is already wasted with other methods. Unless you have a real reason to nay-say it? Pony up!
Re:Waste of perfectly good CPU time (Score:2)
It depends on the task. For solving large systems of non-linear equations, just evaluate them with claimed values of the variables. And just because CPU cycles are wasted now doesn't mean they can't be put to good use in future. That's how distributed computing projects started in the first place.
Re:Waste of perfectly good CPU time (Score:2)
Solution also ignores... (Score:5, Insightful)
These's simply no reason to resort to kludge solutions that depend on penalizing those who cannot afford top-of-the-line systems.
greylisting is better (Score:3, Insightful)
http://slett.net/spam-filtering-for-mx/greylistin
and/or:
http://projects.puremagic.com/greylisting/ [puremagic.com]
In a nutshell, it simply uses a standard 451 SMTP response that says "Hey, I'm busy now, can you call back in a minute or so?" To my knowledge, all standard SMTP servers respect this request, and little to none of the mass mailers do. And if they do, their bandwidth will triple.
Here's a log example:
Oct 15 15:18:17 example1.example.com sendmail[6955]: [ID 801593 mail.info] i9FJIGH06953: to=, ctladdr= (168/601), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=121994, relay=example2.example.com. [123.390.141.456], dsn=4.3.0, stat=Deferred: 451 4.7.1 Greylisting in action, please come back in 00:01:00
If the mail never comes back, then the sender is now blacklisted. If the mail does come back, the sender is whitelisted.
Simplest and most standards compliant thing that I've heard of, and it seems to work.
Re:greylisting is better (Score:3, Insightful)
-Em
Re:greylisting is better (Score:2)
It kills off all of the owned windows machines, and triples the bandwidth of the spamhouses that just so happen to use standard compliant SMTP servers.
Oh, and its not too tough to move someone from a whitelist to the blacklist.
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.
Solvable (Score:2)
If you're using the hash space uniformally, then armies of infected Windows PCs will take just a couple seconds per e-mail. What does the spammer care? Those CPUs are free/cheap. Just means it's time t
Fair Use of Shared Resources? (Score:2)
I don't get this. It will just lead to a general slowing down of the services running on the Internet.
Where do people think that email is being sent from? A dedicated server that the user has somewhere dedicated solely to sending email?
Most people will be sending email through their ISP. And ISP that was coping with x,xxxx,xxxx pieces of email a day will suddenly now have to redo their email architecture to cope with the extra computational cost involved.
Other people send email using their webhost.
Complex Solution...Overly Complex... (Score:2)
waste of time (Score:2)
Okay, some thoughts on the FAO... (Score:3, Insightful)
I consider mailing lists a cute throwback to a much earlier time. Don't get me wrong, I subscribe to three or four myself. But every single one of them, I could just read on-line (and no, not all Yahoo lists, only one in fact).
To effectively eliminate spam, I would gladly visit a web page rather than have the same info appear in my mailbox.
Er... How does that differ from actual spam? I don't give two shakes of a rat's ass whether or not UCE comes from a "legitimate" source. I don't want it. Any of it. So, it really doesn't bother me that, for the benefit of no more "Free v1@6ra" email, I also lose out on "buy our totally legit ink cartridges" at the same time. I consider it a perk, not a problem.
acceptance (Score:3, Insightful)
Quick grep on my mail archive (which is HUGE) failed to find single message with X-HashCash header. That means even if I would enable it now, it will be practically useless.
Of course wide acceptance could be achieved by the means of widespread grassroots campaign, but this is hard way. If somebody big like GMail, Yahoo Mail or MS Outlook or Apple Mail started to use it , that would have snowball effect.
People at Best Buy (Score:3, Funny)
They've been telling people for YEARS that anything under the top-of-the-line computer won't be able to send email or brose the internet!
Hashcash....hmmmm.... (Score:4, Funny)
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.
Another Stupid Suggestion (Score:3, Interesting)
Adoption will be slow. Many companies already have maxed out mail servers. Adding even an 1 second compute cycle to all outbound mail requires a fairly hefty increase in available resources, especially since most mail systems are chosen for bandwidth and IO not math processing power. What happens to a system during peak business hours when 100 people send mail with an average of 5 recipients each ... 500 seconds of computing ... ummm. Imagine a company that sends 5000 messages an hour, or 50000, or ...
If it's not at least a second on a reasonable machine than it's not going to cause ANY headaches for a spammer -- they are just text pumps they can send SO much more mail than a normal server because they don't care about logging, errors, bounces, rejects and retries.
The "use clients inside the company" idea is idiotic -- my mail server is going to punch through the DMZ directly to the desktop of my accounting staff and ask it to generate a key? I don't think so. There is a reason every company with any brains bans Seti/IM/etc. from their internal desktops.
Zombie writers will just interleave writing packets of the current message with SHA-1 calculation for the next message they are sending. Spammers have some really good programmers on their side. If you don't think of them as being at least as good as you are then you have already lost. They are already generating random text at the front and back of the payload, this isn't SHA-1 thing isn't a big deal.
Like SPF, spammers will be the FIRST people to generate proper keys. For the near future a valid key will be a STRONG indicator of spam not a "potential whitelist" feature.
Practical usage scenario (Score:3, Interesting)
I personally stamp all of my outgoing e-mail with 20 bits of hashcash postage. It's easy to do and requires very little CPU time. Here's how I do it:
I have stunnel listening on port 465 which forwards connections to MEsmtpd [edenhofer.de]. After authenticating the sender, MEsmtpd pipes the message to hashcash-sendmail [toehold.com] which adds 20-bit stamps for each recipient to the e-mail and passes it on to sendmail. I don't have to do anything at all in my e-mail clients. There you have it, easy as pie.
Regarding that stupid "your spam solution won't work" checklist, Spam classification is a hard problem. It can't be solved by any one approach. Even though Hashcash won't stop any spam, it can still make your spam filter more effective.
P.S. SpamAssassin supports Hashcash. See Mail::SpamAssassin::Plugin::Hashcash.
Re:This doesn't *stop* anything (Score:5, Insightful)
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:This doesn't *stop* anything (Score:2)
So the key would be having the computation be based on the send
Re:This doesn't *stop* anything (Score:2)
The question is different for each transaction. Duh. Please this idea is dumb on a host of levels and has been covered many times. The biggest issue is that sooooo much infrastructure (mainly software) has to change. So can we just say that this is another one of those CS discussions - interesting in theory - that will go no where anytime soon.
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.
Re:This doesn't *stop* anything (Score:2)
Nope. From my experience, that's not true. These are crooks...selling to crooks. If they sell bad data -- and I'd bet they do -- why would they care and how would the buyers of these lists know the difference?
Reason: About 1/2 of the spam messages I get are to addresses that are total fiction; they have never been used anywhere. Of the commo
Re:This doesn't *stop* anything (Score:2)
It's a non-issue.
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 mailin
Re:Won't Stop Virus/Worm'd Zombie spamming (Score:2, Insightful)
On average, the 1000 zombies will have an average CPU equivalent to a P4. Add to that network latency and all the work that has to go into coordination, and the equivalent CPU power goes down.
So if a spammer had 1000 zombies, he'd get at best a 1000 hours of work in 1 hour, and on average maybe a 100. To send a million emails, even under the best conditions and using the two or three second hash-compute time, he would need approximately 555-833 hour
Re:Won't Stop Virus/Worm'd Zombie spamming (Score:2)
Re:You asked for it - the spam rebuttal!!! (Score:3, Interesting)
Except that Microsoft are *ahead* of the hash cash scheme. They've developed a scheme that does the computation with something memory intensive.
Main memory is much much slower than the CPU and the difference in memory access speeds in a cell phone and a PC are much less than their CPU speed.
Memory based computations are harder to run in parrell. In principle you could have many computers working on signing a single message.
They've made is very difficult to run their