Page 97
Page 98
Electronic mail (e-mail) is arguably the most used application of any data network such as the Internet. (Yes, even more so than the World Wide Web!) Early in the Internet's life, there were many proposed standards for e-mail between systems. These standards changed often, and the corresponding software changes were significant.
During this time of rapid change in e-mail protocols, a package emerged as a standard for mail transfer—sendmail. sendmail, written by Eric Allman of UC Berkeley, was an unusual program for its time because it thought of the e-mail problem in a different light. Instead of rejecting e-mail from different networks using so-called incorrect protocols, it massaged the message and fixed it so that the message could be passed on to its destination. The side effect of this level of configurability has been complexity. Several books have been written on the subject (the authoritative texts have reached over 1000 pages); however, for most administrators those are overkill.
One of the key features of sendmail that differentiated it from other mail transfer agents (MTAs) during the '80s was the separation of mail routing, mail delivery, and mail readers. sendmail performed mail routing functions only, leaving delivery to local agents that the administrator could select. This also allowed users to select their preferred mail readers as long as they could read the format of the messages written by the delivery software.
With the advent of larger heterogeneous networks, the need for mail readers that worked on network clients and connected to designated mail servers to send and receive mail gave way to the Post Office Protocol (POP). POP mail readers have since flourished with client software available for every imaginable platform and server software available for not only various implementations of UNIX (including Linux) but for other less robust operating systems as well.
This chapter covers the most recent work on sendmail, its underlying protocol SMTP, and the qpopper package which implements POP support for Linux.
The Simple Mail Transfer Protocol (SMTP) is the established standard way of transferring mail over the Internet. The sendmail program provides the services needed to support SMTP connections for Linux.
This section covers the various details needed to understand the sendmail package, install it, and configure it. Before getting into the details, however, I'll take a moment to discuss the SMTP protocol in better detail and how the Domain Name System (DNS) (see Chapter 13, "TCP/IP Network Management," for details on DNS configuration) interacts with e-mail across the Internet.
Armed with a better understanding of the protocols, you can take on understanding sendmail itself beginning with the various tasks that sendmail performs (such as mail routing, header rewriting, and so on) as well as its corresponding configuration files.
Page 99
| WARNING |
As with any large software package, sendmail has its share of bugs. Although the bugs that cause sendmail to fail or crash the system have been almost completely eliminated, security holes that provide root access are still found from time to time. |
To understand the different jobs that sendmail performs, you need to know a little about Internet protocols. Protocols are simply agreed-upon standards that software and hardware use to communicate.
Protocols are usually layered, with higher levels using the lower ones as building blocks. For example, 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), which is built on top of IP, provides for connection-oriented services such as those used by programs such as Telnet and the Simple Mail Transfer Protocol (SMTP). Together, TCP/IP provides the basic network services for the Internet. Higher-level protocols such as 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 job.
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 can exchange mail.
The following example of the SMTP protocol in action might help demystify it a little. The user betty at gonzo.gov is sending mail to joe at whizzer.com:
$ sendmail -v [email protected] < letter [email protected]... Connecting to whizzer.com via tcp... Trying 123.45.67.1... connected. 220-whizzer.com SMTP ready at Mon, 6 Jun 1997 18:56:22 -0500 220 ESMTP spoken here >>> HELO gonzo.gov 250 whizzer.com Hello gonzo.gov [123.45.67.2], pleased to meet you >>> MAIL From:<[email protected]> 250 <[email protected]>... Sender ok >>> RCPT To:<[email protected]>
Page 100
250 <[email protected]>... Recipient ok >>> DATA 354 Enter mail, end with "." on a line by itself >>> . 250 SAA08680 Message accepted for delivery >>> QUIT 221 whizzer.com closing connection [email protected]... Sent $
The first line shows one way to invoke sendmail directly rather than let your favorite Mail User Agent (MUA) such as Elm, Pine, or Mutt 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 >>> indicate 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.
Although this dialogue might still look a little mysterious, it will soon be very familiar if you take the time to read RFC 821. Running sendmail with its -v option also helps you understand how an SMTP dialogue works.
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.
In the old 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 hostnames 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.
The DNS distributes authority for naming and numbering hosts to autonomous administrative domains. For example, a company called whizzer.com could maintain all the information about the hosts in its own domain. When the host a.whizzer.com wants to send mail or Telnet to the host b.whizzer.com, it sends an inquiry over the network to the whizzer.com nameserver, which might run on a host named ns.whizzer.com. The ns.whizzer.com nameserver 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.