Re: general question about failed DNS request when looking up MXs

Ned Freed <> Tue, 14 January 1997 01:47 UTC

Received: from cnri by id aa06055; 13 Jan 97 20:47 EST
Received: from by CNRI.Reston.VA.US id aa27238; 13 Jan 97 20:47 EST
Received: (from majordomo@localhost) by (8.8.4/8.7.3) id RAA16489 for ietf-smtp-bks; Mon, 13 Jan 1997 17:22:27 -0800 (PST)
X-Authentication-Warning: majordomo set sender to using -f
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM []) by (8.8.4/8.7.3) with ESMTP id RAA16484 for <>; Mon, 13 Jan 1997 17:22:24 -0800 (PST)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-6 #8694) id <01IE62J9I2SGA8DRXP@INNOSOFT.COM> for; Mon, 13 Jan 1997 17:22:06 PST
Date: Mon, 13 Jan 1997 16:47:27 -0800 (PST)
From: Ned Freed <>
Subject: Re: general question about failed DNS request when looking up MXs
In-reply-to: "Your message dated Mon, 13 Jan 1997 19:19:43 -0500" <>
To: Jack De Winter <>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Precedence: bulk

> Okay, here's a general question for the group at large:

> You are doing an MX request to resolve an address that
> you need to send to.  You get back a Server Error (RCODE=2)
> or an illegal return code (RCODE=6..15).  What is the best
> thing to do to try and resolve this?

You have to abort the delivery attempt and try again later (temporary error).
No other course of action is acceptable, really -- there is nothing that says
that trying the host directly (even assuming you can get its A record when you
can't get its MX record list) will produce correct results. Even if you're
willing to enter a special mode where you treat any errors you get under these
circumstances as temporary, it won't work in general. There are cases where the
host in user@host being an MX pointing to several other systems ends up
resolving to an entirely different mailbox than user@host where host is treated
as simply an A record. There are also cases where direct delivery ignoring MX
leads to loops. (Yes, such setups are problematic given the fact that not
everything on the Internet is consistent in its support of MX, but such setups
exist nevertheless and have to be dealt with.)

The bottom line is that RFC974 says that when an the DNS returns a non-empty MX
list the client is supposed to try all the hosts on that list and then stop,
and setups have been built and are actively being used that take advantage of
every nuance of this described behavior. So if you cannot get the MX
list you don't know what you should or should not do, so your only
course of action is to not do anything.