On 1/28/2014 1:53 PM, Bob Proulx wrote: > Looking for advice... > > I have a Postfix mail server on a relatively slow 1.5Mbit/s dedicated > link. (It used to be relatively fast. Now it is relatively slow.) > It receives a lot of mailing list email from a well connected mailing > list server running Exim. > > Periodically a large wave of email from the mailing lists will be > unleashed. Such as when upstream connectivity is down for a while > causing a backlog and then it is restored causing a transfer of the > backlog. Then the upstream Exim mail server decides to open 36 > concurrent client connections. Server resources are not any problem. > But network bandwidth resources are limited. Each will split the > network bandwidth and get 2.7% or less of the bandwidth. > > Of course eventually the mail is transferred. The problem is that any > *other* network connection is also competing with those and each get a > split of the bandwidth. Everything else suffers. Even interactive > ssh connections are tedious to use. > > On first guess I would like to limit the number of concurrent > clients. I look and see smtpd_client_connection_count_limit=50 and > immediately think I should reduce that number to something smaller, > say less than 10 as a start. But it also includes this stern warning. > > WARNING: The purpose of this feature is to limit abuse. It must not > be used to regulate legitimate mail traffic. > > But there isn't any rationale on why not. Also it doesn't give any > hints as to suggestions to limit the number of incoming clients if > that isn't to be used. Since this email from the upstream mailing > list server is legitimate. > > And so here I am querying the wisdom of the net to see why using > smtpd_client_connection_count_limit would be bad and what alternative > strategies exist.
When the sender exceeds the smtpd_client_connection_count_limit, they will get a 4xx deferral. When they retry delivery is out of your control -- some may retry in a few minutes, other hours, a few never (although not retrying is non-RFC compliant and seldom seen with legit servers). So it can result in severe mail delays and possible loss of mail. The bigger problem is that one or two connections from a well-connected client will still overwhelm your bandwidth. The real solution is traffic shaping or QoS to limit the bandwidth used by SMTP. Your firewall software or your router may already have this feature, just waiting for configuration. -- Noel Jones
