woods@hao.UCAR.EDU (Greg Woods) (07/27/87)
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?
Thanks for any enlightenment anyone provides.
--Greg
--
UUCP: {hplabs, seismo, nbires, noao}!hao!woods
CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA
INTERNET: woods@hao.ucar.edupdb@sei.cmu.edu (Patrick Barron) (07/28/87)
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.
matt@oddjob.UChicago.EDU (Matt Crawford) (08/03/87)
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
chris@mimsy.UUCP (Chris Torek) (01/07/88)
In article <1804@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >For example, my address is jbuck@epimass.epi.com. If you run a >current Internet mailer, it will try to find the host, fail, and then >obtain an MX record telling it to pass the message to uunet.uu.net.... Actually, to make MX records work `right', it has to use the reverse order: try for an MX answer first, and only if that fails (authoritatively, not temporarily), try for a host. If you look for the host name first, then the MX record, you then cannot make a single machine the mail agent for a group of machines. Also, if a machine is down for a few days, it is nice to be able to redirect Internet mail through a different host in the interim. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris