--On Saturday, August 20, 2011 13:36 +0200 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
...
One possibility is to sort queued messages by MX, but this
implies a delay and is error-prone.
Sigh.
Maybe I'm confused about what you are suggesting, but some of
the earliest SMTP senders implemented used a logic of:
-- when a message arrives (from an MUA or relay
function), try to deliver it
-- if it cannot be delivered immediately, queue it for
retry but sort or thread the queues so that, when a
redelivery attempt is made and succeeds, all messages
that are queued for that host are attempted, either in
the same SMTP session or very soon thereafter.
Variations on that theme are, IIR, discussed in RFC 1123 -- it
is not exactly a new idea.
In one form or another, that approach has been used by most
non-trivial SMTP clients since. There are a bunch of
optimizations and one wants to be really careful about any sort
or threading that gets tangled up with MX preferences and
thereby loses critical information, but, more than two decades
later, those methods are rather well-understood.
The obvious extension to that model is to look around after the
queue for a particular target host has been drained (or a bit
earlier if one has been careful about threading (and lucky in
one's choice of operating systems)) and see if new messages have
arrived for that host while that portion of the queue has been
run. That optimization is common too, and holding a connection
open for a few additional seconds while the check is being made
to see if something else arrives is too.
So what are we discussing here?
john