On Wed, 29 Jul 2009 18:55:40 -0400, Sam Varshavchik <[email protected]> wrote:
>> Sam, >> it seems this kind or problem is becoming more common. May be you >> should >> think in some other aproach to face this. May be some runtime >> configuration >> option where we could set submit to end the smtp handshake and realease >> the >> socket when a blacklisted IP is found (as some other errors like user >> unknown, SPF hard error, relay denied,...). > > I'm slowly beginning to lean this way. Things do change over time. Perhaps > it makes sense to do something like this now. I think I will implement > something like that. Sam, I'm already doing following with my script (http://robert.penz.name/smtpiptablesblocker/) which is complete in line with your statements last week to me. Wait for spammer to send the mail, answer with an 511 and than add the IP to the firewall for 10min and drop the connection. I'm using this for some days now and works nicely. The changes in courier would be really minimal and will not effect legitimate senders, as a IP thats in a DNS RBL will there also be in 10min - so why accept the connection after the first bounce at all. A switch (to a minimal blocker process) before forking the smtpconnection and submit process would be even better but thats would also take longer. Sure the long time solution should be something like this, best together with iptables. -- Regards, Robert ----- Robert Penz ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
