On Sat, 22 Mar 2003, J.A. Terranson wrote:
> To date, my personal pet has been payment in computationally intensive
> solutions to questions posed by the recipient. This forced expenditure of
> effort, even if minor, removes the spammer's incentive for sending of
> email: the nature of the beast requires that the spam run be high volume and
> fast in order to pay off - slow down the run with computationally difficult
> questions, and the spammer will make no money.
There is a problem here. There are different machines connected to the Net, their CPU power often differing in orders of magnitude. Either you will completely bog down the 486s still used as low-volume SMTP servers, or you will use a 486-friendly formula that will get barely noticed by a P4 machine, or you will have some CPU speed negotiating protocol, which will rely on the other side not lying about who they are.
The idea if for stamps to be created at the client end. For most people that is not the SMTP server. Even for Web-based email, I envision the client being "encouraged" by the ISP to do the computation work on their own HW, perhaps via a Java applet.
We have to consider the very-low-end systems, eg. Nokia Communicators or various PDAs, which can send mail too. Either we rule them out, or we open a loophole, or we will implement a complicated classification system for the devices that will end up as awfully hairy and still half-working after unsuccessful attempts to iron out all its kinks and holes.
Using a PoW stamp regime low speed processors will either by enable to initiate contact with an unknown addresser or arrange for a third-party (maybe their ISP/cellular provider) to create the introduction stamp for them.
And you most likely lose the ability to send mails using raw telnet.
True.
Besides, can't you achieve something vaguely similar with simple tarpitting?
