I'm just idly curious (like you I have zero confidence in
proof-of-work schemes) but why wouldn't they all be equivalent to
"don't send me your next command for (at least) N seconds or I'll
drop the connection"?
No, because "wait for N seconds" is parallelizable across many
connections, whereas "do N cpu-seconds of work" isn't.
At the root of one of the problems with p-o-w schemes is that there is
no easy way to tell what constitutes N cpu-seconds of work for the SMTP
client, so instead a problem of standardized hardness is substituted
(eg, "find a data block containing this random cookie whose SHA-1 hash
begins with N zero bits")....
Or for that matter just don't respond with a 250 to their HELO for N
seconds and if they continue talking anyhow drop the connection
Yes, that can be very effective. (It will stay that way for a while,
too, until ratware authors implement one of the possible workarounds to
it...I'm already trying to think of workarounds and defenses against
them, against that day.)
That's fairly easy to implement and how can a conformant MTA
distinguish a sneaky delay from a slow network?
It can't. But that's not what p-o-w schemes ask for; they ask for a
solution to a nonce problem of whatever hardness the server demands.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML
mouse(_at_)rodents(_dot_)montreal(_dot_)qc(_dot_)ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg