2.1 Vendor Versus Compiling

Should you compile sendmail from the source or obtain it from a vendor? Vendors tend to ship old versions of sendmail with their operating systems. Current versions of operating systems frequently ship V8.11 sendmail. Very old versions of sendmail should be replaced because they are insecure. Newer versions should also be replaced because the latest version (V8.12) contains many new and valuable features.

To find out which version you are running, issue the following command:[1]

[1] Your installed path might differ. Under Solaris Unix, for example, sendmail is located in /usr/lib.

% /usr/sbin/sendmail -d0.1 -bt < /dev/null

The first line (of possibly many) printed should contain the version number. If no version is displayed, you might be running a very old version of sendmail indeed, or some other program masquerading as sendmail. In either instance, you should upgrade.

If V8.9.2 or earlier is displayed, you should plan to upgrade. V8.9.3 was the last secure version of the V8.9 series.

If V8.11.5 or earlier is displayed, you should plan to upgrade. V8.11.6 was the last secure version of the V8.11 series.

A more difficult decision is whether to upgrade to V8.12 if you are already running V8.9.3 or V8.11.6 sendmail. Potential reasons for upgrading are as follows:


The sendmail program has always been a prime target of attack by crackers (probably because it is distributed as fully commented source code). Although sendmail has been secure since V8.11.6, one of your C-language libraries might not be. If you have been notified of a security hole in your library, you should consider recompiling sendmail, using a new, secure library. You can do this only with the open source. Recompiling is not an option with vendor-supplied binaries.


If your site is beset by spam mailings (as most sites are these days), you should at least be running V8.9.3 sendmail with the access_db FEATURE support included and utilized (Section 7.5). The V8.9 release of sendmail was the first that specifically targeted the suppression of spam. If your site suffers from spam mailings, consider upgrading to V8.12 soon.

Bug fixes

After widespread use and abuse, any program will begin to show its bugs. The sendmail program, although superbly written, is no exception. One reason new versions are periodically released is to fix reported bugs. At the very least, down-load the latest source and look at the release notes to see whether a bug might be biting you.


At a heterogeneous site (as most sites are these days) it is often more convenient to run a common version of sendmail and clone configuration files. Only by compiling and installing from the source can you achieve a controllable level of uniformity.


A precompiled version of sendmail can lack certain features that you find desirable, or it can have features that you would prefer to exclude. Table 3-2 (in Section 3.2) lists the debugging switches you can use to determine what kind of features your sendmail has available. If debugging switches are unavailable, the individual sections at the end of Chapter 3 show methods to determine feature support or the lack of it.

But beware. Before rushing out and replacing your vendor's version of sendmail, find out whether it uses any special vendor-specific features. If so, and if those features are more valuable to you than the antispam features and uniformity that we mentioned, convince your vendor to upgrade for you.

    Part I: Build and Install
    Chapter 2. Build and Install sendmail
    Chapter 4. Configure sendmail.cf with m4
    Part II: Administration
    Part III: The Configuration File