We showed normal mail delivery in the previous section, so here we'll show how MX records are used for mail delivery, and illustrate the VRFY and EXPN commands.
In Section 14.6 we mentioned that one type of resource record in the DNS is the mail exchange record, called MX records. In the following example we'll show how MX records are used to send mail to hosts that are not directly connected to the Internet. RFC 974 [Partridge 1986] describes the handling of MX records by MTAs.
The host mlfarm.com is not directly connected to the Internet, but has an MX record that points to a mail forwarder that is on the Internet:
sun % host -a -v -t mx mlfarm.com The following answer is not authoritative: mlfarm.com 86388 IN MX 10 mercury.hsi.com mlfarm.com 86388 IN MX 15 hsi86.hsi.com Additional information: mercury.hsi.com 86388 IN A 143.122.1.91 hsi86.hsi.com 172762 IN A 143.122.1.6
There are two MX records, each with a different preference. We expect the MTA to start with the lower of the two preference values.
The following script shows mail being sent to this host:
sun % mail -v ron@mlfarm.com -v flag to see what the MTA does To: ron@mlfarm.com Subject: MX test message the body of the message is typed here (not shown) . period on a line by itself to terminate message Sending letter ... ron@mlfarm.com... Connecting to mlfarm.com via tcp... mail exchanger is mercury.hsi.com the MX records are found Trying 143.122.1.91... connected. first tries the one with lower preference 220 mercury.hsi.com ... remainder is normal SMTP mail transfer
We can see in this output that the MTA discovered that the destination host had an MX record and used the MX record with the lowest preference value.
Before running this example from the host sun, it was configured not to use its normal relay host, so we could see the mail exchange with the destination host. It was also configured to use the name server on the host noao.edu (which is across its dialup SLIP link), so we could capture both the mail transfer and the DNS traffic using tcpdump on the SLIP link. Figure 28.4 shows the starting portion of the tcpdump output.
In line 1 the MTA queries its name server for an MX record for mlfarm.com . The plus sign following the 2 means the recursion-desired flag is set. The response in line 2 has the authoritative bit set (the asterisk following the 2) and contains 2 answer RRs (the two MX host names ), 0 authority RRs, and 2 additional RRs (the IP addresses of the two hosts).
In lines 3 “5 a TCP connection is established with the SMTP server on the host mercury.hsi.com . The server's initial 220 response is shown in line 6.
Somehow the host mercury.hsi.com must deliver this mail message to the destination, mlfarm.com . The UUCP protocols are a popular way for a system not connected to the Internet to exchange mail with its MX site.
In this example the MTA asks for an MX record, gets a positive result, and sends the mail. Unfortunately the interaction between an MTA and the DNS can differ between implementations . RFC 974 specifies that an MTA should ask for MX records first, and if none are found, attempt delivery to the destination host (i.e., ask the DNS for an A record for the host, for its IP address). MTAs must also deal with CNAME records in the DNS (canonical names).
As an example, if we send mail to rstevens@mailhost.tuc.noao.edu from a BSD/386 host, the following steps are executed by the MTA (Sendmail).
Sendmail asks the DNS for CNAME records for mailhost.tuc.noao.edu. We see that a CNAME record exists:
sun % host -t cname mailhost.tuc.noao.edu mailhost.tuc.noao.edu CNAME noao.edu
A DNS query is issued for CNAME records for noao.edu and the response says none exist.
Sendmail then asks the DNS for MX records for noao.edu and gets one MX record:
sun % host -t mx noao.edu noao.edu MX noao.edu
Sendmail queries the DNS for an A record (IP address) for noao.edu and gets back the value 140.252.1.54. (This A record was probably returned by the name server for noao.edu as an additional RR with the MX reply in step 3.)
An SMTP connection is initiated to 140.252.1.54 and the mail is sent.
A CNAME query is not tried for the data returned in the MX record ( noao.edu ). The data in the MX record cannot be an alias ” it must be the name of a host that has an A record.
The version of Sendmail distributed with SunOS 4.1.3 that uses the DNS only queries for MX records, and gives up if an MX record isn't found.
Another use of MX records is to provide an alternative mail receiver when the destination host is down. If we look at the DNS entry for our host sun we see that it has two MX records:
sun % host -a -v -t mx sun.tuc.noao.edu sun.tuc.noao.edu 86400 IN MX 0 sun.tuc.noao.edu sun.tuc.noao.edu 86400 IN MX 10 noao.edu Additional information: sun.tuc.noao.edu 86400 IN A 140.252.1.29 sun.tuc.noao.edu 86400 IN A 140.252.13.33 noao.edu 86400 IN A 140.252.1.54
The MX record with the lowest preference indicates that direct delivery to the host itself should be tried first, and the next preference is to deliver the mail to the host noao.edu.
In the following script we send mail to ourself at the host sun.tuc.noaop.edu, from the host vangogh.cs.berkeley.edu, after turning off the destination's SMTP server. When a connection request arrives for port 25, TCP should respond with an RST, since no process has a passive open pending for that port.
vangogh % mail -v rstevens@sun.tuc.noao.edu A test to a host that's down. . EOT rstevens@sun.tuc.noao.edu... Connecting to sun.tuc.noao.edu. (smtp)... rstevens@sun.tuc.noao.edu... Connecting to noao.edu. (smtp)... 220 noao.edu ... remainder is normal SMTP mail transfer
We see that the MTA tries to contact sun.tuc.noao.edu and then gives up and contacts noao.edu instead.
Figure 28.5 is the tcpdump output that shows that TCP responds to the incoming SYNs with an RST.
In line 1 vangogh sends a SYN to port 25 at the primary IP address for sun: 140.252.1.29. This is rejected in line 2. The SMTP client on vangogh then tries the next IP address for sun: 140.252.13.33 (line 3), and it also causes an RST to be returned (line 4).
The SMTP client doesn't try to differentiate between the different error returns from its active open on line 1, which is why it tries the other IP address on line 3. If the error had been something like "host unreachable" for the first attempt, it's possible that the second attempt could work.
If the reason the SMTP client's active open fails is because the server host is down, we would see the client retransmit the SYN to IP address 140.252.1.29 for a total of 75 seconds (similar to Figure 18.6), followed by the client sending another three SYNs to IP address 140.252.13.33 for another 75 seconds. After 150 seconds the client would move on to the MX record with the next higher preference.
The VRFY command verifies that a recipient address is OK, without actually sending mail. EXPN is intended to expand a mailing list, without sending mail to the list. Many SMTP implementations (such as Sendmail) consider the two the same, but we mentioned that newer versions of Sendmail do differentiate between the two.
As a simple test we can connect to a newer version of Sendmail and see the difference. (We have removed the extraneous Telnet client output.)
sun % telnet vangogh.cs.berkeley.edu 25 220-vangogh.CS.Berkeley.EDU Sendmail 8.1C/6.32 ready at Tue, 3 Aug 1993 14: 59:12 -0700 220 ESMTP spoken here helo bsdi.tuc.noao.edu 250 vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29], pleased to meet you vrfy nosuchname 550 nosuchname... User unknown vrfy rstevens 250 Richard Stevens <rstevens@vangogh.CS.Berkeley.EDU> expn rstevens 250 Richard Stevens <rstevens@noao.edu>
First notice that we purposely typed the wrong hostname on the HELO command: bsdi instead of sun. Most SMTP servers take the IP address of the client and perform a DNS pointer query (Section 14.5) and compare the hostnames. This allows the server to log the client connection based on the IP address, not the name that a user might have mistyped . Some servers respond with humorous messages, such as "You are a charlatan," or "why do you call yourself ". We see in this example that this server just prints our real domain name from the pointer query along with our IP address.
We then type a VRFY command for an invalid name, and the server responds with a 550 error. Next we type a valid name, and the server responds with the username on the local host. Next we try the EXPN command and get a different response. The EXPN command determines that the mail for this user is being forwarded, and prints the forwarding address.
Many sites disable the VRFY and EXPN commands, sometimes for privacy, and sometimes in the belief that it's a security hole. For example, we can try these commands with the SMTP server at the White House:
sun % telnet whitehouse.gov 25 220 whitehouse.gov SMTP/smap Ready. helo sun.tuc.noao.edu 250 (sun.tuc.noao.edu) pleased to meet you. vrfy clinton 500 Command unrecognized expn Clinton 500 Command unrecognized