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:
% /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:
- Security
-
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.
- Spam
-
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.
- Uniformity
-
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.
- Tuning
-
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.
|
