Leigh S. Jones wrote: > This is happenning to us all. It's not a DDoS attack, just a spammer > spoofing addresses at your domain.
Aha, thanks, that's good to know. Still, being a random target isn't any better than being a selected one. The problem remains: courier shouldn't choke, but does. 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. This would cause mail to keep flowing in, albeit perhaps at a rate slower than the incoming connection attempts. 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. 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. In other words, there seems to be a deadlock somewhere. Z ------------------------------------------------------------------------- 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
