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 care only about the envelope addresses.

SMTP clients and servers work in much the same way. Suppose that joe@gonzo.gov sends mail to his colleagues betty@zippy.gov and fred@whizzer.com. The recipient list in the letter's headers may look like this:

To: betty@zippy.gov, fred@whizzer.com

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 preceding To: line (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.

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 they 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 list only betty.

Aliases illustrate another reason that header and envelope addresses differ. Suppose that 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 the recipients. Depending on whether the 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@your.host.domain so replies will work).

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

$ cat letter

To: null recipient <>

Subject: header and envelope addresses



testing

You send this letter with the following command (substituting your own login name for yourlogin):

$ sendmail yourlogin < letter

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 a correspondence doesn't necessarily exist between the header addresses and the envelope addresses.

sendmail's Jobs

To better understand how to set up sendmail, you need to know what different jobs it does and how these 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.

sendmail as a Mail Router

sendmail is primarily a mail router, meaning it takes a letter, inspects the recipient addresses, and decides the best way to send it. How does sendmail perform this task?

sendmail determines some of the information it needs on its own, such as the current time and the name of the host on which it's running, but most of its brains are supplied by you, the postmaster, in the form of a configuration file, sendmail.cf. This somewhat cryptic file tells sendmail exactly how you want various kinds of mail handled. It is extremely flexible and powerful, and at first glance seemingly inscrutable. However, one of the strengths of V8 sendmail is its set of modular configuration file building blocks. Most sites can easily construct their configuration files from these modules, and many examples are included. Writing a configuration file from scratch is a daunting task, so you should avoid it if you can.

sendmail as an MTA—Client (Sender) and Server (Receiver) SMTP

As mentioned before, sendmail can function as an MTA because it understands the SMTP protocol (V8 sendmail also understands ESMTP). Because SMTP is a connection-oriented protocol, a client and a server (also known as a sender and a receiver) always exist. The SMTP client delivers a letter to an SMTP server, which listens continuously on its computer's SMTP port. sendmail can be an SMTP client or an SMTP server. When run by an MUA, it becomes an SMTP client and speaks client-side SMTP to an SMTP server (not necessarily another sendmail program). When your system boots and it starts in daemon mode, it runs continuously, listening on the SMTP port for incoming mail.

sendmail as a Final Delivery Agent (NOT!)

One thing sendmail doesn't do is final delivery. sendmail's author wisely chose to leave this task to other programs. sendmail is a big, complicated program that runs with superuser privileges, an almost guaranteed recipe for security problems, and quite a few have occurred in sendmail's past. The additional complexity of final mail delivery is the last thing sendmail needs.

sendmail's Auxiliary Files

sendmail depends on a number of auxiliary files to do its job. The most important are the aliases file and the configuration file, sendmail.cf. The statistics file, sendmail.st, can be created or not, depending on whether you want the statistics. sendmail.hf, which is the SMTP help file, should be installed if you intend to run sendmail as an SMTP server (most sites do). That's all that needs to be said about sendmail.st and sendmail.hf. (Other auxiliary files are covered in the Sendmail Installation and Operating Guide, or SIOG for short.) The aliases and sendmail.cf files, on the other hand, are important enough to be covered in their own sections.

The Aliases File

sendmail always checks recipient addresses for aliases, which are alternative names for recipients. For example, each Internet site is required to have a valid address postmaster to whom mail problems can be reported. Most sites don't have an actual account of that name but divert the postmaster's mail to the person or persons responsible for e-mail administration. For example, at the mythical site gonzo.gov, the users joe and betty are jointly responsible for e-mail administration, and the aliases file has the following entry:

postmaster: joe, betty

This line tells sendmail that mail to postmaster should instead be delivered to the login names joe and betty. In fact, these names could also be aliases:

postmaster: firstshiftops, secondshiftops, thirdshiftops

firstshiftops: joe, betty

secondshiftops: lou, emma

thirdshiftops: ben, mark, clara

In all these examples, the alias names are on the left side of the colon, and the aliases for those names are on the right side. sendmail repeatedly evaluates aliases until they resolve to a real user or a remote address. In the preceding example, to resolve the alias postmaster, sendmail first expands it into the list of recipients firstshiftops, secondshiftops, and thirdshiftops and then expands each of these aliases into the final list—joe, betty, lou, emma, ben, mark, and clara.

Although the right side of an alias can refer to a remote host, the left side cannot. The alias joe: joe@whizzer.com is legal, but joe@gonzo.gov: joe@whizzer.com is not.

Reading Aliases from a File—The :include: Directive

Aliases can be used to create mailing lists. (In the example shown in the preceding section, the alias postmaster is in effect a mailing list for the local postmasters.) For big or frequently changing lists, you can use the :include: alias form to direct sendmail to read the list members from a file. If the aliases file contains the line

homeboys: :include:/home/alphonse/homeboys.aliases