[Mailman-Developers] Regarding Handlers/SMTPDirect.py and "chunkify"

[Ian Eiloart]

--On 13 May 2008 00:26:08 -0400 Barry Warsaw <barry at 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