Sam Varshavchik wrote: > Marcus Pereira writes: > >> and the courieresmtpd process stay locked for hours. I am loosing this >> game. I already blocked more 500 /24 nets but the number of locked >> connections keeps raising until I restart esmtpd. > > I have several thousand spam sources blacklisted. I am just a couple of > vanity domains. You are a large provider. > > The recommended way to address this situation is to set up a script that > monitors syslogs, and flags IP addresses that log more than X errors in > Y minutes, then firewall them.
Do you mean _any_ error? I'm only catching imap/pop3 errors: since I see the SMTP daemon does its own tarpitting, I thought it's better not to interfere... Actually, I've tried and block spammers' sync requests after they send to a spamtrap, but their footprint is so light that I don't gain much that way. However, since you recommend firewalling, wouldn't it be advisable to configure some kind of callback for flagging IP addresses? It seems that monitoring syslogs is where one spends most of the cpu time. > With Linux, you can insert an iptables > rule that rejects *out*bound packets to the blacklisted IPs in a manner > that the sender, in this case courieresmtpd, thinks that the connection > is broken and exits out, releasing the socket. Meanwhile the sender > still remains tarpitted, thinking that the socket is still alive. Hm... blocking outbound so as to induce tarpitting apparently only affects what the server inflicts in retribution. If I understand well, blocking just (future) sync requests from the same IPs would result in similar figures for the attempted connections to port 25. Correct? > That, and a lengthy timeout before the iptables entry gets removed, so > that the iptables does not grow without bounds, should do the trick. I guess you mean more than a few minutes timeout... Hours? Days? >> Other strange issue that start happening is lots of "writev: Broken >> pipe" errors. May be its related to the Zombies, but I have seen this >> error happening on normal smtp connections too. > > This is harmless. It means that the sender dropped the connection while > Courier still had something to send it. Poorly written SMTP senders are > sending you a QUIT command, but don't bother wait for Courier to > acknowledge the QUIT and orderly shut down the socket. Does that mean one shouldn't block based on this error? (Well, blocking outbound packets should be a no-op at this point, but what about blocking future sync requests?) Finally, it looks like you use netfilter. May I ask what userspace program do you run to issue verdicts? I had been looking for such utility, but eventually had to roll my own one... ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
