Slashdot Mirror

• Let them send unstamped mail and let the user whitelist mailing lists or deal with the trapped message issue manually.

There's a reason that junk e-mail is a problem and junk paper mail isn't: the problem is that it's free to send junk e-mail.

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.

These's simply no reason to resort to kludge solutions that depend on penalizing those who cannot afford top-of-the-line systems.
What's the big problem? If it takes them 30 minutes instead of 2 minutes to calculate the hash, why is that such a big issue? They click the "Send" button, and then the calculation is running in the background.

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 you did generate a stamp for every user on every message, yes it would. Fortunately, we take a more usable approach. You only generate a stamp the first time you send e-mail to someone. The process of stamping and mailing also seeds the white list on the assumption that if you send e-mail to someone, you want to get e-mail back from them. Therefore, the load for stamp generation drops if you are sending e-mail to the same set of people on a regular basis; this can frequently be handled on an ordinary mail server. On the other hand, if you're sending e-mail to new people every time (i.e. you're a spammer or commercial advertiser) then you need to generate a stamp. Remember: strangers cost, friends fly free.

This is already covered on the Frequently Raised Objections page.

The Great Hammer of RTFA hits. --more--
You feel compelled to greater efforts of literacy.

The comment even includes a link to the Frequently Raised Objections page which specifically addresses these and a number of other issues. This page discusses specific points that made prior similar ideas were impractical and addresses how this new variant addresses those problems. If you can't emit anything more coherent than an uninformed knee-jerk response, then STFU!

I propose a compute-intensive stamp for posting to slashdot, instead of the retarded delays we currently have. Why not one of those obfuscated words, like when you sign up for a free email account? That way illiterate asshats like yourself won't clutter up the conversation!

jaz

The algorithm appears to be:

Does it have a stamp? If so, add to white list and PASS
Is it on the white list? If so, PASS
Does it pass a CRM114 check? If so, PASS
Otherwise, FAIL.

The information is on the configuration page. It ought, I think, to be in their FAQ.

Ripped right from their website's Frequently Raised Objections:

If anybody can generate a stamp, what is to stop a spammer from generating stamps?
Nothing. In fact, we want spammers to spend as much time as they can generating stamps because it will undermine their economic foundations. As a spammer generates messages with stamps, people can raise their postage based on the spam. Everyone's rates will increase and it'll only affect the spammer and stranger-to-stranger e-mail. Friend-to-friend e-mail doesn't use work stamps and will be unaffected by any postage increases. "

And....

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.
[all emphasis theirs]

It's almost like they anticipated this sort of thing. Or, like, thought out their design beforehand. Crazy concept, no ?


--LordPixie

RTFA, it handles mailing lists fine.

I'm reading TFA and it states quite clearly "Mailing lists don't really have a good solution"

From Camran's FRO

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.

You just have to love a product that has the potential to toast a clueless luser's computer. I would be more than happy to shell out good money for software that has "Makes PC's burst into flames" listed as one of the features. And this stuff is Free !


--LordPixie

They have a page with Frequently Raised Objections. Now I've made redundant 40% of the remaining posts to this article.

* Mailing lists. [...] if there is a way for legitimate mailing lists to bypass the challenge, then spammers can equally bypass the challenge.

Hashcash is generated for the mailing-list address. The recipient would add the mailing-list to their list of addresses they accept mail as, and a spammer can not send to the list without including hashcash. So the limitation for mailing-lists is that the spammer can send mail to many people (the list subscribers) for the cost of one stamp; if he sends directly he has to send one stamp for each recipient.

* Robot armies [of 0wned machines].

Clearly someone wit lots of owned systems can send lots of mail; but still less mail than they could without hashcash.

* Legal robot armies. [...] Large spam groups can afford purchasing hundreds of systems for distributing an computational cost.

They can do this (and doesn't matter with it's legal or not btw, they'll do it anyway), but it will cost them more per mail which will cost them, so they will send less mails and be economically incentivized to target their mails by buying demographic data etc. (eg. so you would be less likely to receive spams in languages you can't read, or on topics you are not interested in).

Another aspect is that legitimate users do not send mails to lots of new recipients; most email exchanges are conversations over a period of time with sends and receives. Some of the hashcash based systems use hashcash only for introductions, and exempt recipients from hashcash after that based on crypto tokens (or just whitelists) (eg CAMRAM, TMDA do this).

The argument here is that hashcash can be set to higher cost as it is only borne once per new recipient for normal users.

The classic problem that is used is the square root. In terms of time, it is very easy to verify a square root given both the question and the answer, but rather more expensive to generate it. This is the kind of solution used by other organisations looking to deal with spam, like Camram. They are using a slightly different method involving hash collisions.

The camram project is very close to releasing 0.2 which will make available a hybrid sender pays system which will work for systems handling a single user through a few hundred users. With this release will also come the information of how to convert any content filtering antispam defense into a hybrid sender-pays system like camram.

As of today, 3 systems support sender-pays using hashcash: gnus, spamassassin, and camram. it's important for more systems to support an open standard for sender-pays. So if you are deeply involved in an antispam content filter, please consider adding hashcash as part of the system.

check out http://www.camram.org http://www.hashcash.org

I support groups like CAUCE in spirit, but IMO spam is not a political problem. It is a technological problem of ancient protocols that are long overdue for an update. So if Yahoo or some other big player chooses to promote a custom protocol, let's hope that it is functionally equivalent to AMTP.

Of course, I foresaw all these things back in April. It's flattering to see that Yahoo is reading my Slashdot postings and taking heed, and only provides more support for my quantum theory that our universe is constructed from my perceptions. :-)

-Gonz

a thing to remember is that if someone can prevent a spammer from communicating based on identity (or lack thereof), you can be silenced as well.

This is why I have put my efforts into sender-pay systems and specifically the camram project. We invite you to please come and join us in the effort to build a decentralized, user-friendly, freedom-of-speech supporting antispam system and hit spammers in the pocketbook.

camram antique documentation (too busy writing code to write new documentation)

It doesn't require a micropayment solution

It doesn't require a central registry

An additional benefit is that for small senders the cost remains negligibly small -- perhaps 2 seconds per e-mail address sent to. For spammers 2 seconds per e-mail address is a huge burden. If you're trying to mail to 10 million addresses, you need 231 hours of processor time to compute the hashcash "stamp" required for all the address. It's not an impossible feat, but if a spammer needs to set up server farms just to compute stamps their profit margins shrink signifigantly.

Group working on an implementation of hashcash

See for example hashcash and camram

The folks over at Camram (the hashcash people) are trying to work out how to bodge hashcash negotiation onto the existing mail system. It sounds like it's a pain to get right.

If we had a new, shiny, protocol designed so that there was some negotiation before the message was collected by the receiver, the hashcash payment could go in at that stage. People who don't pay don't get their messages collected.

It's like junk faxes: in countries with free local calls, junk faxes are a much bigger problem than they are where local calls cost the caller.

Similarly for being called on cell phones with by marketers. In some countries calling a cell phone is free for the recipient and all costs are on the caller.

So while it is true that hashcash would use some CPU on the client, the amount of CPU used would be small enough to not present a noticeable problem for the sender who sends some sane number of mails per day.

The problem as I see it is deployment, as the first message in the thread "Slow acceptance if ever" puts it. ie If I use a hashcash filter on my received mail then I may lose mail if senders don't follow whatever steps are necessary for them to get their mail to me.

This is what the camram list is about -- making it reasonable for senders to send mail to people using hashcash filters, when sender has no client. For example there is a proposal to require hashcash only on the first mail, subsequent mails would be exempted. There is a simple web page with a java implementation of hashcash.

(The are proposals to deal separately with mailing lists where the recipients wants to receive the mail, and the list has to send lots of mail).

Another approach to reduce the deployment problems is to do it in two phases. In phase 1 hashcash filtering is advisory only (bounce messages on mail having no hashcash if any would just encourage sender to participate but not reject mail; filtering would improve priority of mail, not delete mail without postage); in phase 2 if phase 1 was succesful enough the filters could start bouncing mail without postage.

Will any of these approaches reach sufficient deployment to be useful? I don't know. That's what the camram group are working on.

There are also other applications of hashcash (other than email spam) in combatting DoS which have been succesfully deployed (see the paper).

The Campaign for Real Mail is working on a solution to the spam problem based on HashCash and PGP. Once the technique is perfected, the idea is to build the utilities to make it ubiquitous. Details can be found at http://www.camram.org/.

So stop whinging about spam and start stopping it.

Yours truly,
Mr. X

...spiced ham...

This means that if you're running a mailing list, the initial signup procedure (where you confirm that the address you've been given really did want to sign up, by sending them back an email) will do the key exchange, so after that you're only doing some crypto rather than a hashcash calculation. Still more expensive than conventional email, but not deliberately expensive.

For an example of a cryptosystem which works in this way, see Herbivore