On 8/5/2012 10:53 PM, /dev/rob0 wrote: > On Sun, Aug 05, 2012 at 07:48:56AM -0500, Stan Hoeppner wrote: >> On 8/4/2012 10:08 AM, /dev/rob0 wrote: >> >>>> postscreen_client_connection_count_limit = 10 >>> >>> I'm not sure why you did this. Some MTAs, notably qmail, are >>> likely to assault you with many simultaneous connections. This >>> non-default setting might cause difficulty at times in receiving >>> legitimate mail, albeit from impolite clients. >> >> This slows legit clients down no more than greylisting does as it >> simply returns a 4xx to each excess connection. >> >> If you think that's harsh I limit concurrent connections to 4, >> though I'm doing so with smtpd as I don't use postscreen. It >> works very well. > > Fine, I was just asking. I will take your word for it. That's one of > those default settings I have never touched.
The purpose of this is to 1. Keep a single host or a small group of hosts that are hitting you simultaneously from flooding your inbound queue and bogging down your storage. When inbound writes soak up all the IOPS, your outbound queue fills up and deliveries are delayed. Two users asked here about this exact problem in the past few months and in both cases tweaking this setting fixed their queue problems. 2. Prevent such hosts from tying up all of your smtpd processes, causing other clients to wait. The postscreen limit is directly tied to the smtpd limit of the same name--setting one sets the other--as postscreen needs to be able to hand off legit connections to smtpd. Imagine the potential train wreck of giving postscreen 100 concurrent connections but smtpd only 5. The concurrent connection limit chosen will be site/server specific. Some MX Postfix boxen are designed to absorb a lot more mail per unit time than others, and some sites have a much larger inflow than others. My site is very small and thus the _need_ for parallel inbound deliveries should never arise. So a very low concurrency setting works well but for misbehaving clients, only one at the present time. For a much larger site such as say, ASU, with a student population of 55K plus faculty/staff, a low concurrency limit such as mine will likely cause lots of problems with list servers and freemailers, as would using anvil for this purpose period, as it lacks sufficient granularity. For such a large org, they'd want to use something like postfwd to limit concurrent connections from specific problem hosts or domains, and not molest the concurrent connections from known good senders. -- Stan