In this section we put into practice everything we discussed about sendmail configuration filestheir structure and the commands used to build them. We'll modify the configuration file, generic-linux.cf, for use on rodent.wrotethebook.com. We'll modify this particular file because its configuration is closest to the configuration we need for rodent.wrotethebook.com. rodent is a Linux workstation on a TCP/IP Ethernet, and it uses SMTP mail and DNS.
The following sections are titled according to the sections of the file, and they describe the modifications we'll make to the file, section by section. Remember that other sendmail.cf files will probably use different section titles, but the basic information provided in the configuration will be the same.
The first line in the local information section of the configuration file defines class w. Class w is the full set of hostnames for which this system accepts mail. Use the C command or the F 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 many systems that is enough. However, sometimes a sendmail server acts as a mailbox server that must accept and store mail for clients that do not directly receive SMTP mail. The w class needs to identify systems that expect this host to accept mail for them. You'll need to add a hostname to class w for every mailbox client.
 The C and F commands from generic-linux.cf are shown earlier in this chapter.
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 rodent. On the system crab, which is also known by the name wtb-gw, we would add values to class w as follows:
Cwlocalhost wtb-gw wtb-gw.wrotethebook.com
Now mail addressed to email@example.com would be accepted by crab 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 the hostnames. You can do that with the F command. The generic-linux.cf file already has an F command, so we could just place the client hostnames in the file /etc/mail/local-host-names.
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 most 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 wrotethebook.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 rodent.wrotethebook.com for j. If it displayed only rodent, we would edit sendmail.cf to correct the value for j.
# sendmail -bt -d0.4 Version 8.11.3 Compiled with: LOG MATCHGECOS MIME8TO7 NAMED_BIND NDBM NETINET NETUNIX NEWDB SCANF USERDB XDEBUG canonical name: rodent.wrotethebook.com UUCP nodename: rodent a.k.a.: rodent.wrotethebook.com a.k.a.: [172.16.12.2] ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = rodent (canonical domain name) $j = rodent.wrotethebook.com (subdomain name) $m = wrotethebook.com (node name) $k = rodent ======================================================== 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 two pseudo-domains. These pseudo-domain names are "." and REDIRECT. The pseudo-domain dot (.) is used to identify canonical domain names. The REDIRECT pseudo-domain is used by the redirect feature described in Appendix E. Other pseudo-domains can be added to class P to address users who are not on the Internet with Internet-style email addresses. For example, we could add UUCP to class P so that mail can be addressed using the old UUCP "bang" syntax, e.g., ora!los!craig, or it can be addressed in a pseudo-Internet format, e.g., firstname.lastname@example.org. These mail routing domains simplify the address that the user enters and route the mail to the correct mail relay host. However, additional pseudo-domains are rarely needed because most mailers now support standard Internet-style addresses. The class P definition in generic-linux.cf does not require any modification.
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 system 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:
We don't enter anything in any of the relay settings on rodent. 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 five key file definitions. Two of these K commands define pseudo-databases, which are internal sendmail routines used in rewrite rules as if they were true databases. The arith database is an internal routine used to perform certain arithmetic functions. The dequote database is an internal sendmail routine used to remove quotes from within email addresses. The other three K commands define real databases: mailertable, virtuser, and access. These are real databases, but the database files exist only if you create them. The mailertable database is used to send mail addressed to a specific domain through a particular mailer to a specific remote host. The virtuser database routes mail for virtual mail domains, which are mail domains that have no real existence beyond the sendmail server itself. The access database provides access controls for mail relaying and for spam control.
The version number doesn't require modificationbut it's a good idea to keep track of the changes you make to your sendmail.cf file, 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 generic-linux.cf file is:
###################### # Version Number # ###################### DZ8.11.3
After we have finished all of our modifications, it will contain:
###################### # Version Number # ###################### # R1.0 - modified for rodent by Craig # - cleaned up the comments in the local info section # R1.1 - modified macro M to use wrotethebook.com instead of the # hostname in outgoing mail # R2.0 - added rule a to SEnvFromSMTP & S HdrFromSMTP to rewrite the user in outgoing mail to firstname.lastname format DZ8.11.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@example.com is not rewritten to firstname.lastname@example.org even if M is defined as DMwrotethebook.com. Class M 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) DMwrotethebook.com # class M: domains that should be converted to $M CM24seven.wrotethebook.com brazil. wrotethebook.com ora.wrotethebook.com
Given the macro M and class M definitions shown above, this host would rewrite mail from email@example.com or firstname.lastname@example.org to email@example.com. rodent is not a server so we won't use class M. But we will use macro M later in the configuration.
We've 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.
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 generic-linux.cf file:
# location of alias file O AliasFile=/etc/mail/aliases # location of help file O HelpFile=/etc/mail/helpfile # status file O StatusFile=/etc/mail/statistics # queue directory O QueueDirectory=/var/spool/mqueue
If these paths are correct for your system, don't modify them. On rodent 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 generic-linux.cf file define the messages' precedences, the trusted users, and the headers. None of these sections is 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.