Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!know!samsung!munnari.oz.au!cs.mu.oz.au!kre
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Can non-Internet site handle others domains?
Message-ID: <3657@munnari.oz.au>
Date: 13 Apr 90 02:49:07 GMT
References: <141@dynasys.UUCP> <EMV.90Apr12145820@duby.math.lsa.umich.edu> <HGKHXQM@xavier.swarthmore.edu>
Sender: news@cs.mu.oz.au
Lines: 32

In article <HGKHXQM@xavier.swarthmore.edu>,
jeremy@cs.swarthmore.edu (Jeremy Brest) writes:
> It seems that when a mailer looks up a host and finds an MX record, it
> should then start at the top again and look up that host, again to see
> if it has an MX record.

Several reasons .. for one, it would prevent

	A MX B
	B MX A

from working (just in case someone actually finds a use for that...)

Second, the final A record site has to know how to process the mail
in any case (ie: if you had A MX B; B MX C; C A a.b.c.d, then C needs
to know how to handle mail addressed to both A and B).  It makes more
sense to make that clear.

Third, there are many more lookups than changes to the MX routing,
why make each lookup more expensive (needing to do multiple MX
checks) which could easily be done when the MX is installed in the
first place (ie: in the above case, the end result is going to be
that the mail is SMTP'd to C, so just install A MX C initially).

Finally its not clear (to me at least) just what it would mean to
have chained MX's when there are alternate MX's for a name, the
complexity in understanding simply isn't worth the insignificant
gain (which is entirely that if B was to change its MX, and you
want A to go along with it, with chained MX's you wouldn't need
to explicitly change A's MX, without them you do).

kre