smtp-failure shows lots of "too man recipients"

> My assumption is that if you have SMTP_MAX_RCPTS set to a lower value than your MTA, it should "chunk" up the message and deliver just fine and shouldn't get these errors.

Your assumption is correct. Have you restarted Mailman since setting SMTP_MAX_RCPTS=5?

> Why else would I be seeing these errors?

If restart is not the answer, I think that's a sendmail question. You could see the FAQ at http://wiki.list.org/x/-IA9 for a debugging technique that will cause Mailman to log copious debug information to its error log. This may give more insight.

Yes I have restarted Mailman since then. Didn't seem to help. I also verified in my sendmail.cf that the setting is correct and have restarted sendmail as well.

Ok, I will look at that URL.

Just for reference, mailman (specifically, python) talks directly to the MTA, correct? And if python gets the error back from the MTA about too many recipients, then it will write to the smtp-failure log? Is this correct? Once it sees the error, what does mailman do with the message?

Thanks for all the help. It is much appreciated.

> Just for reference, mailman (specifically, python) talks directly to the MTA, correct?

Correct.

> And if python gets the error back from the MTA about too many recipients, then it will write to the smtp-failure log? Is this correct?

Yes.

> Once it sees the error, what does mailman do with the message?

It puts the message minus the 'accepted' recipients (if any) in Mailman's 'retry' queue and retries at 1 hour intervals for up to 5 days or until all recipients have been accepted. These are defaults that can be overridden in mm_cfg.py

DELIVERY_RETRY_PERIOD = days(5)
DELIVERY_RETRY_WAIT = hours(1)

There is one possible issue. Once a message's recipients have been chunked, if the message is queued for retry, the chunks are saved with the message, so changing SMTP_MAX_RCPTS has no effect for this message. Your errors may be from old messages that are still being retried.

Look at entries in Mailman's retry queue with bin/dumpdb and see if the metadata (second object) has large chunks in the 'undelivered' attribute.

This is great information and helps a lot! Thanks for the help!