
--On 13 May 2008 00:26:08 -0400 Barry Warsaw <barry@list.org> wrote:
We clearly need to support personalization[1] in Mailman, although it would be nice if there were extensions we could rely on in the MTA to push even that out farther. I'd like to hear from any Sendmail, Postfix, or Exim experts on this list to see if the chunking even makes sense any more.
Yes, it does. At least, it makes sense to offer the option. There are two cases - (a) Mailman delivers all its mail to a smarthost, (b) Mailman delivers some or all of its mail directly to the MX hosts of the recipients.
Exim, by default, doesn't care about the number of recipients per message. It can be configured to using "recipients_max", and in that case will either defer or reject "recipients_max_reject" the excess. Both these configuration variables are global. Fine tuning of similar limits is available in ACLs, though, and can be configured differently for a known Mailman host.
If Mailman is configured to route mail through a smarthost, then an Exim smarthost should be configured to cope with whatever Mailman throws at it.
Otherwise, as the Exim docs caution, you might fall foul of RFC2821 section 4.5.3.1 Size limits and minimums:
recipients buffer The minimum total number of recipients that must be buffered is 100 recipients. Rejection of messages (for excessive recipients) with fewer than 100 RCPT commands is a violation of this specification. The general principle that relaying SMTP servers MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation tests on message headers suggests that rejecting a message based on the total number of recipients shown in header fields is to be discouraged. A server which imposes a limit on the number of recipients MUST behave in an orderly fashion, such as to reject additional addresses over its limit rather than silently discarding addresses previously accepted. A client that needs to deliver a message containing over 100 RCPT commands SHOULD be prepared to transmit in 100-recipient "chunks" if the server declines to accept more than 100 recipients in a single message.... etc...
-- Ian Eiloart IT Services, University of Sussex x3148