10.7.1 Modifying Local Information

The first line in the local information section of the sendmail.cf file defines class w. [21] Class w is the full set of host names for which this system accepts mail. Use the class w command to add hostnames to this set. sendmail initializes this class to the value in macro w ($w), which is the hostname of this computer. On most systems that is enough; sendmail is able to correctly identify most of the other hostnames for which it should accept mail by querying DNS. The w class needs only to identify systems that expect this host to accept mail for them and that do not have CNAME or MX entries in the DNS that point to this host. You'll need to add a hostname to class w, or an MX record to DNS, if you see the following mail error:

[21] The full text of the local information section is shown in Appendix E.

mil-gw.nuts.com. config error: mail loops back to me (MX problem?)

In our sample, we accept the Cw command as written, and let sendmail define the value for w internally. This is the most common method for desktop systems like peanut. On the system almond, which is also known by the name mil-gw, we would add values to class w as follows:

Cwlocalhost mil-gw mil-gw.nuts.com

Now mail addressed to [email protected] would be accepted by almond and not rejected as being addressed to the wrong host.

Some mail servers might need to be configured to accept mail for many different hostnames. In that case you may want to load class w from a file containing all of the hostnames. Do that with the F command.

No modification is necessary for the j macro definition because, on this system, sendmail obtains a fully qualified domain name for the j macro from DNS. On some systems this is the case; on other systems sendmail obtains the hostname without the domain extension. If j doesn't contain the full name, initialize j with the hostname ($w) and the domain name. In the sample file we would do this by "uncommenting" the Dj command and editing the domain string to be nuts.com. However, there is no need to do this because j has the correct value.

To test if j is set to the correct value on your system, run sendmail with the -bt option and the debug level set to 0.4. In response to this, sendmail displays several lines of information, including the value of j. In the example below, sendmail displays the value peanut.nuts.com for j. If it displayed only peanut, we would edit sendmail.cf to correct the value for j.

# sendmail -bt -d0.4
Version 8.8.5
 Compiled with: LOG MATCHGECOS MIME8TO7 NAMED_BIND NDBM
                NETINET NETUNIX NEWDB SCANF USERDB XDEBUG
canonical name: peanut.nuts.com
 UUCP nodename: peanut
        a.k.a.: peanut.nuts.com
        a.k.a.: [172.16.12.2]

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = peanut
  (canonical domain name) $j = peanut.nuts.com

         (subdomain name) $m = nuts.com
              (node name) $k = peanut
========================================================

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> ^D

The next line in the local information section defines class P. In our sample configuration file, class P stores the names of some special mail routing domains. These pseudo-domain names allow us to address users who are not on the Internet with Internet style email addresses. For example, mail can be addressed using the normal UUCP "bang" syntax, e.g., ora!los!craig, or it can be addressed in a pseudo-Internet format, e.g., [email protected]. These mail routing domains simplify the address that the user enters, and route the mail to the correct mail relay host. However, pseudo-domains are rarely needed because most mailers now support standard Internet-style addresses. The class P definition in linux.smtp.cf does not require any modification. The only value assigned as a pseudo-domain is a dot (.), which is used in this sendmail.cf file to identify canonical domain names.

The configuration file has macro definitions for several mail relays. None of these are assigned a value in our sample file. You only need a relay host if your system cannot deliver the mail because it lacks capability or connectivity. UNIX systems do not lack capability, but a firewall might limit connectivity. Some sites use a mail relay so that only one systems needs a full sendmail.cf configuration. The other hosts at the site simply forward their mail to the smart host for delivery. If this is the configuration policy of your site, enter the name of the mail relay as the "smart" relay. For example:

DSrelay.nuts.com

We don't enter anything in any of the relay settings on peanut. This desktop system will handle all its own mail. Hey, that's why we run UNIX!

The local information section in the sample file also includes four key file definitions. Three of these K commands are commented out, and all four of them can be ignored. The one key file definition that is not commented out defines the dequote database, which is an internal sendmail database used to remove quotes from within email addresses. The user key file, which is commented out, is also an internal database. It is used to check if a username exists. The last two databases exist only if you create them. The domaintable is used to rewrite domain names and the mailertable database is used to send mail addressed to a specific domain through a particular mailer to a specific remote host.

The version number doesn't require modification - but it's a good idea to keep track of the changes you make to your sendmail configuration, and this is the place to do it. Each time you modify the configuration, change the version number by adding your own revision number. At the same time, enter a comment in the file describing the changes you made. Usually, this is the last change made to the files so the comments reflect all changes. For example, the original version number section in the linux.smtp.cf file is:

######################
#   Version Number   #
######################

DZ8.7.3

After we have finished all of our modifications, it will contain:

######################
#   Version Number   #
######################
#  R1.0 - modified for peanut by Craig
#       - cleaned up the comments in the local info section
#  R1.1 - modified macro M to use nuts.com instead of the
#         hostname in outgoing mail
#  R2.0 - added rule a to S11 & S31 to rewrite to first.last format

DZ8.7.3R2.0

Finally, we need to understand the purpose of a few other classes and macros found in this section. The M macro is used to rewrite the sender host address. Define a value for M to hide the name of the local host in outbound mail. Classes E and M are both related to macro M. Class E defines the usernames for which the hostname is not rewritten even if the M macro is defined. For example, [email protected] is not rewritten to [email protected] even if M is defined as DMnuts.com. Class M is defines other hostnames, not just the local hostname, that should be rewritten to the value of macro M. This is used on mail servers that might need to rewrite sender addresses for their clients. For example:

# who I masquerade as (null for no masquerading) (see also $=M)
DMnuts.com

# class M: domains that should be converted to $M
CMacorn.nuts.com brazil.nuts.com filbert.nuts.com

Given the macro M and class M definitions shown above. This host would rewrite mail from [email protected] or [email protected] to [email protected]. peanut is not a server so we won't use class M. But we will use macro M later in the configuration.

We spent lots of time looking at the local information section because almost everything you will need to do to configure a system can be done here. We will quickly discuss the other section before getting into the really challenging task of working with rewrite rules.

10.7.2 Modifying Options

The section, "Options," defines the sendmail environment. For example, some of the options specify the file paths used by sendmail, as in these lines from the linux.smtp.cf file:

# location of alias file
O AliasFile=/etc/aliases
# location of help file
O HelpFile=/usr/lib/sendmail.hf
# status file
O StatusFile=/etc/sendmail.st
# queue directory
O QueueDirectory=/var/spool/mqueue

If these paths are correct for your system, don't modify them. On peanut we want to keep the files just where they are, which is generally the case when you use a sendmail.cf file that was designed for your operating system. In fact, you will probably not need to change any of the options if you use a configuration file designed for your operating system. If you're really curious about sendmail options, see Appendix E.

The next few sections of the linux.smtp.cf file define the messages' precedences, the trusted users, and the headers. None of these sections are modified. Following these sections are the rewrite rules and the mailers. This material is the bulk of the file and the heart of the configuration. The sample configuration file is designed to allow SMTP mail delivery on a Linux system running DNS, so we assume no modifications are required. We want to test the configuration before copying it into sendmail.cf. We'll save it in a temporary configuration file, test.cf, and use the troubleshooting features of sendmail to test it.