>
> With all the recent discussion about aggregating RCPTs for the same MX,
> I took a look at qmail's code.
>
> It became clear quite fast that general aggregation was quite impossible
> given the architecture.
Especially since the it's quite possible for the same machine to exist in
the MX record sets of more that one recipient address, but with a different
preference value.
> What is feasible is this : for a given message, aggregate by
> domain. I.e, a mail to
> [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> can be dispatched as three mails,
> one to [EMAIL PROTECTED], [EMAIL PROTECTED]
> one to [EMAIL PROTECTED], [EMAIL PROTECTED]
> and one to [EMAIL PROTECTED]
>
> As it stands, most of qmail's architecture happily keeps all the
> recipients together. qmail-smtpd, qmail-inject and qmail-queue deal with
> a multi-RCPT message as one entity ; qmail-remote can send a single mail
> to multiple recipients on the same mailhost. Only qmail-send and
> qmail-rspawn are special-cased : qmail-rspawn is designed to only accept
> one recipient, and of course qmail-send actually does the breaking up.
This assumes that the recieving MTA will process multiple RCPT messages
in exactly the same way as those with a single RCPT. e.g. the MTA might
impose progressive delays in the transaction for every RCPT given to it
or attempt to deliver a message with multiple RCPT's at a lower priority.
Since the usual case is likely to be one RCPT it makes sense for recieving
MTA's to optimise for this case. (Also to treat messages with large numbers
of RCPT's as potential spam.)
Also you must handle the case where the the receiving MTA says "no more
RCPT's please".
--
Mark Evans
St. Peter's CofE High School
Phone: +44 1392 204764 X109
Fax: +44 1392 204763
