To: Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com>,
asrg(_at_)ietf(_dot_)org
Thus, I think we'd need on the order of *AT LEAST* 10 ghz*minutes of
...
What is the minimumm speed CPU that you will allow to send mail? A
25 MHz 486 is at least 200 and perhaps 500 or 1000 times slower than
a 3 GHz P4. A 25 MHz 486 needs several minutes to generate 60
GHz*seconds of hashcash. You might fix the problem for mailing lists
...
You're still, I think foolishly, focused on an ISP-oriented
solution. Sender-pays makes them most sense when the client SW is capable,
if not singularly empowered, to enforce the payment mechanism at the
receiving point.
Ok, but what about the main question? What is the minimum speed CPU
that you will allow to send mail? Do you expect everyone from now on
to buy equal speed CPUs? How else do you ensure that the spammers
don't have CPUs that are 10,000 times faster than spam targets?
There are reasons why after at least 6 months the hashcash proposals
are still only ideas.
The reason is mostly that there are lots of arm chair generals but fewer
competent programmers.
I can't disagree; standards committees, netnews groups, and bars are
always filled with non-players eager to tell the players how to play.
However, a willingess to admit and deal with fundamental design problems
such as the span of real CPU speeds is part of being a competent
programmer. At the end of the day, competent programmers are those
who have programmed competently. How is your sender-pays implementation
working? How much of your incoming mail is sender-paid, and how much
is simply whitelisted? (If I'm confused about which solution you have
implemented, please forgive me and say how it is working.)
Only about 1% of the spam sent my way gets through my filters, but I
must admit that the DCC is applied to only the leavings of my static
filters.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg