On Wed, 2003-03-05 at 15:57, Gordon Schumacher wrote: > 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.
As you can see in the API doc I published last night (warning - it's a little long), extensibility is key to TarProxy. There are so many different ideas for ways to react to connected spammers that I don't expect to be able to keep up with all of them in the main codebase. If TarProxy produces easily parseable files and launches external programs or plugins based upon certain triggers, custom scripts can react to spammers at a much lower level than TarProxy - by running a bunch of iptables commands, for example. The more combinations of strategies employed, the more difficult it will be for spammers to detect and adapt. - Marty -- Marty Lamb Martian Software <mlamb at martiansoftware dot com>
