Racer X wrote:
> publishing an MX host that is never reachable seems pretty broken to me. it
> may be technically permitted, i suppose it's not explicitly forbidden
> anywhere, but publishing the record is like saying "what if 2 plus 2 equals
> 5?" interesting concept but pointless to bother with it. the firewall is
> clouding the issue.
If a server was broken, and I had no intent to fix it, but published an MX
pointing to it anyway, I would agree that is broken. OTOH, servers break,
and DNS servers don't know to withdraw the MX, and MTAs don't know if the
time frame is "never" or "for a while".
> the issue is more than that - it's "to what lengths should qmail go to work
> around the failure?"
... and what are the costs of doing so versus the benefits. Choosing to
sometimes retry the 2nd MX in the same process that just tried the 1st
would only cost the additional connection attempt. If it makes the
difference between successful or failed delivery of the mail, it would
be worth it. If it makes mail arrive earlier it may still be worth it.
OTOH, adding an elaborate scheme to the MTA which requires adding new
information in the mail queue to make complex delivery and recovery
decisions would certainly be costly and probably not worth the effort.
OTTOMH, I would favor a randomized fallback scheme which does not depend
on queued message state. When a delivery failure occurs, choose a random
number, then decide whether to now try the next MX based on a probability
derived from the MX level, or the ratio of MX levels, then maybe or maybe
not retry the next level before requeueing.
Should MX entries of equal value be tried equally?
--
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
phil | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
at | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ipal | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
dot | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
net | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
