On 11/10/20 12:30 PM, Brian Carpenter wrote:
Hello everyone,
We had a new client come on board that brought a list that had the largest out-going mail volume that I have ever dealt with. So I did what any sane server administrator would do that is running Mailman 3: I ran to Mark Sapiro for help! Here is what the Sage of all things Mailman counseled me to do:
Thank you <blush>
- Disabled VERP delivery. VERP can help improve mail delivery by delivering 1 message per SMTP transaction (I think I got that right). Using VERP is counter-productive as it can seriously delay outgoing mail delivery for a high-volume list. So you can use something like the following in the MTA section of your mailman.cfg:
Actually, I mentioned VERP, but I don't think I recommended disabling it. Also note that these settings:
[mta] verp_confirmations: no verp_personalized_deliveries: no verp_delivery_interval: 0 are the defaults. Further, verp_confirmations is a holdover from MM 2.1 and has no effect, although prior to Mailman 3.3.2 confirmations were sent with
confirm <token>as the Subject: and beginning with Mailman 3.3.2, confirmations are sent withYour confirmation is needed ...as the Subject:.
Actually, I think enabling VERP with
[mta] verp_delivery_interval: 1
is generally a good idea for more reliable bounce detection.
- I configured Mailman 3 to run 4 outgoing runners. The default is 1. This action was the game changer. It allows Mailman to handle 4 incoming messages at a time instead of 1. My client's incoming list volume was high enough where it was overwhelming the single outgoing runner. Here is what I added to the mailman.cfg file:
[runner.out] instances: 4
Doing this step immediately solved the backlog in var/queue/out.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan