Viktor Dukhovni wrote:
> 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
Probably due to high load on the server throttling the regular
transmission and then resuming later when the load is reduced the the
throttling removed.
> > 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?
I wish all users were so kind. But there are too many users who post
screen images in order to transmit error messages by a large picture
that should have been cut-n-pasted in as a few bytes of text. That
can cause some very large messages. Plus some mailing lists contain
patches and some patch sets can be very large into the
multi-megabytes. To avoid being too vague I am talking about the
{non,}gnu.org mailing lists such as the qemu ones. Over many of the
mailing lists in total it only takes a few such large messages to be
problematic as as whole.
So in general I agree with you that messages should be short and this
shouldn't be a problem. And yet frequently it is a problem in
practice. Enough that I notice. And enough that I try to address the
ussue some way. When I last scanned through the messages trying to
determine the problem I only saw random mailing list email traffic.
When it happens it usually continues for twenty minutes or so. This
encourages me to leave the keyboard and let it finish. I usually go
for a walk and let it settle. And then it is back to being fine
again. But the episodes have been happening more often lately.
> > 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.
Good to know.
> 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).
Unfortunately I don't have any control over the sending side. If I
did I would convert it to Postfix! :-)
Bob
