unx41.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<LI>RFC 821 Simple Mail Transfer Protocol (SMTP). RFC 821 defines the commands by which Internet mailers exchange e-mail. It is explained later in more detail.

<BR>

<BR></LI>

<LI>RFC 822 Standard for the format of ARPA Internet text messages. RFC 822 defines the proper form of an e-mail message. E-mail is divided into two parts, the headers and the body, which are separated by a blank line. The headers contain essential 
information such as the return address of the sender, and the body is the message you want to send.

<BR>

<BR></LI>

<LI>RFC 1425 SMTP Service Extensions. RFC 1425 extends the SMTP protocol to what is commonly known as ESMTP.

<BR>

<BR></LI>

<LI>RFC1123 Requirements for Internet Hosts&#151;Application and Support. RFC1123 is commonly known as the host requirements RFC. It clarifies requirements that all hosts on the Internet must meet and corrects some errors in earlier RFCs.

<BR>

<BR></LI>

<LI>RFC 976 UUCP Mail Interchange Format Standard. RFC 976 explains the UUCP mail protocol, which is a store-and-forward mechanism. Instead of making a direct connection like a phone circuit, host A makes a temporary connection to send mail to host B, 
which stores it temporarily and forwards it to host C, the final recipient. UUCP is a pain in the neck; avoid it if you can.

<BR>

<BR></LI></UL>

<H5 ALIGN="CENTER">

<CENTER><A ID="I8" NAME="I8">

<FONT SIZE=3><B>Sendmail Documentation</B>

<BR></FONT></A></CENTER></H5>

<P>V8 sendmail comes with three important documents:

<BR></P>

<UL>

<LI>Sendmail Installation and Operation Guide (SIOG)

<BR>

<BR></LI>

<LI>SENDMAIL&#151;An Internetwork Mail Router

<BR>

<BR></LI>

<LI>Mail Systems and Addressing in 4.2bsd

<BR>

<BR></LI></UL>

<P>All three were written by Eric Allman, the author of the sendmail program. The SIOG is an essential reference manual that explains the guts of sendmail. The other documents are more general overviews of mail router design. All are worth reading, but the 

SIOG is your essential guide to sendmail. You'll want to read it several times and highlight parts relevant to your site's configuration.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I9" NAME="I9">

<FONT SIZE=3><B><I>sendmail</I></B><B>, The Book</B>

<BR></FONT></A></CENTER></H5>

<P>The book sendmail by Bryan Costales, Eric Allman and Neil Rickert (O'Reilly &amp; Associates, Inc., 1993) is the most comprehensive treatment of the care and feeding of V8 sendmail. If you manage a complex site or must write custom configuration files, 

it is invaluable. If your site is fairly simple or you find that you can get most of what you need from this chapter, the standard V8 sendmail documentation, comp.mail.sendmail and the RFCs, save your money.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I10" NAME="I10">

<FONT SIZE=3><B>Comp.mail.sendmail</B>

<BR></FONT></A></CENTER></H5>

<P>If your site receives USENET news, don't pass go, don't collect $200, just add the newsgroup comp.mail.sendmail to your newsreader's subscription list. Eric Allman, the author of sendmail, contributes regularly along with other sendmail wizards. You can 

get more quality, free advice here than anywhere else on the USENET.

<BR></P>

<P>However, as with any newsgroup, read it for a few weeks before you make your first posting, and save yourself the embarrassment of asking a question that has already been answered a hundred times by first reading the V8 sendmail Frequently Asked 
Questions (FAQ) document and the other documentation mentioned in this chapter. It may take a little longer to get your burning question answered, but you'll still respect yourself in the morning.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I11" NAME="I11">

<FONT SIZE=3><B>Internet Mail Protocols</B>

<BR></FONT></A></CENTER></H4>

<P>In order to understand the different jobs that sendmail does, you need to know a little about Internet protocols. Protocols are simply agreed-upon standards that software and hardware use to communicate. 

<BR></P>

<P>Protocols are usually layered, with higher levels using the lower ones as building blocks. For instance, the Internet Protocol (IP) sends packets of data back and forth without building an end-to-end connection such as-used by SMTP and other 
higher-level protocols. The Transmission Control Protocol (TCP) is built on top of IP and provides for connection-oriented services like those used by programs such as telnet and the Simple Mail Transfer Protocol (SMTP). Together, TCP/IP provide the basic 

network services for the Internet. Higher-level protocols like the File Transfer Protocol (FTP) and SMTP are built on top of TCP/IP. The advantage of such layering is that programs which implement the SMTP or FTP protocols don't have to know anything about 

transporting packets on the network and making connections to other hosts. They can use the services provided by TCP/IP for that.

<BR></P>

<P>SMTP defines how programs exchange e-mail on the Internet. It doesn't matter whether the program exchanging the e-mail is sendmail running on an HP workstation or an SMTP client written for an Apple Macintosh. As long as both programs implement the SMTP 

protocol correctly, they will be able to exchange mail.

<BR></P>

<P>The following example of the SMTP protocol in action may help demystify it a little. The user betty at gonzo.gov is sending mail to joe at whizzer.com:

<BR></P>

<PRE>$ sendmail -v [e-mail] &lt; letter

[e-mail]... Connecting to whizzer.com via tcp...

Trying 123.45.67.1...  connected.

220-whizzer.com SMTP ready at Mon, 6 Jun 1994 18:56:22 -0500

220 ESMTP spoken here

&gt;&gt;&gt; HELO gonzo.gov

250 whizzer.com Hello gonzo.gov [123.45.67.2], pleased to meet you

&gt;&gt;&gt; MAIL From:&lt;[e-mail]&gt;

250 &lt;[e-mail]&gt;... Sender ok

&gt;&gt;&gt; RCPT To:&lt;[e-mail]&gt;

250 &lt;[e-mail]&gt;... Recipient ok

&gt;&gt;&gt; DATA

354 Enter mail, end with &quot;.&quot; on a line by itself

&gt;&gt;&gt; .

250 SAA08680 Message accepted for delivery

&gt;&gt;&gt; QUIT

221 whizzer.com closing connection

[e-mail]... Sent

$</PRE>

<P>The first line shows one way to invoke sendmail directly rather than letting your favorite MUA do it for you. The -v option tells sendmail to be verbose and shows you the SMTP dialogue. The other lines show an SMTP client and server carrying on a 
conversation. Lines prefaced with &gt;&gt;&gt; are the client (or sender) on gonzo.gov, and the lines that immediately follow are the replies of the server (or receiver) on whizzer.com. The first line beginning with 220 is the SMTP server announcing itself 

after the initial connection, giving its hostname and the date and time, and the second line informs the client that this server understands the Extended SMTP protocol (ESMTP) in case the client wants to use it. Numbers such as 220 are reply codes that the 

SMTP client uses to communicate with the SMTP server. The text following the reply codes is only for human consumption.

<BR></P>

<P>Although this dialogue may still look a little mysterious, it will soon be old hat if you take the time to read RFC 821. Running sendmail with its -v option also helps you understand how an SMTP dialogue works.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I12" NAME="I12">

<FONT SIZE=3><B>The Domain Name System (DNS) and E-Mail</B>

<BR></FONT></A></CENTER></H4>

<P>Names like whizzer.com are convenient for humans, but computers insist on using numeric IP addresses like 123.45.67.1. The Domain Name System (DNS) provides this hostname to IP address translation and other important information.

<BR></P>

<P>In the olden days when most of us walked several miles to school through deep snow, there were only a few thousand hosts on the Internet. All hosts were registered with the Network Information Center (NIC), which distributed a host table listing the 
host names and IP addresses of all the hosts on the Internet. Those simple times are gone forever. No one really knows how many hosts are connected to the Internet now, but they number in the millions, and an administrative entity like the NIC can't keep 
their names straight. Thus was born the DNS.

<BR></P>

<P>The DNS distributes authority for naming and numbering hosts to autonomous administrative domains. For instance, a company whizzer.com could maintain all the information about the hosts in its own domain. When the host a.whizzer.com wished to send mail 

or telnet to the host b.whizzer.com, it would send an inquiry over the network to the whizzer.com name server, which might run on a host named ns.whizzer.com. The ns.whizzer.com name server would reply to a.whizzer.com with the IP address of b.whizzer.com 

(and possibly other information), and the mail would be sent or the telnet connection made. Because ns.whizzer.com is authoritative for the whizzer.com domain, it can answer any inquiries about whizzer.com hosts regardless of where they originate; the 
authority for naming hosts in this domain has been delegated.

<BR></P>

<P>Now, what if someone on a.whizzer.com wants to send mail to [e-mail]? Ns.whizzer.com has no information about hosts in the gonzo.gov domain, but it knows how to find out. When a name server receives a request for a host in a domain for which it has 

no information, it asks the root name servers for the names and IP addresses of servers authoritative for that domain, in this case gonzo.gov. The root name server gives the ns.whizzer.com name server the names and IP addresses of hosts running name 
servers with authority for gonzo.gov. The ns.whizzer.com name server enquires of them and forwards the reply back to a.whizzer.com.

<BR></P>

<P>From the description above you can see that the DNS is a large, distributed database containing mappings between hostnames and IP addresses, but it contains other information as well. When a program like sendmail delivers mail, it must translate the 
recipient's host name into an IP address. This bit of DNS data is known as an A (Address) record, and it is the most fundamental data about a host. A second piece of host data is the Mail eXchanger (MX) record. An MX record for a host like a.whizzer.com 
lists one or more hosts that are willing to receive mail for it.

<BR></P>

<P>What's the point?  Why shouldn't a.whizzer.com simply receive its own mail and be done with it? Isn't a postmaster's life complicated enough without having to worry about mail exchangers?  Well, while it's true that the postmaster's life is often overly 

complicated, MX records serve useful purposes:

<BR></P>

<UL>

<LI>Hosts not on the Internet (e.g., UUCP-only hosts) may designate an Internet host to receive their mail and so appear to have an Internet address. For instance, suppose that a.whizzer.com is only connected to ns.whizzer.com once a day via a UUCP link. 
If ns.whizzer.com publishes an MX record for it, other Internet hosts can still send it mail. When ns.whizzer.com receives the mail, it saves it until a.whizzer.com connects. This use of MX records allows non-Internet hosts to appear to be on the Internet 

(but only to receive e-mail).

<BR>

<BR></LI>

<LI>Imagine a UNIX host pcserv.whizzer.com that acts as a file server for a cluster of personal computers. The PC clones have MUAs with built-in SMTP clients that allow them to send mail, but not receive mail. If return addresses on the outbound mail look 

like [e-mail], how can people reply to the mail?  MX records come to the rescue again &#151; pcserv.whizzer.com publishes itself as the MX host for all the PC clones, and mail addressed to them is sent there.

<BR>

<BR></LI>

<LI>Hosts may be off the Internet for extended times because of unpredictable reasons ranging from lightning strikes to the propensity of backhoe operators to unexpectedly unearth, fiber-optic cables. While your host is off the Internet, its mail queues on 

other hosts, and after a while it bounces back to the sender. If your host has MX hosts willing to hold its mail in the interim, the mail will be delivered when your host is available again. The hosts can be either on-site (i.e., in your domain) or 
off-site, or both. The last option is best, since backhoe operator disasters usually take your entire site off the net, in which case an on-site backup does no good.

<BR>

<BR></LI>

<LI>MX records hide information and allow you more flexibility to reconfigure your local network. If all your correspondents know that your e-mail address is [e-mail], it doesn't matter whether the host that receives mail for whizzer.com is named 
zippy.whizzer.com or pinhead.whizzer.com. It also doesn't matter if you decide to change it to white-whale.whizzer.com; your correspondents will never know the difference.

<BR>

<BR></LI></UL>

<H5 ALIGN="CENTER">

<CENTER><A ID="I13" NAME="I13">

<FONT SIZE=3><B>Mail Delivery and MX Records</B>

<BR></FONT></A></CENTER></H5>

<P>When an SMTP client delivers mail to a host, it must do more than translate the hostname into an IP address. First, it asks for MX records. If any exist, it sorts them according to the priority given in the record. For instance, whizzer.com might have 
MX records listing the hosts mailhub.whizzer.com, walrus.whizzer.com, and mailer.gonzo.gov as the hosts willing to receive mail for it (and the &quot;host&quot; whizzer.com might not exist except as an MX record, meaning that there might be no IP address 
for it). Although any of these hosts will accept mail for whizzer.com, the MX priorities specify which of those hosts the SMTP client should try first, and properly behaved SMTP clients will do so. In this case the system admin-istrator has set up a 
primary mail relay mailhub.whizzer.com, an on-site backup walrus.whizzer.com, and arranged with the system administrator at mailer.gonzo.gov for an off-site backup. They have set the MX priorities so that SMTP clients will try the primary mail relay first, 

the on-site backup second, and the off-site backup third. This setup takes care of the problems with the vendor who doesn't ship your parts on time as well as the wayward backhoe operator, who severs the fiber optic cable that provides your site's Internet 

connection.

<BR></P>

<P>After collecting and sorting the MX records, the SMTP client gathers the IP addresses for the MX hosts and attempts delivery to them in order of MX preference. You should keep this in mind when debugging mail problems. Just because a letter is addressed 

to [e-mail], it doesn't necessarily mean that a host named whizzer.com exists. Even if it does, it might not be the host that is supposed to receive the mail.

<BR></P>

<H5 ALIGN="CENTER">

<CENTER><A ID="I14" NAME="I14">

<FONT SIZE=3><B>Header and Envelope Addresses</B>

<BR></FONT></A></CENTER></H5>

<P>The distinction between header and envelope addresses is important because mail routers may process them differently. An example will help explain the difference between the two.

<BR></P>

<P>Suppose you have a paper memo that you want to send to your colleagues Mary and Bill at the Gonzo corporation, and Ted and Ben at the Whizzer company. You give a copy of the memo to your trusty mail clerk Alphonse, who notes the multiple recipients. 
Since he's a clever fellow who wants to save your company 29 cents, he makes two copies of the memo and puts each in an envelope addressed to the respective companies (rather than sending a copy to each recipient). On the cover of the Gonzo envelope he 
writes Mary and Bill, and on the cover of the Whizzer envelope he writes Ted and Ben. When his counterparts at Gonzo and Whizzer receive the envelopes, they make copies of the memo and send them to Mary, Bill, Ted and Ben, without inspecting the addresses 

in the memo itself. As far as the Gonzo and Whizzer mail clerks are concerned, the memo itself might be addressed to the pope; they only care about the envelope addresses.

<BR></P>

<P>SMTP clients and servers work in much the same way. Suppose that [e-mail] sends mail to his colleagues [e-mail] and [e-mail]. The recipient list in the letter's headers may look like this:

<BR></P>

<PRE>To: [e-mail], [e-mail]</PRE>

<P>The SMTP client at gonzo.gov connects to the whizzer.com mailer to deliver Fred's copy. When it's ready to list the recipients (the envelope address), what should it say?  If it gives both recipients as they are listed in the To: line above (the header 

address), Betty will get two copies of the letter because the whizzer.com mailer will forward a copy to zippy.gov. The same problem occurs if the gonzo.gov SMTP client connects to zippy.gov and lists both Betty and Fred as recipients. The zippy.gov mailer 

will forward a second copy of Fred's letter.

<BR></P>

<P>The solution is the same one that Alphonse and his fellow mail clerks used. The gonzo.gov SMTP client puts an envelope around the letter that contains only the names of the recipients on each host. The complete recipient list is still in the letter's 
headers, but those are inside the envelope, and the SMTP servers at gonzo.gov and whizzer.com don't look at them. In this example, the envelope for the whizzer.com mailer would list only fred, and the envelope for zippy.gov would only list betty.

<BR></P>

<P>Aliases illustrate another reason why header and envelope addresses differ. Suppose you send mail to the alias homeboys, which includes the names alphonse, joe, betty, and george. In your letter you write To: homeboys. However, sendmail expands the 
alias and constructs an envelope that includes all of the recipients. Depending on whether those names are also aliases, perhaps on other hosts, the original message might be put into as many as four different envelopes and delivered to four different 
hosts. In each case the envelope will contain only the name of the recipients, but the original message will contain the alias homeboys (expanded to homeboys@<I>your.host.domain</I> so replies will work).

<BR></P>

<P>A final example shows another way in which envelope addresses may differ from header addresses. sendmail allows you to specify recipients on the command line. Suppose you have a file named letter that looks like this:

<BR></P>

<PRE>$ cat letter

To: null recipient &lt;&gt;

Subject: header and envelope addresses

testing</PRE>

<P>and you send it with the following command (substituting your own login name for <I>yourlogin</I>):

<BR></P>

<PRE>$ sendmail yourlogin &lt; letter</PRE>

<P>You will receive the letter even though your login name doesn't appear in the letter's headers because your address was on the envelope. Unless told otherwise (with the -t flag),  sendmail constructs envelope addresses from the recipients you specify on 

the command line, and there isn't necessarily a correspondence between the header addresses and the envelope addresses.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I15" NAME="I15">

<FONT SIZE=3><B>sendmail's Jobs</B>

<BR></FONT></A></CENTER></H4>

<P>To better understand how to set up sendmail, you need to know what different jobs it does and how those jobs fit into the scheme of MUAs, MTAs, mail routers, final delivery agents, and SMTP clients and servers. sendmail can act as a mail router, an SMTP 

client and an SMTP server. However, it does not do final delivery of mail.

<BR></P>