28.3 SMTP Examples

28.3 SMTP Examples

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.

MX Records: Hosts Not Directly Connected to the Internet

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.

Figure 28.4. Sending mail to a host that uses MX records.
graphics/28fig04.gif

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).

  1. 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 
  2. A DNS query is issued for CNAME records for noao.edu and the response says none exist.

  3. 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 
  4. 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.)

  5. 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.

MX Records: Hosts That Are Down

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.

Figure 28.5. Attempt to connect to an SMTP server that is not running.
graphics/28fig05.gif

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.

VRFY and EXPN Commands

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 


TCP.IP Illustrated, Volume 1. The Protocols
TCP/IP Illustrated, Vol. 1: The Protocols (Addison-Wesley Professional Computing Series)
ISBN: 0201633469
EAN: 2147483647
Year: 1993
Pages: 378

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net