On Fri, Jul 21, 2000 at 11:23:45AM -0400, Mark Mentovai wrote:
> >How is this accumulation supposed to occur? Per queue injection?
> >Over a time period? How long of a time period? As long as we're
> >being good neighbors, should the mta lookup the mx for each
> >recipient and accumulate by mx? What should we do if the dns
> >gives us a 0 ttl for the mx?
>
> None of the above. Let me give a loose description of what my idea of an
> efficient and fast MTA can do:
>
> When an MTA receives a message that should be sent out remotely, it should
> determine, in order of preference, which remote hosts are candidates for
> relaying the message. It should then attempt delivery to the
> best-preference host it can find, unless a certain number of active SMTP
> sessions to that host are already open. (This number can be one, or it can
> be something else small in the interests of allowing for parallel delivery.
> It should not be unlimited.) If there are already too many active SMTP
> sessions to the remote host, the message should wait until one of those
> sessions has finished transferring a message. Instead of closing the SMTP
> session, the sender would then transfer the new, waiting message. When a
> new message hits the queue and a delivery is attempted, any other messages
> in the queue waiting to be delivered to the same host should also be sent
> across the same session, or set of sessions.
>
> An MTA should not split the same message up into multiple messages when
> transferring them beyond reason. Although RFC 821 recommends that an SMTP
> server implementation place no arbitrary limitation on the number of
> recipients per message, it mandates that mail servers must be able to
> process up to 100 recipients. If an MTA receives a message with 100
> recipients with the same MX, there is no reason to transfer the message to
> the remote mail exchanger 100 times.
That's nice. Where's your implementation? I don't mind testing your
patches to qmail if you'll send them to me.
John
