Zenon Panoussis wrote: > > Enda Cronnolly wrote: > >> I would hazard a guess that you have either ran out of pre-configured >> available threads for esmtpd to listen on (in which case increasing the >> limits will help) or your system has run out of available resources to >> provide esmtpd with new threads. Its the only logical reason why esmtpd >> can't answer requests. > > You might be right, but there's something with this reasoning that I don't > grasp. Whatever resources courier has, small or big, it should be using and > re-using. So let's say it can only start five threads; it would then do so, > accept five connections, deal with them, close them down and then accept > the next five.
Yes, it will do that. However, when mail servers connect to courier's smtpd and send RCPT commands with invalid users (or any other error), smtpd starts tarpitting them -- after each failed command, it waits for an increasingly long period of time before it replies and reads more commands. This feature of courier prevents dictionary attacks against your system. In your case, the mail servers sending you backscatter continue to send commands for a long period, which means that it takes a long time for courier to free up slots for new connections. What you're seeing is not a bug in courier. > This is not the case though. What happens is that courier accepts n > connections, deals with whatever is coming in on them (accepts it or bounces > it), and then stops accepting new connections indefinitely, until restarted. > This would suggest that the processes started are not properly terminated, > because new ones should be started when the old ones finish, but are not. > So either something is wrong with courier, or my understanding of how new > processes are respawned is flawed. You're simply wrong about what's happening. You can see open connections with either 'netstat' or 'ps'. Use 'tcpdump -A' or 'ethereal' to watch traffic on those connections. > Gordon Messmer wrote: > >> You don't need more authdaemons, just more esmtpd processes. Increase >> MAXDAEMONS, but not MAXPERC or MAXPERIP. > > I've already been there. They are now 40, 5 and 5 respectively. The 40 seem > to roughly correspond at the number of accepted connections after each > restart. > But with the behaviour I see, increasing the daemons only leads to a higher > number of initial connections before courier stops responding. 40 is the default -- pretty low. I use 120 for low-traffic servers. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
