----- Original Message -----
From: "Arnt Gulbrandsen" <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>
Valdis Klētnieks writes:
I think Arnt's meaning was "If you get a SERVFAIL trying to get the
MX, then you *don't* know there's no MX, so dropping back to an A is
improper. The message should be queued and retried later".
Exactly.
I'd say that SERVFAIL is best covered by RFC 2821 section 6.1, which has
this to say about error handling: «It [the MTA] must take this
responsibility seriously. It MUST NOT lose the message for frivolous
reasons, such as because the host later crashes or because of a
predictable resource shortage.» Although the DNS is not mentioned, the
passage doesn't seem to condone speculatively falling back to A in case
of an MX query timeout, SERVFAIL, or other uncertain response.
I think all agreed.
But if you search the net, you will find discussions on this SMTP client
consideration. I can only suggest the historical reason is that there were
many DNS servers producing the erroneous SERVFAIL failures, and it would be
quite possible that exhausted attempts would finally kill/dump the message
when in fact, an A record lookup might have satisfied the transaction.
But you are right. This wouldn't be a good idea.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com