Наши партнеры








Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Linux System Administrator's Survival Guide lsg34.htm

Previous Page TOC Next Page



Chapter 34


E-mail and Linux


Almost everyone who has a Linux system wants to expand its use to allow e-mail. Local area network users especially want to implement e-mail because it is one of the primary attractions of LANs. Linux offers its users several different e-mail systems. The next few chapters look at the most popular and useful of these systems. This chapter explains the background information that's necessary to know in order to use e-mail as well as the basic configuration steps for all e-mail packages.

Linux Mail Software


An e-mail system on Linux has two components: the mail user agent (called an MUA), which is your interface to the mail package that you use to write and read mail, and the underlying mail transport agent (called an MTA), which handles the sending and receiving of mail. There are two MTAs in common use with Linux and dozens of MUAs available.

There are probably more versions of e-mail MTAs and MUAs available for Linux than any other software application (with the possible exception of editors). The most widely used e-mail MTA system for Linux is sendmail, which is based on an e-mail system developed at the University of California at Berkeley. Several versions of sendmail are available for Linux; each version has slightly different capabilities. Another commonly used e-mail system for Linux is smail, developed by Curt Noll and Ronald Karr. Again, several versions of smail are currently available for Linux.

Because both sendmail and smail are supplied with most CD-ROM distributions of Linux, you may be wondering which mail system you should use. For small installations, either system works fine. In some ways, smail is slightly easier to configure and use, primarily because it is a more modern product. For larger systems or those with special configuration requirements, sendmail is more flexible and offers more configuration capabilities.

Both sendmail and smail require you to customize the packages through configuration files, although the processes are different for each package. For basic e-mail requirements, such as a connection to a mail server or other machines in a network, the process is quite simple. The exception is sendmail, which has a very complex configuration file. Its configuration file is so complex that sendmail is usually used with a utility called IDA (the set is called sendmail+IDA), which makes configuring the package much easier.

When you write a mail message using one of the mail user agent (MUA) user interface programs (such as Elm, Pine, or mail) on your Linux system, the application passes the message to the mail transfer agent (MTA), such as sendmail or smail. (Actually, the MUAs pass the message to a generic delivery transport called rmail, which is usually aliased to the specific MTA you want to use.) You can have several MTAs running at once (such as one package for LAN-based e-mail delivery and another for UUCP delivery), although most systems only use one for convenience.

If the mail message is for someone on the local area network (or even the same machine), the MTA should be able to figure out this information from the address. MTAs must be able to understand aliasing as well, in case you call machines, networks, or users by different names. If the message is for a remote system user, the MTA must be able to establish a connection to a mail machine somewhere along the route to the destination and transfer the mail. The connection can be either UUCP or TCP based. If the latter is used, a transfer protocol called Simple Mail Transfer Protocol (SMTP) is often employed. The MTA must also be able to handle problems with the delivery of mail, such as when the destination machine is unavailable or the user doesn't exist. In this case, the mail is returned to the sender with an error message.

An e-mail system must be able to handle addresses for the sender and recipient in several formats. Commonly used formats are the UUCP-style bang addresses, such as merlin!brutus!tpci.com!tparker (which means transfer the mail to merlin, then brutus, and then tpci.com to the user tparker), and domain names, such as tparker@tpci.com. The UUCP style usually shows the complete path to the target machine, and domain names use an address resolution system to work out the path. Other address systems are also used (such as DECnet and % addressing), although UUCP and domain names are the most often used.

The routing of the mail messages to the destination is an important aspect of the MTA software and differs depending on whether UUCP (in which case the complete path is usually specified) or domain name (in which case the route must be deduced) addressing is used. For TCP-based addressing (usually using domain names), the default action is for an MTA is to deliver messages to the destination machine based on the IP address and ignore the routing, leaving that to the IP software in the TCP/IP drivers.

To simplify mail delivery for larger networks or systems where a single machine acts as the interface to the Internet, a local area network can publish an MX (Mail Exchanger) record that is interpreted by the domain name system (DNS) as an instruction to route all mail for that domain to the single machine (which further distributes it through the LAN). The MX record allows machines that are not connected to the Internet all the time to have mail received by a host, which UUCP or TCP can then connect to occasionally. An MX record looks like the following:


merlin.tpci.com IN MX 3 bigserver.tpci.com

This line tells the DNS system that any mail for merlin.tpci.com should be sent to the system bigserver.tpci.com. The IN entry identifies the type of resource record involved (important to TCP/IP), and MX shows that this record is an MX record. The number 3 in this example is a preference number. A network can have several mail servers, each of which has a preference number. The lower numbers are used by transfer software first; the software moves to the higher numbers only when the lower numbered machines aren't responding.

A UUCP network handles mail differently. In the early days of UUCP usage, the entire path to the destination machine had to be specified, with each hop along the way explicitly laid out. The increasing size of networks made this specification impractical for all but small local area networks, so a mapping system was developed. The UUCP Mapping Project maintains a list of all official UUCP site names and their neighbors, allowing a UUCP-based transport to find the route to a destination machine by querying the map. The maps are called USENET Maps and are sent out over the Internet regularly to update hosts.

E-Mail Structure


To understand how mail systems work, you should know what a mail message looks like. A mail message consists of the text of the message (called the body) and a chunk of information at the beginning of the message that contains information about who sent the message, where it is going, and so on(called the header). Usually the header and body of the mail message are separated by a blank line. Many messages also include a chunk of data at the end of the message that is called the signature. The signature is a bit of ASCII data written by the sender to be included in every message; it usually gives information about the sender and may contain a pithy saying.

The header is made up of two parts. The first part contains information about the sender and recipient and includes their addresses. This portion is often called the envelope. The second part of the header has information specific to the handling of the mail message, including the subject, the transport used to send the message, recipients on a copy list, the date, and similar information.

The header of a mail message consists of a number of lines separated by newline characters. Each line has a field name followed by a colon and the contents of the field. The following is an extract from a header file:


From brutus!bignet.com Thu Sep 21 17:40:32 1995

Received: from bignet.com by tpci.tpci.com id aa00184; 21 Sep 95 17:39 EDT

Received: from mailserv.biggernet.com ([147.77.1.1]) by bignet.com with

 SMTP id <250079-4>; Thu, 21 Sep 1995 20:48:04 -0400

Received: by biggernet.com (4.1/SMI-4.1)

 id AA00266; Thu, 21 Sep 95 17:39:03 PDT

Date: Thu, 21 Sep 1995 20:39:03 -0400

From: Yvonne <yvonne@chatton.bignet.com>

Message-Id: <9509220039.AA00266@yvonne@chatton.bignet.com>

To: tparker@tpci.com

Subject: Important stuff

Cc: prudie@bignet.com

The first few lines of the header show who sent the message and how it got to its destination. The rest of the header shows the date, message ID (each message has a unique identification number), the subject line, and any users copied on the message. Each line has the field:value format, although the exact layout of each line changes depending on the field. The following fields are normally found in a mail message:

  • There are two From fields. The first shows which machine last transferred the mail to your system, and the second (further down the header) is the sender's e-mail address (and sometimes the sender's name from the /etc/passwd file). This field can have many different formats, including UUCP-style bang addressing and full domain name formats.

  • Each machine that the message passes through adds a line to the Received field to show where the message was received from and when it was received. This information enables you to trace the message back to its source.

  • The Date field shows the date that the e-mail was sent (based on local machine time and date).

  • The Message-Id field lists a unique identifying number for the message.

  • The To field shows who the e-mail is for.

  • The sender provides the information in the Subject field to describe what the mail is about.

  • The Cc field gives the ID of anyone else who was copied on the message.

Depending on the mail system in use, some mail message headers include the following fields as well:

  • The Reply-To field shows the address that the sender wants any reply sent to. This field is usually used when you have more than one user account and want the replies sent to an account other than the sending one.

  • The Organization field provides the name of the company that owns the machine you are using. This optional field is often left blank or set to private for non-corporate machines.

  • The letter X followed by identifying tags is used to add features to the basic message format. Both ends of the connection must be able to handle this feature.

Almost all mail systems used with Linux have a common layout based on a formal specification called RFC 822. RFC 822 is only a base set, however, and many products have built on it to include extensions for multimedia, special character sets, encryption, and so on. For messages to be read properly, both ends of the mail path (sender and receiver) have to be able to handle the extensions in the same manner.

Summary


E-mail has its own sophisticated format and transport systems, but most of the details are hidden from users and system administrators. Once a system has been configured with local site information, an administrator's involvement is finished except for checking for proper functioning and cleaning up log files.

Now that you've seen the basics of an e-mail system, you can move in to specific MTAs. The two most often found in Linux are smail and sendmail+IDA, which are covered in their own chapters. After that, you can look at configuring a typical mail reader (MUA).

Previous Page Page Top TOC Next Page