On Tue, Jan 28, 2014 at 12:53:41PM -0700, Bob Proulx wrote:
> 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.
Mailing list posts are generally short, I would estimate typicall
less than 4kB per message, so 36 * 32kbits ~ 1Mbit. This should
saturate your link for about 1 second. Do the lists in question
carry unusually large messages?
> WARNING: The purpose of this feature is to limit abuse. It must not
> be used to regulate legitimate mail traffic.
Client concurrency limits cause difficulties on the sending side,
what may well happen is that mail is deferred and then even more
mail accumulates, the queue is flushed with most of the mail
deferred, ... The feedback mechanism only works when there is a
single spike, against a background of very low traffic.
You might consider applying the limit to just the problem source,
and see if that works, but it would be better if the sending system
could limit concurrency (don't know how or whether Exim controls
connection concurrency).
--
Viktor.
