On Wed, 21 Aug 2002 william@elan.net wrote:
1. I want to create specification that would allow server operators themselve to decide what kind of verification they want, if you do not like callback, do not implement it.
Ultimately, only the system that is flexible in this regards will succeed as a viable solution.
3. The processing is server cpu resource, while sending email is bandwidth used. I'll give up some more cpu resources to decrease used bandwidth.
The trick (and I steal this openly and completely from a recent thread on Cypherpunks) is make mail delivery computationally difficult - for the sender. This of course assumes that we are throwing out the fools gold of Hashcash itself. Presenting a computationally difficult problem to a connecting MTA moves the requirement for the CPU power to the sender while keeping the recipient site unfettered. Let's face it, the spam problem is merely one of cost shifting from sender to reciever, and this proposal shifts the load back. Any site that wishes to maintain the current system of email subsidies to the sender domain need only provide a computationally simple token.
4. For last years cpu speed & hardware have been increasing at 2x per 2 years and are more and more powerfull. Even if the initiative goes through fairly fast (I projected2 years, that is already too optimistic), it'll be another 4 years at least before its used, by that time servers would be 8 times faster!
Yet, all of this would not help the spam originating sites at all because of the sheer volume of mail they must send in order to turn a profit. Yours, J.A. Terranson