Tarproxy, on the other hand, is proactive -- it stops the open relay the very first time it goes to work.
Excellent point; I suspected that there must be some good reason I was overlooking (which is why I posted the question.
On the other hand, if a critical mass of tarproxy installations were reached, it would help everyone, even non-users.
This is absolutely true; however, due merely to human nature I doubt that a critical mass of any given tool is likely to be achieved in any reasonable timescale. (And by the time that timescale is reached, the tool will be obsolete...)
Perhaps this is overly cynical, but there it is.
The next question is still back to the former, though; let's see if we can figure out a way to make it even more painful for them. I think that selectively dropping TCP packets is a good idea, as long as it's not turned on by default. (If it is, the uninformed will think that tarproxy sucks down their bandwidth.)
I think that giving SMTP responses that make them go away should also be a non-default behaviour; it kind of defeats the purpose of the "tar" part of tarproxy - assuming that the idea is to make them stick around for as long as possible, wasting their resources.
