zcat wrote:
My thoughts, after a 10 minute perusal of hashcash :)
Hashcash is (imho) a stupid waste of time. It unfairly penalises people with slow computers who might want to run a mailing list (me!) while barely slowing any spammer who happens to control a vast network of virus-infected home computers (most of them). And, like most spam 'solutions' it requires a complete reimplimentation of the entire mailsystem.
If you think that 'raising the cost of mail' is the right approach, tiergrube(sp?) would be a much fairer (and more transparent) way of doing it.
Tiergrube really doesn't work that well when you realise that: A) SMTP servers have pipelining, so you can send "ahead of time" B) SMTP works over TCP which has a window of 32k to 64k depending on the implementation. C) Spammers use their own SMTP clients. This means you can send up to about 32k of data to an SMTP server and then "forget" about it. You'll note that you can easily fit your spam into this limit. Tiergrube is nice that it doesn't change anything today, however it's as much of a kludge as anything else. This is a reciever-side solution. SPF is nice, and supports saying "emails from this domain must be signed by GPG" (rather than must arrive directly from this address) which gets around the major problem of SPF (you can't use mail forwarders). SPF presumably can also say that email must be hashcode'd. This is a legitimate-sender-side solution combined with a reciever-side solution. Hashcode is a nice legitimate-sender-side solution. You can say a mail is more important based on how much CPU time you spend on sending it, combined with a reciever-side solution. Hashcode doesn't have irritating problems with overloading the meaning of DNS records, or with forwarding email. Spamassasin is a reciever-side solution that supports hashcode and SPF. The thing to notice here is that reciever side solutions get better traction, and sender side solutions tend to be what everyone wishes were used. This could be flipped around in a hurry if someone like gmail decided to sign all email that comes from gmail, and/or use hashcode, and perhaps SPF. (hey! gmail DO use SPF!) The problem here is that someone like gmail will need a LOT of cpu to do proper hashcode, and this is perhaps one place where the model falls down. Perhaps the solution here is to use a java applet to do the hashcode calculation so they can "farm" it out to their users. In general I think the answer is to the spam problem is not any one solution, but a lot of solutions working in tandem. Have some tiergrubes around the internet, everyone using SPF, hashcode, GPG, have good laws protecting people from spam.