🚀 go-pugleaf

In article <801@hao.UCAR.EDU> woods@hao.UCAR.EDU (Greg Woods) writes:
>Now that we have a running named(8) name server, and a version of sendmail(8)
>capable of querying it, I'd like to make use of it. I hear a lot about MX
>records, but as yet I have not figured out exactly what they are nor how to
>use them. The BIND documentation mentions their existence and how to specify
>them in the named cache files, but it does not explain how they would be used.
>The sendmail documentation I have doesn't mention them at all.  So, can someone
>answer these questions for me (and I doubt if I'm the only one that wants to
>ask): 1) What exactly is the purpose of an MX record? 2) How do I go about
>using one at this site to make delivery to our domain more reliable? 3) How
>do I use the MX records provided by other sites?

An MX record simply specifies the name of another site that can accept mail
addressed to your site, along with a preference value that specifies what
order to try mail exchangers if there are more than one.

For instance, the host "watnot.waterloo.edu" is a CSnet site, but I'd
still like to be able to mail to "user@watnot.waterloo.edu", instead of
"user%watnot.waterloo.edu@relay.cs.net" (in other words, I'd rather not
know or care that this mail must go through CSNET-RELAY.)  The "nslookup"
program (which you should have gotten with BIND) can be set to look at
MX records by "set querytype=MX".  When I do this, and look up watnot, I
get:

watnot.waterloo.edu     preference = 10, mail exchanger = relay.cs.net

Which means that all mail to watnot.waterloo.edu should *really* be sent
to relay.cs.net.  Note that the preference value here is meaningless, since
there is only one MX record.

Another more interesting case is the site "cis.upenn.edu", which is on
the Internet.  Here are the MX record lookups for that site:

cis.upenn.edu   preference = 10, mail exchanger = E.CIS.UPENN.EDU
cis.upenn.edu   preference = 10, mail exchanger = B.CIS.UPENN.EDU
cis.upenn.edu   preference = 10, mail exchanger = C.CIS.UPENN.EDU
cis.upenn.edu   preference = 20, mail exchanger = CIS.UPENN.EDU
cis.upenn.edu   preference = 30, mail exchanger = LINC.CIS.UPENN.EDU

Here, there are 5 machines specified as able to recieve mail for
"cis.upenn.edu", and one of them is that machine itself.  Since there
are multiple MX records, the mailer should try them in order of ascending
preference value; first it tries all of "E...", "B...", and "C...", in
no particular order.  If all of those fail, it will try to send to
"CIS.UPENN.EDU" directly.  If *that* fails, then it tries to send the
mail to "LINC.CIS.UPENN.EDU".

Note that, when delivering mail to an MX host, the "To:" address in the
header is *not* rewritten to include the name of the MX host.  The MX
host must be smart enough to gateway mail (this is quite easy for sendmail
to do).

--Pat.

In article <801@hao.UCAR.EDU> woods@hao.UCAR.EDU (Greg Woods) writes:
>>Now that we have a running named(8) name server, and a version of 
>>sendmail(8) capable of querying it, I'd like to make use of it.

And pdb@sei.cmu.edu (Pat Barron) says:
>An MX record simply specifies the name of another site that can accept mail
>addressed to your site, along with a preference value that specifies what
>order to try mail exchangers if there are more than one.

Let me elaborate a little on what Pat said.

Let's say that an MX-using host S is trying to send mail to a
destination D.  It finds all the MX records for D.  If none of these
name D itself as a mail-exchanger for D, then S will not attempt to
connect to D directly.

If S itself is listed as a mail-exchanger for D, with some preference
P, then S will only connect to a mail exchanger whose preference is
strictly less than P.  

If that last rule leaves no eligible mail-exchangers for D (or if
there were no MX records to begin with), then S may (must?) pretend
that there was an MX record listing D as a mail-exchanger with
preference zero.

Not that you don't need to do anything funky in sendmail.cf to use
the MX records.  If ruleset zero resolves to host D, then code in
deliver.c will look up MX records for D.

Now for two named caveat and some cute tricks.  

It is awfully tempting to put a wildcard MX record in the data for
your domain.  This is usually not as useful as you think.  Wildcard
records are only returned to a querant if there is no other record of
any type for the name asked about.

If the mail-exchanger listed for some host is itself a nickname for
something, that is if it is the subject of a CNAME record, you may
create a forwarding loop.

Here at the university of Chicago we have a high speed but unreliable
internet connection, and a lower speed connection.  We list the host
which owns the low speed connection as an MX with preference 100 for
every mail host in our domain.  That host is "dumb" and always
forwards internal mail to another host, gargoyle, so to avoid loops
we must list gargoyle as an MX for every host and give it a lower
preference.  Thus a typical host's MX records look like:

chip.UChicago.EDU	preference = 0, mail exchanger = chip.UChicago.EDU
chip.UChicago.EDU	preference = 10, mail exchanger = sphinx.UChicago.EDU
chip.UChicago.EDU	preference = 99, mail exchanger = gargoyle.UChicago.EDU
chip.UChicago.EDU	preference = 100, mail exchanger = cypress.UChicago.EDU

When our primary link is down, only host cypress.UChicago.EDU is
reachable from off-campus.  Thus mail from MX-using hosts will still
get in.  (Yes, we do have an off-campus secondary server for our
domain!)
________________________________________________________
Matt	     University		matt@oddjob.uchicago.edu
Crawford     of Chicago     {astrovax,ihnp4}!oddjob!matt