25 Jun
2022
25 Jun
'22
12:24 p.m.
Hi Didar,
On Sat, Jun 25, 2022 at 03:23:54PM +0530, didar via BitFolk Users wrote:
I set smtp_accept_queue_per_connection to 0 so it will allow any
number of messages in a connection.
Just in case there should be some runaway deluge of email I also
added:
queue_only_load = 4
so that if system load goes >= 4 it will queue mails, not try to
deliver them immediately.
On Debian the main Exim process also does queue runs, and the
interval is set in /etc/default/exim4:
QUEUEINTERVAL='5m'
(default is '30m')
Cheer,s
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
On Thu, Jun 23, 2022 at 11:26:12PM +0000, Andy Smith
via BitFolk Users wrote:
The setting is smtp_accept_queue_per_connection. On Debian's Exim
this isn't set, and the default value is 10.
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-main_configura…
"This option limits the number of delivery processes that Exim
starts automatically when receiving messages via SMTP, whether
via the daemon or by the use of -bs or -bS. If the value of the
option is greater than zero, and the number of messages received
in a single SMTP session exceeds this number, subsequent
messages are placed in the queue, but no delivery processes are
started. This helps to limit the number of Exim processes when a
server restarts after downtime and there is a lot of mail
waiting for it on other systems. On large systems, the default
should probably be increased, and on dial-in client systems it
should probably be set to zero (that is, disabled)."
This was because Exim on the lists host was set
to queue emails
after only 10 messages have been submitted in one connection - a
default setting I wasn't aware of and hadn't hit in my testing. The
queue check interval was also at its default, which is every 30
minutes.
What was the setting on Exim for "set to queue emails after only 10 messages
have been submitted in one connection"? I've now
rectified that by removing the 10 message limit and
reducing the queue run frequency to 5 minutes. Thje re-ordering and
extreme delays shouldn't happen again.
...and the settings that you now use to rectify?