Table of Contents for

sendmail, 4th Edition

Clearly, many of sendmail’s duties require it to run as root. As a corollary, however, whenever sendmail does not need to be root, it should become the appropriate non-privileged user. It does this by using the following bit of logic:

Note that setreuid(3) is preferred over seteuid(3)^[63] and setuid(3) because it allows sendmail to temporarily give away both its real and effective root privilege, then to get it back again. To illustrate the need for this behavior, consider processing a mailing list that saves mail to two different files:

/u/bill/archive        ← owned by the user bill, mode 4600
/u/alice/archive       ← owned by the user alice, mode 4600

Further consider that these files both have permissions of set-user-id to the individual users^[64] and are writable only by the individual users. To perform delivery in this instance, sendmail must^[65] first become bill (this requires root privilege). To become another user, sendmail forks. The parent remains root and the child becomes the user, bill in our example. When it is done, the child exits. The parent sendmail remains root so that it can next become alice. By retaining a real uid of root, sendmail is able to change its effective uid to one user after another as needed.

See the description of the test directory in USESETEUID on page 151 for more on this subject.

When sendmail executes (runs) a delivery agent (The Child on page 757), it passes to that delivery agent an environment that includes only the items described earlier. Some delivery agents, however, might require additional environment variables to function properly. For those special cases, sendmail offers the E configuration command to set individual environment variables that will be passed to all delivery agents:

Evar=value

The var is the environment variable that will be either defined or redefined. It is immediately followed (with no intervening space) by an equal-sign and then (again with no intervening space) by the value that will be assigned to it.

If the =value is missing, sendmail looks up the variable var in its environment and, if it is found, uses that value. If the = is present but the value is absent, the var is assigned an empty string (a single zero byte). If the var is missing, a variable name that is an empty string is used.

The var is looked up to see whether it is already a part of the delivery agent’s environment. If it is, it is redefined to be the new value. If it is not, it is added to that list of variables. If that addition will cause the list to exceed MAXUSERENVIRON variables (currently defined as 100 in conf.h, MAX... on page 120), the definition is silently ignored.

Whether or not the var was added to, or updated in, the delivery agent’s environment, it is always added or updated to sendmail’s environment with putenv(2). If this call fails, sendmail logs and prints the following message:

setuserenv: putenv(var=value) failed

Only one var can be defined per E command. Additional environment variables require multiple E commands. Each E command affects all delivery agents. There is no way to tune the environment on a per-delivery-agent basis.

An “unfixed bug” probe can use the SMTP debug and showq commands. The SMTP debug command allows the local sendmail to be placed into debugging mode (as with the -d command-line switch, The Syntax of -d on page 530) from any other machine anywhere on the network. The SMTP showq command allows outsiders to view the contents of the mail queue.

If SMTPDEBUG (SMTPDEBUG on page 144) is defined when sendmail is compiled, the SMTP debug and showq commands are allowed to work; otherwise, they are disabled. SMTPDEBUG should be defined only when modifying the sendmail code and testing a new version. It should never be defined in an official release of sendmail. To see whether it has been defined at your site, run the following command:

% telnet localhost 25
Trying 123.45.6.7 ...
Connected to localhost.
Escape character is '^]'.
220 localhost sendmail 8.12 ready at Fri, 13 Dec 2002 06:36:12 −0800
debug
500 Command unrecognized
quit
221 localhost.us.edu closing connection
Connection closed by foreign host.
%

When connected, enter the command debug. If you get the answer 500 Command unrecognized, you know that SMTPDEBUG is not enabled. If, on the other hand, you get the answer 200 Debug set, SMTPDEBUG is defined on your system, and you should immediately take steps to correct the situation. Either contact your vendor and request a new version of sendmail, or get the sendmail source and compile it with SMTPDEBUG undefined.

When SMTPDEBUG is undefined and an outsider connects to the local machine and attempts to execute the debug or showq command, sendmail will syslog(3) a message such as the following:

Jul 22 07:09:00 here.domain sendmail[192]: "debug" command from there.domain
      (123.45.67.89)

This message shows the name of the machine that attempts the probe, or there.domain, and the IP address of that machine. Note that this message is logged only if the LogLevel option (LogLevel on page 1040) is nonzero.

You might be dismayed to learn that the login names of ordinary users can be used to break into a system. It is not, for example, all that unusual for a user to select a password that is simply a copy of his login name, first name, last name, or some combination of initials. A risk of attack can arise from outsiders guessing login names. Any that they find can be used to try to break in, and the SMTP VRFY gives an attacker the means to discover login names.

Login names are also a way to gather addresses for spam email messages. The SMTP VRFY command, too, can be used to collect names for that illicit use.

The SMTP VRFY command causes sendmail to verify that it will accept an address for delivery. If a user’s login name is given, the full name and login name are printed:

vrfy george
250 George Washington <george@wash.dc.gov>

Here, the 250 SMTP reply code (see RFC821) means a successful verification.^[66] If the user is unknown, however, sendmail says so:

vrfy foo
550 5.7.1 foo... User unknown

The SMTP EXPN command is similar to the VRFY command, except that in the case of a mailing list, an aliases, or a ~/.forward file entry, it will show all the members. The SMTP EXPN command causes sendmail to expand (show all the recipients) of an address. To illustrate the risk, consider that many sites have aliases that include all or a large segment of users. Such aliases often have easily guessed names, such as all, everyone, or staff. A probe of all, for example, might produce something such as the following:

expn all
250-George Washington <george@wash.dc.gov>
250-Thomas Jefferson <tj@wash.dc.gov>
250-Ben Franklin <ben@here.us.edu>
250-Betsy Ross <msflag@ora.com>
250 John Q. Public <jqp@aol.com>

With well-designed passwords these full and login names can safely be given to the world at large. But if one user (say, jqp) has a poorly designed password (such as jqpublic), your site’s security can easily be compromised.^[67] Note that not all uses of VRFY or EXPN represent probes. Some MUAs,^[68] for example, routinely VRFY each recipient before sending a message.

SMTP VRFY and EXPN commands are individually logged in a form such as one of the following:

Sep 22 11:40:43 yourhost sendmail[pid]: other.host: vrfy all
Sep 22 11:40:43 yourhost sendmail[pid]: [222.33.44.55]: vrfy all
Sep 22 11:40:43 yourhost sendmail[pid]: other.host: expn all
Sep 22 11:40:43 yourhost sendmail[pid]: [222.33.44.55]: expn all

This shows that someone from the outside (other.host in the first and third examples) attempted to probe for usernames in the mailing list named all. In the second and last examples, the probing hostname could not be found, so the IP address is printed instead (in the square brackets). Note that this form of logging is enabled only if the LogLevel option (LogLevel on page 1040) is greater than 5.

Pre-V8 versions of sendmail do not report SMTP VRFY or EXPN attempts at all. Some versions of sendmail (such as the HP-UX version) appear to verify but really only echo the address stated.

V8 sendmail allows VRFY and EXPN services to be accepted or rejected on the basis of the setting of the PrivacyOptions option (PrivacyOptions on page 1065). For improved security, we recommend this setting for the PrivacyOptions option:

O PrivacyOptions=novrfy,noexpn

V8.10 and above sendmail allow VRFY and EXPN services to be selectively accepted or rejected on the basis of rules in the check_vrfy (check_vrfy and check_expn on page 707) and check_expn (check_vrfy and check_expn on page 707) rule sets. If, for example, you wish to allow VRFY from internal hosts, but wish to deny it for all outside hosts, you can do so by omitting a definition of the PrivacyOptions option as explained earlier, and by designing appropriate rules for the check_vrfy rule set.

The file form of the F configuration command (The F Class Command on page 857) can be used to read sensitive information. That command looks like this in the configuration file:

FX/path pat

This form is used to read class macro entries from files. It can cause problems through a misunderstanding of the scanf(3) pattern pat. The /path is the name of the file, and the optional pat is a pattern to be used by scanf(3) (scanf(3) variations on page 858).

To illustrate the risk of the pat, consider the following configuration file entry:

Fw/etc/myhostnames %[^#]

Normally, the F command reads only the first whitespace-delimited word from each line of the file. But if the optional pattern pat is specified, the F command instead reads one or more words from each line based on the nature of the pattern. The pattern is used by scanf(3) to extract words, and the specific pattern used here, [^#], causes scanf(3) to read everything up to the first comment character (the #) from each line. This pat allows multiple hostnames to be conveniently listed on each line of the file. Now assume that a new administrator, who is not very familiar with sendmail, decides to add an F command to gather a list of UUCP hosts from the /etc/uucp/Systems file. Being a novice, the new administrator copies the existing entry for use with the new file:

FU/etc/uucp/Systems %[^#]

This is the same pattern that was correctly used for /etc/myhostnames. Unfortunately, the Systems file contains more than just host entries on each line:

linda Any ACU 2400 5551212  "" \d\n in:-\r-in: Uourhost word: MublyPeg
hoby Any ACU 2400 5551213  "" \d\n in:-\r-in: Uourhost word: FuMzz3.x

A part of each line (the last item in each) contains nonencrypted passwords. Prior to V8.12, an unscrupulous user, noticing the mistaken [^#] in the configuration file, could run sendmail with a -d36.5 debugging switch and watch each password being processed. For example:

% /usr/lib/sendmail -d36.5 -bt < /dev/null
← ...some output deleted
STAB: hoby 1 entered
STAB: Any 1 entered
STAB: ACU 1 entered
STAB: 2400 1 entered
STAB: 5551213 1 entered
STAB: "" 1 type 1 val 0 0 200000 0
STAB: \d\n 1 entered
STAB: in:-\r-in: 1 entered
STAB: Uourhost 1 entered
STAB: word: 1 entered
STAB: FuMzz3.x 1 entered                         ← note
STAB: local 3 type 3 val 34d00 0 0 0
STAB: prog 3 type 3 val 34d80 0 0 0

Note the third line from the bottom, where the password for the UUCP login into the host hoby is printed. Also note that this is no longer possible with V8.12 and above if sendmail is installed as non-set-user-id as recommended.

This example illustrates two rules about handling the configuration file:

Another form of the F (File) configuration command is the program form, which looks like this:

FX|/path

Here, the | prefix to the /path tells sendmail that /path is the name of a program to run. The output produced by the program is appended to the class, here X.

To illustrate another potential security risk, consider a configuration file that is group-writable, perhaps by a few administrators who share the job of postmaster. To break into root, the attacker needs to assume the identity of only one of those users and, under that identity, edit the configuration file. Consider the following bogus entry added by an attacker to that configuration file:

FX|/tmp/.sh

Consider further a change to the DefaultUser option (DefaultUser on page 1000) that causes the default uid and gid to become those of root:

O DefaultUser=0:0

With these changes in place, the program (actually a shell script) called /tmp/.sh is run by sendmail to fill the class X with new values. All this seems harmless enough, but suppose /tmp/.sh does the unexpected:

#!/bin/sh
cp /bin/sh /tmp/.shell
chmod u+s /tmp/.shell

Here, the Bourne shell is copied to /tmp/.shell, and the set-user-id root bit is set. Now, any user at all can run sendmail and become root:

% ls -l /tmp/.shell
/tmp/.shell not found
% /usr/lib/sendmail -bt < /dev/null
% ls -l /tmp/.shell
-rwsr-xr-x  1 root       122880 Sep 24 13:20 /tmp/.shell

The program form of the F configuration command can clearly be dangerous. The sendmail configuration file must never be writable by anyone other than root. It should also live in a directory, every path component of which is owned by and writable only by root. (We’ll discuss this latter point in greater detail soon.) If the configuration file is created with the m4 technique, care must be taken to ensure that only root can write to the mc file, and that only root can use that mc file to install the configuration file.

Just as the program form of the F command can pose a security risk if the configuration file is poorly protected, so can the M delivery agent definition. Specifically, the P= equate for a delivery agent (P= on page 748) can be modified to run a bogus program that gives away root privilege. Consider the following modification to the local delivery agent:

Mlocal, P=/bin/mail, F=rlsDFMmnP, S=10, R=20, A=mail -d $u
            ↓
becomes
            ↓
Mlocal, P=/tmp/mail, U=0,F=SrlsDFMmnP,  S=10, R=20, A=mail -d $u
                ↑       ↑
note           note

Here, local mail should be delivered with the /bin/mail program, but instead it is delivered with a bogus frontend, /tmp/mail. If /tmp/mail is carefully crafted, users will never notice that the mail has been diverted. The S flag in the F= equate (F=S on page 780) causes sendmail to retain its default identity when executing the bogus /tmp/mail. The U=0 equate (U= on page 755) causes that default to become the identity of root.

Delivery agent P= equates must be protected by protecting the configuration file. As an additional precaution, never use relative pathnames in the P= equate.

The F=S and U=0 are especially dangerous. They should never appear in your configuration file unless you have deliberately placed them there and are 100% certain of their effect. For example, the local_lmtp feature (FEATURE(local_lmtp) on page 625) correctly sets them for the local delivery agent because the mail.local program is no longer set-user-id root.

When sendmail attempts to record its delivery agent statistics (The statistics File on page 365), it checks for the existence and write permissions of the file specified by the StatusFile option (StatusFile on page 1095). Prior to V8.9, sendmail did not care where that file lived or what permissions it had—only that it existed.

A security problem could arise if one is tempted to locate the statistics file in a spool or temporary area. Consider the following location, for example:

define(`STATUS_FILE',`/usr/tmp/statistics')

Here, the administrator sets the StatusFile option to locate the statistics file in the /usr/tmp directory. The intention is that the file can be easily created by anyone who wishes to gather statistics, then removed. Unfortunately, the /usr/tmp directory is usually world-writable.

Thus, prior to V8.9, any unhappy or malicious user could bring the system to its knees:

% cd /usr/tmp
% ln -s /vmunix statistics

Here, sendmail clobbers the disk copy of the kernel. Nothing bad might happen at first,^[70] but the machine will require manual intervention to boot in the future.^[71] Clearly, precautions must be taken. For example, any file that sendmail writes to (such as the StatusFile option statistics file or the aliases database files) must be writable only by root and live in a directory, every path component of which is writable only by root.

The sendmail program, of necessity, needs to trust its configuration file. To aid in the detection of risks, it checks the permissions of its configuration file when first reading that file. If the file is writable by group or world, sendmail logs the following message:^[72]

configfile: WARNING: dangerous write permissions

If sendmail is being started as a daemon or is being used to initialize the aliases database, it will print the same message to its standard error output.

The sendmail program doesn’t always run as root. When delivering mail, it often changes its identity into that of a nonprivileged user. When delivering to an :include: mailing list, for example, it can change its identity to that of the owner of the list. This, too, can pose security risks if permissions are not appropriate.^[73] Consider the following aliases file entry:

newprogs: :include:/usr/local/lists/proglist

Here, notification of new programs is mailed to the alias newprogs. The list of recipients is taken from the following file:

-rw-rw-r—  2 bin  prog   704 Sep 21 14:46 /usr/local/lists/proglist

Because this file is owned by bin, sendmail changes its identity to bin when delivering to the list of recipients. Unfortunately, the file is also writable by the group prog. Anyone in the group prog can add a recipient to that list, including one of the form:

|/tmp/x.sh

This tells sendmail to deliver a copy of the message by running the program (a shell script) /tmp/x.sh. The sendmail program (which is still running as bin) executes that program as bin. Further, suppose the program /tmp/x.sh contains the following:

#!/bin/sh
cp /bin/sh /tmp/sh
chmod u+s /tmp/sh
cat - > /dev/null
exit 0

This causes bin first to make a copy of the Bourne shell in /tmp (a copy that will be owned by bin), and then to set the set-user-id bit on that copy (the u+s):

-rwsr-xr-x  1 bin    64668 Sep 22 07:38 /tmp/sh

The script then throws away the incoming mail message and exits with a zero value to keep sendmail unsuspecting. Through this process, an ordinary user in the group prog has created a set-user-id shell that allows anyone to become the semiprivileged user bin. From the earlier discussion (Permissions on page 164), you can see the trouble that can cause!

Mailing lists (:include:) must live in a directory, all the components of which are writable only by root. The lists themselves should be writable only by the owner.

Mailing list (:include:) files can safely be owned by root. When sendmail processes a root-owned mailing list, it changes itself to run as the user and group specified by the DefaultUser option (DefaultUser on page 1000). That option defaults to daemon^[74] but should be set to the mailnull user and mailnull group. The DefaultUser option should never be set to root.

The ~/.forward file can pose a security risk to individual users. There is a higher degree of risk if the user is root or one of the semiprivileged users (such as bin). Because the ~/.forward file is like an individual mailing list (:include:) for the user, risk can be encountered if that file is writable by anyone but the user.^[75] Consider the following, for example:

drwxr-xr-x 50 george guest        3072 Sep 27 09:19 /home/george/
-rw-rw-r—  1 george guest          62 Sep 17 09:49 /home/george/.forward

Here, the user george’s ~/.forward file is writable by the group guest. Anyone in group guest can edit george’s ~/.forward file, possibly placing something such as this into it:

\george
|"cp /bin/sh /home/george/.x; chmod u+s /home/george/.x"

Now all the attacker has to do is send george mail to create a set-user-id george shell. Then, by executing /home/george/.x, the attacker becomes george.

The semiprivileged users such as bin, and root in particular, should never have ~/.forward files. Instead, they should forward their mail by means of the aliases file directly.

User ~/.forward files must be writable only by the owning user. Similarly, user home directories must live in a directory that is owned and writable only by root, and must themselves be owned and writable only by the user.

Some users, such as the pseudouser uucp, have home directories that must be world-writable for software to work properly. If that software is not needed (if a machine, for example, doesn’t run UUCP software), that home directory should be removed. If the directory must exist and must be world-writable, to ensure that the ~/.forward file is never processed you can create an alias in the aliases database for uucp that points to root. For example:

uucp:   root

Thereafter, although the ~uucp directory is world-writable (so that anyone can remove anything from it), that file will be ignored by sendmail, even if someone places a ~/.forward file in it.

Note that all critical dot files in a world-writable home directory must be protected from creation by others. Each of .rhosts, .login, .cshrc, .profile, and .logout, for example, should be made a nonempty, root-owned directory with mode 000. World-writable home directories must be owned by root instead of by the user, and they must have the +t (sticky bit) set.

When processing a user’s ~/.forward file, sendmail requires that the file be owned by the user or by root. If ownership is correct, it then examines the ~/.forward file’s permissions. If that file is world- or group-writable, sendmail ignores (and logs) attempts to run programs and to write directly to files.

Table 4-1 shows the recommended ownerships and permissions for all the files and directories in the sendmail system. The path components will vary depending on the vendor version of sendmail you are running. For example, where we show the /usr/sbin/sendmail directory, your site might use /usr/lib/sendmail, or even /usr/lib/mail/sendmail.

In Table 4-1, we show the owner as root, or as a T (which means the owner can be the user listed with the TrustedUser option; TrustedUser on page 1112), or as an R (which means the owner must be the one specified by the RunAsUser option; RunAsUser on page 1083) if that option was specified. Under the “Owner” column, we show a colon and the group when the group is important.

In DontBlameSendmail on page 1009, we describe the DontBlameSendmail option, which can be used to allow looser permissions. We mention this option here because its misuse can lead to a weakening of security.

Consider a site where you use group permissions to allow system administrators to edit :include: files, rather than allowing them to do so by becoming root. Note that these mailing lists include archive files—that is, entries that append messages to archive files.

Unless you tell sendmail otherwise, it will refuse to run programs listed in such group-writable :include: files, and also refuse to append to any files listed in such :include: files (append to archive files). Every time mail is sent to such a mailing list, sendmail will log the following warning:

/path: group writable :include: file, marked unsafe

You can prevent this warning and allow running of disallowed programs and appending to disallowed files by declaring the DontBlameSendmail option in your mc configuration file:

define(`confDONT_BLAME_SENDMAIL', `GroupWritableIncludeFileSafe')

This declaration tells sendmail that you consider it safe to append to archive files from inside :include: files, even when the :include: file is group-writable. The result is that you have streamlined your department’s operation, but you have done so at the price of security.

The sendmail program is paranoid about group-writable permissions because such permissions open the door to intrusion by insiders. Group permissions are managed via the passwd and group files, and :include: files can be silently edited with no record made about what was done to them. Contrast this approach to one that uses sudo(8) or a similar program, to manage access to root and other privileges. The sudo(8) program executes programs (such as an editor to edit an :include: file) with special permissions (such as root) and logs a record of each command executed.

It is vastly better to keep sendmail’s file permissions narrow and to use other security tools to manage those files. We recommend you never use the DontBlameSendmail option to loosen permissions. If you think you need to do so, you should review your overall approach. Try to find a safe way to satisfy your needs, rather than loosening sendmail’s security behavior.

The aliases(5) file is often stored in dbm(3) or db(3) database format for faster lookups. The database files live in the same directory as the aliases file. For all versions of sendmail they are called aliases.dir and aliases.pag for dbm(3), but for V8 sendmail, only a single database file might exist and be called aliases.db for db(3).

It is useless to protect the aliases(5) file if you do not protect its corresponding database files. If the database files are not protected, the attacker can create a private aliases file and then run:

% /usr/lib/sendmail -oA./aliases -bi

This causes sendmail to build ./aliases database files in the current directory. The attacker then copies those bogus database files over the unprotected system originals. The sendmail program never detects the change because the database files appear to be newer than the aliases file.

Note, for best security, that the aliases file and its database files must be owned by root, and be writable only by root. They must live in a directory, every path component of which is owned by and writable only by root.

All versions of sendmail trust the files in the mail queue. They assume that only sendmail has placed files there. As a consequence, a poorly protected queue directory can allow the attacker to create mail that looks 100% authentic. This can be used to send forged mail, to append to system-critical files, or to run arbitrary programs as root or other users. Consider the following bogus qfl0NFMs3g016812 file for sending forged mail (qf files are described in The qf File Internals on page 445):

V8
T829313834
N0
P943442
Fs
$_root@yourhost
S<root@yourhost>
RPFD:george@yourhost
H?P?return-path: <root@yourhost>
Hmessage-id: <200712141257.l0NFSKNK016837@yourhost>
HFrom: root@yourhost
HDate: Thu, 14 Dec 2007 05:47:46 −0800
HTo: george@yourhost
HSubject: Change your Password Now!!

This qf file causes mail to be sent to george that appears in all ways to come from root. There is nothing in this qf file to indicate to the recipient (or to sendmail) that the message is not authentic. Now further suppose that the df file (the message body) contains the following text:

The system has been compromised. Change your password NOW!
Your new password must be:

                           Fuzz7bal
Thank you,
        —System Administration

Unfortunately, in any large organization there will be more than a few users who will obey a message such as this. They will gladly change their password to one assigned to them, thereby providing the attacker with easy access to their accounts.

The queue directory must be owned by and writable only by root or the user defined by the RunAsUser option (RunAsUser on page 1083). CERT recommends that the queue directory always be mode 0700.

The MSP queue of V8.12 and above (typically /var/spool/clientmqueue) must be owned by smmsp, with group smmsp, and should be mode 0770.

The queue files placed into the queue by sendmail must be well protected by defining narrow default permissions with the TempFileMode option (TempFileMode on page 1097) prior to V8.12, or the QueueFileMode option (QueueFileMode on page 1071) beginning with V8.12. A default of 0600 is best for the main queue, and a default of 0660 is recommended for the MSP queue.

We won’t illustrate the SMTP interaction here. But note that anyone can connect to your local sendmail via telnet(1) at port 25 or run sendmail with the -bs command-line switch. Once connected, sendmail must, of necessity, believe everything it receives. The only exception is the hostname sent in the HELO or EHLO message.^[76] In that case, the sendmail program looks up the real hostname based on the connection. If the stated hostname and the real hostname differ, the false name is used as the name of the sending host with the real name added in parentheses:

250 your.host Hello false.host (real.host), pleased to meet you

The real hostname is then used as the sending hostname in the construction of all headers. The result (the header and body received by the user) might look something like this:

From root@false.host Dec 14 14:36:40 2007
Received: from false.host (real.host [real.IP.address]) by your.host (8.14.1/8.14.1)
        id AA00998; Thu, 14 Dec 2007 14:36:38 −0700
Message-Id: <200712141257.l0NFSKNK016837@yourhost>
From: root@false.host (System Administration)
To: you@your.host
Subject: Change your password now!
Date: Thu, 14 Dec 2007 05:47:46 −0800

To improve security at our location you are requested to immediately
change your password. The password you have been assigned is:

        7Fuzzy1's

Thank you,
        --root

Fortunately, this Received: header contains the name of the real host (which is not always the case). An attentive user can tell that this is a forged message because the host in that header line differs from the false hostname used in the other header lines.

However, most mail-reading programs allow users to filter out (prevent your seeing) uninteresting header lines.^[77] Typically, users choose to ignore headers such as Received: and Message-ID:. For such users, the task of detecting forged mail is much more difficult. Instead of seeing the earlier message with real hostnames, they might see the following with only false names:

From root@false.host Dec 14 14:36:40 2007
From: root@false.host (System Administration)
To: you@your.host
Subject: Change your password now!
Date:  Thu, 14 Dec 2007 14:36:38 −0800
To improve security at our location you are requested to immediately
change your password. The password you have been assigned is:

        7Fuzzy1's

Thank you,
        —root

Clearly, a user who sees only this much of the mail message will be more likely to believe that it is real. There are several ways you can educate your users that mail can be forged:

Under pre-V8 sendmail, trusted users are those who are allowed to use the -f command-line switch (-f on page 241) 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. V8.11 and above allow only users in that class to rebuild the aliases database.

Trusted users are necessary for certain kinds of mail to flow properly. For example, the rmail(8) program of the UUCP suite of programs runs set-user-id to uucp. If rmail were not to use the -f 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 list to be dispatched as though it were sent from the address list-request (the -f). This causes errors to be returned to the maintainer of the list (the list-request), but replies still go to the real sender.

Unfortunately, this scheme fails when mail is posted to list 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 -f switch).

T uucp                                       ← legal in V8.1 through V8.6 but
ignored
Troot daemon                                 ← legal in V8.1 through V8.6 but
ignored
Ct uucp                                      ← ignored pre-V8.7
Ctroot daemon                                ← ignored pre-V8.7
define(`confTRUSTED_USERS',`root daemon')    ← V8.7 and above in mc file

sendmail: too many T lines, 32 max

The sendmail program offers several options that can help you to improve the security at your site. Some we have discussed already. 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.

mailnull:*:32765:32765:Sendmail Default User:/no/such/directory:/bin/false

mailnull:*:32765:

mailnull:*:65533:65533:Sendmail Default User:/no/such/directory:/bin/false

define(`confTRUSTED_USER',`user')

O ForwardPath=/usr/local/etc/forwards/$u.forward:$z/.forward

-rw-r—r—  1 root  system   0 Dec 13  2002  /usr/local/etc/forwards/bob.forward

O LogLevel=12      ← V8.8 and above configuration file
define(`confLOG_LEVEL', 12)   ← V8.8 and above mc configuration

# kill -HUP `head −1 /etc/sendmail.pid'

——- Transcript of session follows ——-
 >>> RCPT To:<root@your.site.domain>
 <<< 550 cannot open /tmp/.../getshell: No such file or directory
 550 5.7.1 cannot open /tmp/.../getshell: No such file or directory

O PostmasterCopy=postmaster,securitymaster
                                      ↑
                                    added

define(`confPRIVACY_FLAGS', ``goaway,restrictmailq,restrictqrun'')

define(`confPRIVACY_FLAGS', ``needmailhelo,noexpn,novrfy,noverb,authwarnings,
restrictmailq,restrictqrun'')

O SafeFileEnvironment=/path          ← configuration file
define(`confSAFE_FILE_ENV',`/path')          ← mc configuration

bob:     \bob, /admin/mail/bob.archive

bob:     \bob, /path/admin/mail/bob.archive

O SafeFileEnvironment=/

O TempFileMode=0600       ← pre-V8.12, for all temp files and queue files
O QueueFileMode=0600      ← V8.12 and above, for queue files only, in sendmail.cf
O QueueFileMode=0660      ← V8.12 and above, for MSP queue files only, in submit.cf

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 so:

|"/some/program"
/save/to/a/file

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.^[80] If that file does not exist, sendmail looks up the shell in its internal list, which looks (more or less) like this:^[81]

/bin/bsh
/bin/csh
/bin/ksh
/bin/pam
/bin/posix/sh
/bin/rksh
/bin/rsh
/bin/sh
/bin/tcsh
/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/tcsh

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 pseudouser 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 ftp@here.us.edu doesn't have a valid shell for mailing to programs
User ftp@here.us.edu doesn't have a valid shell for mailing to files

Note that unusual circumstances might require you to allow users with invalid shells to run programs 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:

/SENDMAIL/ANY/SHELL/

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:/bogus/shell

We recommend that all pseudousers (such as bin and ftp) be given invalid shells in the password file and that /SENDMAIL/ANY/SHELL/ never be used.

Be warned, however, that if a user can get into your machine as ftp, it can be possible for that user to run another shell, such as csh(1). Thus, in addition to listing a bogus shell, you might need to take further steps to prevent such access.