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

Reply via email to