Hung Phan wrote:

Previously, our Mailman sent out messages all at once to the recipients; however, this behavior has since changed.

And what did you change just before this behavior changed?

According to the exim log file, the message delivers to 10 recipients and get queue for the next round. So we have been researching for different options to tweak the behavior. So far, we have: SMTP_MAX_RCPTS = 0 and SMTP_MAX_SESSIONS_PER_CONNECTION = 0 for the ~mailman/Mailman/Defaults.py

Do not make changes to Defaults.py. Defaults.py contains the default settings and their documentation. Changes should be made in mm_cfg.py. See the FAQ at <http://wiki.list.org/x/fIA9>.

SMTP_MAX_SESSIONS_PER_CONNECTION has nothing to do with this. It's name is a bit of a misnomer. It actually sets the maximum number of SMTP transactions (MAIL FROM commands) that Mailman will send over an SMTP connection before closing and reopening the connection. It has no effect on the number of recipients in a single transaction.

SMTP_MAX_RCPTS = 0 tells mailman not to "chunkify" the recipients, but to send to all recipients in a single transaction with one MAIL FROM, a RCPT TO for each recipient and one DATA for the message data.

QUEUE = 5m for the /etc/init.d/exim

This just tells the exim daemon to check its queues for things to do every 5 minutes. It doesn't affect how many recipients will be accepted for a message.

Other mention that we should add smtp_accept_queue_per_connection = 0 into exim.conf config file. By adding this in, exim fails on restart so we reverse the change.

This could be relevant. It defaults to 10 which says if more than 10 messages are received on a single connection, they will be queued. What was the specific exim error with smtp_accept_queue_per_connection = 0?

All these configurations don't change the new behavior. Any other configuration that we may overlook?

The relevant exim main.cf settings are smtp_accept_max_per_connection recipients_max. smtp_accept_max_per_connection is exim's side of Mailman's SMTP_MAX_SESSIONS_PER_CONNECTION. In theory, exim's setting should be as large or larger than Mailman's, but exim's default is 1000, and even if there are only 10 recipients per transaction, unless you are sending to more than 10,000 recipients, you should be OK.

recipients_max is exim's limit on the number of recipients per transaction. exim's default for this is 0 meaning unlimited, but if it were set to 10 it might explain this behavior. In any case, exim's recipients_max should be at least as big as Mailman's SMTP_MAX_RCPTS.

These are really exim questions and while I have used exim, I don't currently and I'm not an expert.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hung Phan wrote:

Previously, our Mailman sent out messages all at once to the recipients; however, this behavior has since changed.

And what did you change just before this behavior changed?

According to the exim log file, the message delivers to 10 recipients and get queue for the next round. So we have been researching for different options to tweak the behavior. So far, we have: SMTP_MAX_RCPTS = 0 and SMTP_MAX_SESSIONS_PER_CONNECTION = 0 for the ~mailman/Mailman/Defaults.py

Do not make changes to Defaults.py. Defaults.py contains the default settings and their documentation. Changes should be made in mm_cfg.py. See the FAQ at <http://wiki.list.org/x/fIA9>.

SMTP_MAX_SESSIONS_PER_CONNECTION has nothing to do with this. It's name is a bit of a misnomer. It actually sets the maximum number of SMTP transactions (MAIL FROM commands) that Mailman will send over an SMTP connection before closing and reopening the connection. It has no effect on the number of recipients in a single transaction.

SMTP_MAX_RCPTS = 0 tells mailman not to "chunkify" the recipients, but to send to all recipients in a single transaction with one MAIL FROM, a RCPT TO for each recipient and one DATA for the message data.

QUEUE = 5m for the /etc/init.d/exim

This just tells the exim daemon to check its queues for things to do every 5 minutes. It doesn't affect how many recipients will be accepted for a message.

Other mention that we should add smtp_accept_queue_per_connection = 0 into exim.conf config file. By adding this in, exim fails on restart so we reverse the change.

This could be relevant. It defaults to 10 which says if more than 10 messages are received on a single connection, they will be queued. What was the specific exim error with smtp_accept_queue_per_connection = 0?

All these configurations don't change the new behavior. Any other configuration that we may overlook?

The relevant exim main.cf settings are smtp_accept_max_per_connection recipients_max. smtp_accept_max_per_connection is exim's side of Mailman's SMTP_MAX_SESSIONS_PER_CONNECTION. In theory, exim's setting should be as large or larger than Mailman's, but exim's default is 1000, and even if there are only 10 recipients per transaction, unless you are sending to more than 10,000 recipients, you should be OK.

recipients_max is exim's limit on the number of recipients per transaction. exim's default for this is 0 meaning unlimited, but if it were set to 10 it might explain this behavior. In any case, exim's recipients_max should be at least as big as Mailman's SMTP_MAX_RCPTS.

These are really exim questions and while I have used exim, I don't currently and I'm not an expert.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan