Mailing list traffic: Submission strategies

[Stefan Förster-4]

Hello world,

please consider running a software running a mailing list, for example
Majordomo or Mailman. Typically, if this software receives a vaild
mail which is to be  distributed amongst the mailing lists
subscribers, it will submit the message using (E)SMTP (the performance
tuning readme clearly states that large amounts of mail should not be
injected using sendmail(1)).

Postfix allows to configure the number of recipients allowed, so the
list managing software can simply avoid exceeding this limit by
splitting the recipients into several batches if the number of
recipients is bigger than smtpd_recipient_limit.

Is there an "optimal" strategy to order those recipients if the number
of recipients exceeds smtpd_recipient_limit? For example, does it make
sense to group by TLD (.com, .net, .org) and inject batches of less
than smtpd_recipient_limit recipients (for example, 500 .com in the
first batch, 400 .net in the second batch, 400 .org in the third batch
and 250 other (g)TLDs in the fourth one)? Another example would be to
strictly order by recipient destinations, that is one (or more) mails
for every destination, @AOL.com first and @zdnet.com last.

I didn't have time to read http://www.postfix.org/SCHEDULER_README.html
really carefully, but from what I understand so far, this "tricks"
don't seem to be necessary to ensure fast delivery. Within the defined
limits (size of the active queue, number of available delivery agents
and so on) I can't see how the aforementioned ordering should yield
any significant performance gains (talking about Postfix 2.5 here, not
1.x). On the contrary, qmgr seems fully able to take care of any
ordering, even if there are only a few messages, each one with a large
recipient list, which would allow the mailing list software to simply
split recipients into batches of smtpd_recipient_limit size.

I hope my question makes sense, if not, I will gladly rephrase it. Any
insights on this would be greatly appreciated.


Cheers
Stefan

[Wietse Venema]

Stefan F?rster:
> Hello world,
>
> please consider running a software running a mailing list, for example
> Majordomo or Mailman. Typically, if this software receives a vaild
> mail which is to be  distributed amongst the mailing lists
> subscribers, it will submit the message using (E)SMTP (the performance
> tuning readme clearly states that large amounts of mail should not be
> injected using sendmail(1)).

... if you send one-message-per-recipient email

With multi-recipient messages, the overhead of creating a queue
file does not matter,

        Wietse

[Stefan Förster-4]

* Wietse Venema <[hidden email]> wrote:

> Stefan Förster:
> > Hello world,
> >
> > please consider running a software running a mailing list, for example
> > Majordomo or Mailman. Typically, if this software receives a vaild
> > mail which is to be  distributed amongst the mailing lists
> > subscribers, it will submit the message using (E)SMTP (the performance
> > tuning readme clearly states that large amounts of mail should not be
> > injected using sendmail(1)).
>
> ... if you send one-message-per-recipient email
>
> With multi-recipient messages, the overhead of creating a queue
> file does not matter,

Thanks for pointing that out. Do you have any hints on the recipient
ordering I mentioned (see bleow)?

>> Is there an "optimal" strategy to order those recipients if the number
>> of recipients exceeds smtpd_recipient_limit? For example, does it make
>> sense to group by TLD (.com, .net, .org) and inject batches of less
>> than smtpd_recipient_limit recipients (for example, 500 .com in the
>> first batch, 400 .net in the second batch, 400 .org in the third batch
>> and 250 other (g)TLDs in the fourth one)? Another example would be to
>> strictly order by recipient destinations, that is one (or more) mails
>> for every destination, @AOL.com first and @zdnet.com last.
>>
>> I didn't have time to read http://www.postfix.org/SCHEDULER_README.html
>> really carefully, but from what I understand so far, this "tricks"
>> don't seem to be necessary to ensure fast delivery. Within the defined
>> limits (size of the active queue, number of available delivery agents
>> and so on) I can't see how the aforementioned ordering should yield
>> any significant performance gains (talking about Postfix 2.5 here, not
>> 1.x). On the contrary, qmgr seems fully able to take care of any
>> ordering, even if there are only a few messages, each one with a large
>> recipient list, which would allow the mailing list software to simply
>> split recipients into batches of smtpd_recipient_limit size.

Thanks in advance
Stefan

[Wietse Venema]

Stefan F?rster:

> * Wietse Venema <[hidden email]> wrote:
> > Stefan F?rster:
> > > Hello world,
> > >
> > > please consider running a software running a mailing list, for example
> > > Majordomo or Mailman. Typically, if this software receives a vaild
> > > mail which is to be  distributed amongst the mailing lists
> > > subscribers, it will submit the message using (E)SMTP (the performance
> > > tuning readme clearly states that large amounts of mail should not be
> > > injected using sendmail(1)).
> >
> > ... if you send one-message-per-recipient email
> >
> > With multi-recipient messages, the overhead of creating a queue
> > file does not matter,
>
> Thanks for pointing that out. Do you have any hints on the recipient
> ordering I mentioned (see bleow)?

Postfix sorts recipients by domain so it can bundle multiple
recipients into one delivery request.

        Wietse