For this to work, there would need to be a list maintained by the
delivering MTA that lists which other MTAs it has tried to deliver to which
failed due to failure to connect (along with a queue of messages that need
be delivered to that MTA and a time to next attempt to connect). When a new
message arrives and it gets delivered (since that connect attempt worked)
the queue of pending messages can then be immediately flushed to the MTA.
many MTAs have this type of support to force flush a pending queue when a
message delivery succeeds?
Exim works in roughly this way.
So does our product (currently called Oracle Communications Messaging Server,
but who knows what the name will be tomorrow ;-), although there are a number
of additional details like message priority and number of previous delivery
attempts that have to be factored in.
I've always assumed that a fair number of other MTAs also do this sort of
But sometimes these strategies cause problems of their own. For example,
suppose there's a message that crashes the receiving SMTP server. (This happens
a lot more often than it should, unfortunately.) If you implement a "oldest
first" or "most often retried first" strategy along with strict "always send
every pending message once you get a connection open" policy, you can end up in
a situation where the problematic message ends up blocking other messages which
would work if you tried them first. And this issue has gotten more pernicious
over time as email service has consolidated onto fewer, larger service
providers, who sadly aren't in any way immune from the crashing message issue.