Last month's Guru Guidance presented an overview of electronic mail on Linux and Unix systems. This month, we will continue our exploration of this topic by looking at sendmail, the most widely used mail transport agent in the world (most current estimates put sendmail usage at over 75 percent).
Last month’s Guru Guidance presented an overview of electronic mail on Linux and Unix systems. This month, we will continue our exploration of this topic by looking at sendmail, the most widely used mail transport agent in the world (most current estimates put sendmail usage at over 75 percent).
sendmail is a very powerful facility. It is capable of performing most tasks related to e-mail, including handling the mail from the moment a user submits from a mailer program (“user agent”), transporting it across a LAN or the Internet to the proper destination system, and finally handing it off to a program that will actually place the message in the user’s mailbox (the “delivery agent”). In fact, since the sendmail package includes a delivery agent program, the facility can actually handle every aspect of e-mail except, of course, composing and reading messages and retrieving them from message stores.
The current version of sendmail (as of March 2001) is 8.11.3. However, this may or may not be the version of sendmail that is running on your systems. Vendor-included versions of sendmail tend to lag somewhat behind the current version.
The major version number (8) refers to the major rewrite of sendmail done in 1993 by its author, Eric Allman. The other numbers are revisions within that series. sendmail may be obtained via its homepage, http://www.sendmail.org (note the suffix; sendmail.com corresponds to the commercial version of sendmail).
On a Linux system, you can identify which version of sendmail is installed with the following command (shown with the output from a recent Red Hat distribution):
$ rpm -qa | grep sendmail
This system is running version 8.11.0, which is a couple of minor revisions back from the current version. You can verify that this is the version actually running with the command shown in Figure One.
Figure One: sendmail’s Address-Testing Mode
$ echo | /usr/sbin/sendmail -bt -d0
Compiled with: LDAPMAP MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETUNIX NEWDB NIS QUEUE SASL SCANF
============ SYSTEM IDENTITY (after readcf) =================
(short domain name) $w = sheila
(canonical domain name) $j = sheila.aeleen.com
(subdomain name) $m = aeleen.com
(node name) $k = sheila.aeleen.com
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
This sendmail command runs the facility in its interactive address-testing mode with some additional debugging output enabled; in this case, the input is taken from standard input, which is null, thereby terminating the session after the initial messages are displayed (/dev/null could also be used as the input source).
The output of this command indicates the sendmail version information as well as the set of compilation options with which it was built. For example, this version includes support for interfacing with an LDAP database (which is indicated by the first keyword in the list). The second section of the output displays information about the local system and its domain environment. The final lines pertain to address translation and can accordingly be ignored.
If you want to find out the specific sendmail version that is running on a remote system, telnet to port 25 (the port that is specified as telnet’s second parameter):
$ telnet sheila 25
Connected to sheila.
Escape character is ‘^]’.
220 sheila ESMTP Sendmail 8.11.0/8.11.0; Sun, 4 Mar 2001 14:46:28 -0500
sendmail upgrades appear very frequently (barring any major bugs and security holes, every two to three months). Ideally, hosts that relay mail into and out of your site should be kept up-to-date with the latest version of sendmail; these are your most vulnerable security points. Other hosts, which usually just rely on a central mail server for mail transport, can probably make do with the version that came with the operating system (unless a major security problem is discovered). In any case, regularly check security sites and mailing lists (as well as the sendmail homepage) for notices of newly-discovered vulnerabilities and appropriate fixes.
The Pieces of sendmail
The sendmail facility consists of many components: the sendmail daemon, configuration building tools, associated commands, and several configuration files. They are combined as a single package under SuSE Linux and as three separate packages under Red Hat Linux (as displayed in our previous example). Note that you must install the sendmail-cf package if you want to modify your sendmail configuration on Red Hat systems. This package is not installed by default.
The sendmail files will be located in standard locations only if you install sendmail yourself from source code. Table One lists sendmail’s major components and their directory locations under Red Hat 7.0 and SuSE 7.0.
Table One: Major Components of the sendmail Package
|Item||Red Hat 7.0||SuSE 7.0|
| sendmail binary|| /usr/sbin|| /usr/sbin|
| daemon startup script|| /sbin/init.d/sendmail|| /sbin/init.d/sendmail|
| daemon startup configuration|| /etc/sysconfig/sendmail|| /etc/rc.config.d/sendmail.rc.config|
| smrsh, mail.local|| /usr/sbin (smrsh only)|| /usr/lib/sendmail.d/bin|
| mailq, newaliases, vacation|| /usr/bin (no vacation)|| /usr/bin|
| sendmail.cf (primary configuration file)|| /etc|| /etc|
| sendmail.cf build directory|| /usr/lib/sendmail-cf/cf|| /usr/share/sendmail/cf|
| aliases file|| /etc|| /etc|
| other configuration files|| /etc/mail|| /etc/mail|
| local user mailboxes|| /var/spool/mail|| /var/spool/mail|
| sendmail work queue|| /var/spool/mqueue|| /var/spool/mqueue|
| mail-related syslog messages|| /var/log/maillog|| /var/log/mail|
sendmail’s functioning is controlled by the sendmail daemon; all of the other components work under its direction. The daemon is generally started at boot time with a command like the following:
which runs the daemon in the background, processing the mail queue every 30 minutes. If necessary, you can start or restart sendmail with a command like this one:
# /sbin/init.d/sendmail restart
Previously, configuring sendmail was something of a black art; it took a long time to learn how, and even then the process remained at least somewhat mysterious to all but a few gurus. Since the facility began using the m4 macro preprocessor facility to create sendmail.cf configuration files, however, the job has become much, much easier.
When you create a sendmail configuration file, you tell sendmail about the specifics of mail submission and delivery on the local computer system. sendmail is highly configurable, allowing you to specify desired behavior in detail and to modify almost any of its default settings. Fortunately, these default settings are well chosen, and configuring sendmail is a pretty simple task for the most commonly used mail scenarios.
sendmail’s main configuration file, /etc/sendmail.cf, is created by running a much simpler source file through the m4 macro processor. In order to build a custom configuration, you must create this second file, process it, install the resulting file as /etc/sendmail.cf, and notify the daemon.
The configuration file build directory varies for each Linux distribution (see Table One for details). The main directory contains a variety of sample configuration source files (their extension is .mc ); you can often begin a new configuration by copying and then modifying one of them. In their simplest form, these files contain three main types of entries:
* Macro Invocations: Predefined macros that expand to the items which are necessary to enable a particular sendmail feature. Macro names are conventionally in uppercase letters, and their arguments are specified as a parenthesized, comma-separated list.
* Additional Macro Definitions: These are performed via the m4 define command, which have the general form: define(‘NAME’,value) . These items are used to enable features and to set values of various sendmail parameters and settings.
* Comments: Source files usually begin with a block of comments, delimited by divert(-1) and divert(0) commands (these tell the preprocessor to ignore all lines in between them). Additional comments may appear elsewhere in the file following the string ” dnl .”
Listing One illustrates the use of these various items within a sendmail source file. This file is used on the client systems of a site which uses a designated mail hub system for all non-local outgoing mail; in other words, mail submitted on a client system destined for that same system is delivered locally, but all other mail — whether it is going to another machine within the site or some other site altogether — gets forwarded to the mail hub.
Listing One: Configuration Source File for a Client System
If you modify this file, you will have
to regenerate /etc/sendmail.cf:
m4 <file>.mc > /etc/sendmail.cf
VERSIONID(‘Config file for Red Hat Linux’)
As usual, the source file begins with comments. The first item following the comment block includes the contents of a standard source file within this file. The first macro in the file, VERSIONID , specifies a version string identifying this particular version of the source file; often, the value of this macro is a source control system ID string, although in our case it is simply a few words of description. Note that character strings specified as arguments are enclosed with an initial backquote and a closing single quote: ‘ string’ .
The next macro, OSTYPE , specifies the operating system type of the target system; in this case, Linux is selected. This macro causes another, OS-specific source file to be included within this source file. The various defined OStypes, and all of their associated source files, are located in the ../ostype subdirectory (which is relative to the build directory).
The next two macros select two sendmail features; nocanonify tells sendmail not to expand addresses to their fully qualified form (this will be done on the mail hub, and delaying it until then saves some redundant DNS lookups), and local_procmail says to make procmail the default local delivery agent. (In fact, the latter is already the default on Linux systems, via the ../ostype/linux.m4 file.)
The next two lines use the define macro to indicate the system that is the mail hub (bella) and to specify an alternate location for the sendmail status/statistics file. The final two lines of the file use the MAILER macro to specify that SMTP and local mailers (delivery agents) are in use on this system. Since the local_procmail feature has been invoked, the final line is equivalent to specifying the procmail mailer: MAILER(‘procmail’) .
The order of items within this file is important. The general structure of a source file is outlined below:
DOMAIN (not usually needed–used to indicate the local domain)
MAILERs (SMTP should be first)
local rulesets (advanced featurenot usually needed)
Thus, FEATUREs generally precede defines. However, if a setting related to a feature is specified in a define macro, then that define should precede the corresponding feature.
The comments in the preceding source file indicate one way to build a sendmail.cf file from the source file, and this is the way Red Hat systems are set up to work. However, the more typical way to perform this operation is to use the Build script in the same subdirectory as shown below (this method also works on Red Hat systems). I tend to be a bit more cautious installing the new file:
# emacs test.mc
# ./Build test.cf
# cp /etc/sendmail.cf/etc/sendmail.cf.save
# cp test.cf /etc/sendmail.cf
Whenever you change your sendmail configuration, you must either restart the daemon or (better) send it a HUP signal:
# kill -HUP ‘head -1 /var/run/sendmail.pid’
The sendmail.pid file stores the process ID of the sendmail daemon (on its first line), along with the command used to initiate it (line 2).
Listing Two illustrates the source file that might be used to build the sendmail.cf file for the mail hub system (we have removed the initial block of comments and the VERSIONID macro in this example).
Listing Two: Configuration Source File for the Mail Hub
dnl Send out all mail as firstname.lastname@example.org
This source file is again for a Linux system. The first FEATURE , relay_ entire_domain , causes the mail hub to accept mail for forwarding from any host in the local domain. The second FEATURE specifies that an external configuration file be used to specify a list of hosts and domains for which this system will accept and deliver mail. The default file for this purpose is /etc/mail/local-host-names; it is an ordinary text file containing one name per line. Be sure to include the local domain within the file (here, somecomp. com ) and the desired hosts.
The three lines following the comment enable masquerading on this host. The MASQUERADE_AS macro will cause all mail that is leaving the site to appear to be coming from a single location; here that item is specified as the domain somecomp.com . The masquerade_envelope FEATURE causes masquerading (address rewriting) to occur within the message’s envelope (which are the actual delivery addresses built from the message’s mail headers by the mailer) as well as the standard mail headers, and allmasquerade says to masquerade recipient names as well as sender names (the latter is useful when the recipient list includes both local and nonlocal people).
The final two lines of the file select various delivery agents: SMTP and procmail (the default local mailer under Linux).
These simple examples illustrate many of sendmail’s basic features and capabilities. There are many more available, but space constraints do not permit us to explore them in this column. Consult the README file in the sendmail configuration subdirectory for a full list.
|Figure Two: linuxconf and YaST GUIs for configuring sendmail.|
I think that sendmail is quite easy to configure by manually creating a .mc file, but if you prefer a GUI interface, they are available. Figure Two illustrates the facilities offered by linuxconf (Red Hat) and YaST (SuSE).
The linuxconf windows are on the left-hand side of the figure. The upper window indicates the menu path required to enable sendmail configuration within this tool (it is disabled by default). Once enabled, you can configure sendmail via the menu path shown in the bottom window. Various sendmail features and settings can now be selected and specified via its four panels.
The windows on the right-hand side of Figure Two show the corresponding facilities under YaST. The upper window allows you to select from a list of several general configuration types. If you select the penultimate item, Expert mode for sendmail configuration, then the lower dialog will appear.
Hopefully this discussion will enable you to get started exploring and configuring sendmail. Next month, we will take a look at the final piece of the e-mail puzzle, delivery agents. We will be focusing on procmail and its ability to filter incoming mail for both security (e.g., viruses) and content (i.e., spam).
Æleen Frisch is the author of Essential System Administration. She can be reached at email@example.com.