Mark Mentovai <[EMAIL PROTECTED]> wrote:
>Why not? You can have your cake and eat it too. Efficient network
>utilization doesn't mean delayed or slow delivery.
Say you have 100 different messages to deliver to various users at
AOL. Which will be faster:
1) Opening one connection to a single AOL MX and feeding them through
single-file, or
2) Opening N connections to M AOL MX's and feeding one message to
each?
Answer: 2
Now say you have one message to deliver to 5000 recipients at various
locations. Which will be faster:
1) Sorting the list by MX or domain name, opening a single connection
to each, and feeding one or more messages through single-file, or
2) Opening N connections to N recipient's MX's, delivering one
message through each connection?
Answer: 2
>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.
There's a lot of up-front DNS lookup overhead there. Even Postfix,
which tries to be neighborly, only sorts by FQDN.
>(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.
That's ten times as complicated as qmail's
one-qmail-remote-per-delivery method. If you can write such a complex
beast as correctly, reliably, efficiently, and securely as
qmail-rspawn/qmail-remote, by all means, do so. I will bow to your
greatness as I do to DJB's.
>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.
One good reason: VERP.
-Dave
