>I would strongly suggest doing this outside the MTA, and splitting
>the message prior to it hitting exim.
Hmm. Just been discussing this. My view it that the correct place to
do it is in the MTA. A user agent (including a list management system)
should'nt need to know the queuing management details of the MTA its
using - it should just say - send this message to these people as fast
as you can.
>I don't know what list
>processor you are using, but several have capabilities of doing just
>that!
We are using listserver which has those capablities but are about to
move to majordomo (which does'nt). Majordomo just sends to an outgoing
alias - which is expanded by the MTA.
>However it would be nice if exim *could* effectively split up huge
>delivery sets into multiple smaller sets, but how this would best be
>acheived, and at what point (after routing them all, after directing,
>during delivery...?), is a non-trivial task!
The way PP does it is to build queues based on outbound MTA.
I don't really know the ins and outs of the exim code but it could
fork of a master process for a message which then fork of children
for each rcpt field up to some maximum.
There is also a queue_smtp flag. So it may be possible to work out
all the routing first. Then go back and process multi-messages based
on MTA.
Martyn
--
+--------------------------------------------------------------------+
| Martyn Hampson | Tel: 0171 594 6973 |
| Imperial College | Fax: 0171 594 6958 |
| Computer Centre | E-Mail: M.Hampson@??? |
| London SW7 2BP, ENGLAND | "Don't just do something, sit there!" |
+--------------------------------------------------------------------+
