Andreas Grupp via Mailman-Users writes:

Note that this is the wrong list for Mailman 3. This list is for Mailman 2, and you are likely to get inaccurate advice here. You should use mailman-users@mailman.org in the future. (Don't move this thread there, I think it's mostly over anyway, and we should keep the thread together.)

No, Postfix on the same machine and is sending several thousand mails in 8 hours. Sending for example 600 mails, coming from a forum in a Learning Management System, is done in one step in only a few seconds.

Postfix is quite capable of permitting a particular user to exceed limits placed on other users. Seems unlikely in your case, but keep it in mind as a last resort.

It's also possible the LMS system is specifying 600 recipients to a single message in one session. Mailman can do that, but you have to turn off the personalization features of Mailman.

I can see in the mail log that there are only 100 mails delivered from Mailman3 to Postfix.

Here are the relevant Mailman mail delivery configuration parameters. (If you want multiple recipients per session, you also have to turn off personalization for that list.) Note: I believe that in the comments quoted below "session" and "transaction" are the same thing, the set of SMTP commands starting with MAIL FROM and ending with the period at the end of the DATA command. These are defaults set in site-packages/mailman/config/schema.cfg:

# Ceiling on the number of recipients that can be specified in a
# single SMTP transaction.  Set to 0 to submit the entire
# recipient list in one transaction.
max_recipients: 10

# Ceiling on the number of SMTP sessions to perform on a single
# socket connection.  Some MTAs have limits.  Set this to 0 to do
# as many as we like (i.e. your MTA has no limits).  Set this to
# some number great than 0 and Mailman will close the SMTP
# connection and re-open it after this number of consecutive
# sessions.
max_sessions_per_connection: 0

If I understand correctly, the maximum number of recipients that will be sent out before closing the connection is max_recipients * max_sessions. The default settings should allow Mailman to make one connection and send out all of the recipients for that message, but if you have large numbers of recipients going to the same domain (eg, GMail or GMX) and personalization is OFF, you can speed things up dramatically by raising max_recipients.

Warnings: If personalization is on (for example so you can put personalized unsubscribe URLs in the footer), this won't help because that forces session-per-recipient performance anyway. You should also be aware that some hosts will decide you're a spammer if you try to send to all your subscribers at that host at the same time. Personally I would probably not mess with max_recipients.

# Maximum number of simultaneous subthreads that will be used for
# SMTP delivery.  After the recipients list is chunked according
# to max_recipients, each chunk is handed off to the SMTP server
# by a separate such thread.  If your Python interpreter was not
# built for threads, this feature is disabled.  You can explicitly
# disable it in all cases by setting max_delivery_threads to 0.
max_delivery_threads: 0

These defaults serialize all of the recipients. If you have personalization on, this means that there will be one recipient in each session, and the messages will be be sent one at a time until done, or the MTA breaks the connection. In the latter case Mailman will open a new connection, and repeat the process until done.

You can probably speed things up by bumping up max_delivery_threads (check that Python supports threading). However, you probably should do this gradually so that Mailman doesn't crowd out your other mass- mailing clients.

Any of these changes should be made in mailman.cfg, which probably is in /etc/mailman3/. If these parameters are not set in mailman.cfg, most likely your MTA is doing the throttling, but you can check schema.cfg to see if maybe Debian messed with the defaults.

The only thing I've changed to the standard Debian

Unfortunately, Debian frequently lags current releases substantially, as well as making plenty of changes on your behalf that all too often are confusing for upstream developers. The variables above are the kind of thing that Debian frequently messes with, although I would expect those changes to be visible in the mailman.cfg config file.

configuration was due to error mails coming form Django. So I inserted to /etc/mailman3/mailman-web.py at the end the following lines:

QCluster is irrelevant to post distribution, it only affects archiving.

Steve