Pablo Alsina wrote:
On 5/28/05, Matt Fretwell <[EMAIL PROTECTED]> wrote:
<snip>
If this is not your preferred solution, how do you suggest to stop those scumbags searching for my user-database? Remember I'm not stopping spammers, I'm stopping user-db harvesters (probably future spammers).
My patch does this. And this is not a clear cut issue as you have no objective mechanism for determining what is plain and simple a wrong email address and what is probe attempts. All current mechanisms are subjective, to the tune of "If X bad rcpts, then probably probing" or "if bad Rcpts look to be random <-- (subjective), than it is probing"
So you can make educated guesses but there is no way to be 100 percent certain 100 percent of the time (or any other close value for that matter)
I would encourage you to use DNSBL blocklists intensively, they are currently the only (relatively) cheap mechanism for keeping unwanteds away from your system. (my patch works for those as well)
Of course you will also need to couple that with aggressive whitelisting. I would recommend you setup a DNSWL for that exact purpose.
One proposed solution was to run another SMTP box, redirect SMTP traffic to it, and stop those attempts there, either with tarpitting, or directly terminate connections that reach a certain ratio of bad rcpts (as Joe Maimon suggested with a provided patch). This seems OK, but introduces another single point of failure, as this works if I disable SMTP directly to my real box (no secondary MX register allowed).
No new box needed for my patch
The other thing with this is if I terminate the connection when a threshold is reached, what avoids having this client reconnect, and continue with its mission? The whole point of tarpitting is that it does not stop them, just make it more expensive.
sendmail rate-limiting of connection attempts. Interesting concept would be to prejudice rate-limiting code against "previous offenders", but in practice, I have found the current setup to be more than effective without causing ANY reported issues.
Regards. _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
_______________________________________________ http://lurker.clamav.net/list/clamav-users.html
