UNIX System Administration Handbook - Evi Nemeth [342]
The use_cw_file feature
The sendmail internal class w (hence the name cw) contains the names of all local hosts for which this host accepts and delivers mail. A client machine might include its hostname, its nicknames, and localhost in this class. If the host being configured is your mail hub, then the w class should also include any local hosts and virtual domains for which you accept email.
The use_cw_file feature defines class w from the file /etc/mail/local-host-names (which used to be called sendmail.cw; the exact filename is configurable with the confCW_FILE option, discussed later). Without this feature, sendmail accepts only mail addressed to the machine on which it is running. Since sendmail reads the .cw file only when it starts, you must send a HUP signal to sendmail if you change the .cw file to make the change take effect.
FEATURE('use_cw_file')
invokes the feature and uses local-host-names;
FEATURE('use_cw_file', 'other-filename')
lets you choose the filename.
The redirect feature
When people leave your organization, you usually either forward their mail or let mail to them bounce back to the sender with an error. The redirect feature provides support for a more elegant way of bouncing mail. If Joe Smith has graduated from oldsite.edu to newsite.com, then enabling redirect with
FEATURE('redirect')
and adding the line
smithj: joe@newsite.com.REDIRECT
to the aliases file causes mail to smithj to be returned to the sender with an error message which suggests that the sender try the address joe@newsite.com instead. The message itself is not automatically forwarded.
The always_add_domain feature
This feature makes sendmail add the local hostname to destination addresses that are not fully qualified. For example, suppose a message from lynda@cs.colorado.edu to barb@netrack.net also copies the local user evi. Without always_add_domain, the mail that barb receives will show “evi” on the Cc header line. If she responds to all recipients, her response will go to “evi”, which might not be a valid account at netrack.com or might be a different person. With always_add_domain turned on, evi’s address is mapped to evi@cs.colorado.edu before it leaves lynda’s machine.
It is also appropriate to use always_add_domain when you share spool directories among machines that do not share an alias file or that do not have the same passwd file (incidentally, you probably shouldn’t do such sharing). Mail to an alias or user that is not known everywhere would be fully qualified on the originating machine and therefore replyable.
Another selling point for this feature is that unqualified names are often rejected as spam. We recommend that you always use it.
If you are using MASQUERADE_AS (see page 583), always_add_domain adds the name of the host you are masquerading as, not the local hostname. This convention can cause problems if the aliases file or passwd file on the local host is not a subset of the equivalent file on the MASQUERADE_AS host.
The nocanonify feature
This feature postpones the DNS lookups that are necessary to send a message. For example, at a site with a master mail hub and client machines that forward all their mail through the master, the clients might use
FEATURE('nocanonify')
to avoid doing the DNS lookups locally. Our second example (page 591) uses this scheme. It can also be used in the MSA/MTA scheme that might be used at a very large mail site. In this scenario, the MSA does all the DNS lookups and the master machine running the MTA specifies nocanonify.
Tables and databases
sendmail has several FEATUREs that use a construct called a “table” to figure out where mail should be routed. A table is a text file of routing, aliasing, access, or other information that is converted to a database format externally with the makemap command and then used as an internal database for sendmail’s various lookups. The use of a centralized IMAP or POP server relieves sendmail of the chore of chasing down users and obsoletes some of