We now turn our attention from security problems to security features:
T configuration command (class
defines which users are allowed to use the
command-line switch to override the sender address with one of their own.
The smrsh program replaces /bin/sh as the program run by the
prog delivery agent to execute programs.
Several options can be used to tighten security and to provide reports of security violations.
The /etc/shells file prevents ordinary users from running programs on your mail server.
Under pre-V8 sendmail,
trusted users are those who are allowed to use the
command-line switch (see Section 36.7.21, -f and -r) to override the
sender address with one of their own.
V8.1 sendmail eliminated this configuration command.
V8.7 restored it, but as a class, and uses that class only to suppress warning headers.
Trusted users are necessary for certain kinds of mail to flow properly.
By way of example, the rmail(8) program of the UUCP suite of
programs runs suid to uucp. If rmail were not to use the
command-line switch, all mail from UUCP would
wrongly appear to come from the uucp user.
To circumvent this problem, rmail runs sendmail as
/usr/lib/sendmail -f reallyfrom
This tells sendmail to show, in both the header and envelope, the message as being from reallyfrom, rather than from uucp.
The concept of a trusted user is intended to prevent ordinary users from changing the sender address and thereby forging mail. Although that intention is laudable and good for UUCP, it can cause problems with mailing lists. Consider the following:
list: "|/usr/lib/sendmail -oi -flist-request -odi list-real" list-real: :include:/export/share/mail-lists/list.list
The intention here is for all mail sent to the mailing list named
to be dispatched as though it were sent from
This causes errors to be returned to the maintainer of the list
list-request), but replies still go to the real sender.
Unfortunately, this scheme fails when mail is posted to
from the local machine. Recall that only trusted users can change
the identity of the sender with
-f. This is why
V8.1 sendmail eliminated the concept of the trusted user
(anyone could use the
Beginning with V8.7, sendmail restored the concept but uses the
T command only to suppress warning headers.
Trusted users are defined by those lines in the sendmail.cf
file that begin with the uppercase letter
Only trusted users may use the
switch to specify who sent the message.
Beginning with V8.7 sendmail, the class
may also be used.
T sendmail.cf command must begin a line. One or more
space-delimited usernames then follow on that same line. There
may be multiple
T commands in a sendmail.cf file, each
adding names to the list of trusted users. Prior to V8 there could be at most
MAXTRUST trusted users, where
MAXTRUST was defined
in conf.h when you compiled sendmail. Beginning with V8.7, there
is no limit:
T uucp legal in V8.1 through V8.6 but ignored Troot daemon legal in V8.1 through V8.6 but ignored Ct uucp V8.7 and above Ctroot daemon V8.7 and above
T commands show that there may optionally be whitespace
T and the first name in any list of names.
They indicate that uucp, root, and daemon are
trusted and have been added to the list of trusted users in
that order. The two class declarations show a similar declaration
for use beginning with V8.7 sendmail (but note that V8.7 and above
can still use the old syntax).
Prior to V8 sendmail, if you listed more than
MAXTRUST trusted users,
sendmail printed and syslog(3)'ed a message like this:
sendmail: too many T lines, 32 max
This message was not fatal. The sendmail program issued
it for each excess
T line (ignored those trusted users)
and continued to run.
Prior to V8 sendmail, if a user who was not trusted attempted to use the
switch, that attempt was silently ignored (silently disallowed).
Beginning with V8.7 sendmail, if a user who is not trusted attempts to use
-f switch, that attempt may produce an
header (see Section 35.10.35, X-Authentication-Warning:)
p) option (see Section 34.8.47) has
One line of attack against all users, including root, is to modify a user's ~/.forward file (see Section 22.5.3, "Permissions for ~/.forward Files"). Unless you take steps to prevent it, sendmail will run any program that it finds in a user's ~/.forward file:
\user |"/usr/ucb/vacation user" ok |"/tmp/x.sh" An attack! |"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x" An attack!
As an aid in preventing such attacks, V8 sendmail offers
the smrsh (sendmail restricted shell) program,
and V8.7 sendmail offers the
smrsh FEATURE (see Section 19.6.22, FEATURE(smrsh))
as an easy way to install smrsh with the m4 configuration technique.
The smrsh program is supplied in source form with the sendmail distribution in the smrsh directory. The README file in that directory describes how to compile and install smrsh.
The smrsh program replaces the /bin/sh program in the
delivery agent (see Section 30.2.1, "Required Symbolic Names") declaration:
Thereafter, whenever smrsh is called to run a program, smrsh strips the leading path from the program name and looks for that program in its special /usr/adm/sm.bin directory. If the program is not found in that directory, the message bounces. Thus in our first attack example above, with smrsh installed and with x.sh not in the /usr/adm/sm.bin directory, the ~/.forward line
would cause the email message to bounce with this error:
smrsh: /usr/adm/sm.bin/x.sh: not found
|"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"
In this instance, smrsh would reject the command line (and thus bounce the message) because it contained a semicolon character:
smrsh: cannot use ; in command
The smrsh program is simple yet immensely valuable. We recommend that it be routinely installed on all your machines.
Be very conservative when choosing programs to put in the /usr/adm/sm.bin directory. Never, for example, put programs there that allow shell escapes.
The sendmail program offers several options that can help you to improve the security at your site. Some we have discussed above. We touch on a few more in this section, and provide a recommended setting where appropriate. For a full description of each, see the sections referenced.
u) option (see
Section 34.8.15) can be used to ensure that the default
identity (when it is not running as root) is a safe one. CERT
recommends that you create a pseudo-user whose uid and gid
are used nowhere on your system, then define the
u) option to be that pseudo-user. As an additional
precaution, make sure that pseudo-user lacks a valid shell and has no
valid home directory:
nullmail:*:32765:32765:Sendmail Default User:/no/such/directory:/bin/false
At the same time, set up a group entry for this user's group:
This is necessary if you want to refer to this group symbolically at some later time.
Avoid using the name nobody, because root is mapped to nobody over NFS. If root were to create a file over NFS that it thought was safe because root owned it and because it was readable only by root, that root user would be surprised to find that file owned by nobody. Consequently, we recommend that in an NFS environment you set the default user to one less than nobody. For example, if nobody has the uid 65534, you could set up
nullmail:*:65533:65533:Sendmail Default User:/no/such/directory:/bin/false
J) option (see Section 34.8.27, ForwardPath (J)) lists a series
of directories that sendmail will search for user ~/.forward files.
At most sites there are users who are savvy and able to correctly administer
their own ~/.forward files, but there are others who are
untrained or careless. One way to allow experienced users use of the
~/.forward facility while denying it to the others is with the
Here, sendmail will first search the /usr/local/etc/forwards directory
to find a file that begins with the user's login name (the
$u see Section 31.10.36, $u)
followed by a .forward. If you set up such a file for the untrained user, say bob:
-rw-r-r- 1 root system 0 Dec 13 1996 /usr/local/etc/forwards/bob.forward
and if that file is empty, bob's mail will always be delivered locally, no matter what bob puts in his ~/.forward file. For experienced users you can omit their files from the /usr/local/etc/forwards directory, thus enabling their use of their /.forward files.
The sendmail program normally logs
a great deal of useful information
via syslog (see Section 26.1.1, "syslog(3)").
There will be times, however, when
the normal amount of information is insufficient. Consider, for example,
that some outsider is using your site to forge mail. Since this
is done over an SMTP connection, it would be handy to have
both sides of all SMTP conversations logged.
You can do this with the
L) option (see Section 34.8.33):
O LogLevel=12 V8.8 and above to log SMTP
Beginning with V8.8 sendmail, a level of 12 causes both sides of every SMTP conversation to be logged. That logging looks very similar to the logging produced by verbose mode (see Section 4.2, "Verbose (-v)").
Note that after changing the log level in your configuration file you will need to restart the daemon. With V8.7 and above sendmail you restart the daemon like this:
kill -HUP `head -1 /etc/sendmail.pid`
Be aware that a log level of 12 produces a huge amount of output. Be prepared to prune your log files more often than usual.
P) option (see Section 34.8.46, PostmasterCopy (P))
causes a copy of every bounced message to be delivered to a named user.
Usually, that user is the person who handle email problems. But since
clumsy intrusion attempts can result in bounced mail, there will be
times when bounced mail should also be delivered to the
security administrator. Consider the following:
--- Transcript of session follows --- ... while talking to your.site.domain.: >>> RCPT To:<email@example.com> <<< 550 cannot open /tmp/.../getshell: No such file or directory 550 cannot open /tmp/.../getshell: No such file or directory
This bounced mail message indicates that someone tried to become root by breaking through your aliases database.
Users are added to the list of those who get copies of bounced
messages with the
securitymaster (probably an alias to a real user)
p) option (see Section 34.8.47)
is used to limit the amount of information offered to the outside
world and to limit other kinds of access. The most restrictive setting
p) is probably best:
As a general rule it is best to begin with tight security. This minimizes your risk at the start and allows you to cautiously ease restrictions at a comfortable rate. Beginning with loose restrictions may force you to tighten restrictions in a panic when it is least convenient to do so.
Beginning with V8.7 sendmail,
SafeFileEnvironment option (see Section 34.8.58, SafeFileEnvironment)
determines how delivery will be made to files.
Ordinarily, sendmail will deliver to anything, provided that it
has permission to do so (see Section 24.2.2, "Delivery to Files"). It can, for
example, deliver by appending to ordinary files or by writing to a device
such as /dev/log.
SafeFileEnvironment option is declared, sendmail will only
deliver to ordinary files. This improves security by preventing anyone from
scribbling over sensitive things, such as directories and
devices. (Beginning with V8.8 sendmail, it is still okay to write to
/dev/null even though this option is set.)
SafeFileEnvironment option can also be used to define a directory
under which all files that will be appended to must exist. This may inconvenience
some users but will generally improve the security of your site. We recommend:
This takes care of both security enhancements. Of course, you will need to create
the directory specified in
/path and modify all path references in
your aliases file before actually enabling this.
If all you want to do is prevent writing to directories and devices, and if you
do not want to place all files in a special path, you can accomplish this
/path as the root directory:
F) option (see Section 34.8.68)
specifies the mode (file permissions) to give temporary files and queue files.
In general, all files that are created by sendmail should be considered
proprietary for safety's sake. We recommend a setting of:
To prevent certain users from running programs or writing to files by way of the aliases or ~/.forward files, V8 sendmail introduced the concept of a "valid shell." Just before allowing delivery via an alias such as these:
the user's password entry is looked up. If the shell entry from that password entry is a valid one, delivery is allowed. A shell is valid if it is listed in the /etc/shells file. If that file does not exist, sendmail looks up the shell in its internal list that looks (more or less) like this: 
 This is an amalgamation of many vendor lists. See conf.c in the source distribution for details.
/bin/bsh /bin/csh /bin/ksh /bin/pam /bin/posix/sh /bin/rksh /bin/rsh /bin/sh /bin/tsh /usr/bin/bsh /usr/bin/csh /usr/bin/keysh /usr/bin/ksh /usr/bin/pam /usr/bin/posix/sh /usr/bin/rksh /usr/bin/rsh /usr/bin/sh /usr/bin/tsh
With this technique it is possible to prevent certain users from having sendmail running programs or delivering to files on their behalf. To illustrate, consider the need to prevent the ftp pseudo-user from misusing sendmail:
ftp:*:1092:255:File Transfer Protocol Program:/u/ftp:/no/shell
Here, any attempt by ftp to send mail through a program or into a file will fail because the shell /no/shell is not a valid shell. Such mail will bounce with one of these two errors:
User firstname.lastname@example.org doesn't have a valid shell for mailing to programs User email@example.com doesn't have a valid shell for mailing to files
Note that unusual circumstances may require you to allow users with invalid shells to run program or deliver to files. To enable this for all such users (as on a mail server with restricted logins), place the following line directly in the /etc/shells file:
To enable this for selected users, just replace their shell with a bogus one that is listed in /etc/shells:
ftp:*:1092:255:File Transfer Protocol Program:/u/ftp:
We recommend that all pseudo-users (such as bin and ftp) be given invalid shells in the password file and that /SENDMAIL/ANY/SHELL/ never be used.