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-us...@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
------------------------------------------------------
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@mail-archive.com
