8. Addresses and Rules

Contents:
A Fictional Network
Why Rules?
Rule Sets
Rules
The Workspace
The Flow of Addresses Through Rules
Wildcard Operators
Things to Try

Before delving into the inner workings of rules, we need to create a fictional network to provide a common ground for discussing mail addresses.

8.1 A Fictional Network

Consider the network shown in Figure 8.1. It consists of three sites (the clouds) that are interconnected by high-speed networks (the solid lines). Each site is a DNS domain composed of many individual computers. Each domain is set up differently, as we will show, but from the user's point of view, the process of sending mail from a machine in one domain to a machine in another is the same in all cases.

Figure 8.1: Domains in our fictional network

A domain name is interpreted right to left. The com in .acme.com, for example, means that acme is a part of the top-level domain com (for commercial). There are many commercial sites in the com top-level domain, but only one acme among them. Similarly, edu is the top-level domain for educational institutions (such as colleges and universities), and gov is the top-level domain for government organizations.

A domain can consist of many machines. Each machine inside a domain has a fully qualified domain name that consists of a hostname, a dot, and then its domain name. For example, sec.acme.com is a fully qualified domain name because it consists of the hostname sec, a dot, then the domain name acme.com.

Host and domain names are case-insensitive. That is, sec.acme.com may be expressed in any of the following ways:

sec.acme.com        good
SEC.Acme.COM        also good
sEc.aCmE.cOm        ugly, but also good

8.1.1 The dc.gov Domain

Figure 8.2 shows the dc.gov domain from the inside. It is composed of three machines (although in the real world it might be composed of many more). These three machines are connected together on a private network for security (the solid lines). Only one machine, fbi.dc.gov, has a connection to the outside world. Mail from the outside world always goes to fbi.dc.gov first; from there it is forwarded to the appropriate machine on the internal network. For example, the user george eventually receives his mail on his own machine (wash.dc.gov), even though that mail is first handled by fbi.dc.gov.

Figure 8.2: The dc.gov domain is accessible only through fbi.dc.gov

The fbi.dc.gov machine is called a gateway because it forms a gate between the internal and external networks through which all network traffic (such as mail) must flow. It is also called a forwarder, because it accepts mail for machines on the internal network, then forwards mail to them.

Despite the presence of a gateway, users in .dc.gov still receive mail on their individual machines. Inside .dc.gov, mail from one machine to another goes directly over the internal network. The gateway is not involved. But mail destined for the outside world must always first go to the gateway, which then forwards that mail over the outside network.

Mail that is addressed to the domain (dc.gov rather than a specific machine such as wash.dc.gov) will be delivered to the gateway machine. Unfortunately, in our fiction the gateway does not know about any of the users at other machines in the domain. As a consequence, mail to a user at the domain (user@dc.gov) will bounce.

8.1.2 The acme.com Domain

Figure 8.3 shows the .acme.com domain. It is different from .dc.gov because all machines are connected directly to the outside world and to one another.

Figure 8.3: All machines in acme.com connect to the outside world

All machines can directly receive mail from the outside world. For example, the user tim receives and reads his mail on the machine boss.acme.com, but unlike the previous network, there is no gateway.

Like fbi.dc.gov, the machine sec.acme.com will receive all mail addressed to the domain acme.com. But unlike the gateway fbi.dc.gov, sec.acme.com knows about all the users in its domain. [1] So mail to tim@acme.com will be correctly forwarded to tim at boss.acme.com.

[1] It runs nis (formerly Yellow Pages) and can mount the home directories of all users.

8.1.3 The us.edu Domain

Figure 8.4 shows a third way to set up a domain. In this domain, all mail (both inside and outside) is delivered to the machine mail.us.edu. Unlike the previous two examples, no mail is ever delivered to the other machines. Instead, it is delivered into the master spool directory on mail.us.edu. The other machines then network mount that directory so that users can read their mail from any machine.

Figure 8.4: Only mail.us.edu receives mail in the domain us.edu

Under this system, mail addresses need to contain only the name of the local recipient, an @, and the name of the domain (such as user@us.edu). This arrangement eliminates the need for users elsewhere in the world to know any specific machine's name.

All three forms of domains have their advantages and disadvantages. We don't favor any one above another. In this and the chapters to follow, we consider our machine to be in the us.edu domain. We selected it only because it allows the simplest sendmail configuration file to be used.

8.1.4 UUCP and Host Paths

In addition to our fictional network, consider two hosts that are connected to acme.com using dial-up lines (see Figure 8.5). Under UUCP, one needs to know exactly how hosts are connected in order to send mail to any one of them. To get from sec.acme.com to sonya, for example, the mail needs to go through lady first.