22.8.1.1 Declare trusted users (not V8.1 through V8.6)

Trusted users are defined by those lines in the sendmail.cf file that begin with the uppercase letter T. Only trusted users may use the sendmail program's -f command-line switch to specify who sent the message. Beginning with V8.7 sendmail, the class t may also be used.

The 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

The two T commands show that there may optionally be whitespace between the 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 -f switch, that attempt was silently ignored (silently disallowed). Beginning with V8.7 sendmail, if a user who is not trusted attempts to use the -f switch, that attempt may produce an X-Authentication-Warning: header (see Section 35.10.35, X-Authentication-Warning:) if the PrivacyOptions (p) option (see Section 34.8.47) has authwarnings listed.

• Even though some users find them annoying, we recommend that you always enable X-Authentication-Warning: headers. They warn of suspicious behavior. If the behavior is legitimate, modify that behavior to eliminate the header instead of eliminating the more valuable warning headers.

22.8.3.1 The DefaultUser option

The DefaultUser (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 DefaultUser (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:

nullgroup:*:32765:

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

22.8.3.2 The ForwardPath option

The ForwardPath (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 ForwardPath (J) option:

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

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.

22.8.3.3 The LogLevel option

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 LogLevel (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.

22.8.3.4 The PostmasterCopy option

The PostmasterCopy (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:<root@your.site.domain>
<<< 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 PostmasterCopy (P) option:

O PostmasterCopy=postmaster,securitymaster
                                     
                                   added

Here, securitymaster (probably an alias to a real user) was added.

22.8.3.5 The PrivacyOptions option

The PrivacyOptions (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 for the PrivacyOptions (p) is probably best:

O PrivacyOptions=goaway,restrictmailq,restrictqrun

This setting disables the expn and vrfy SMTP commands, requires other sites to identify themselves before sending mail, and also limits access to the mail queue directory.

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.

22.8.3.6 The SafeFileEnvironment option

Beginning with V8.7 sendmail, the 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.

If the 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.)

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

O SafeFileEnvironment=/path

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 by defining /path as the root directory:

O SafeFileEnvironment=/

22.8.3.7 The TempFileMode option

The TempFileMode (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:

O TempFileMode=0600

With this narrow setting, the risk of accidental or malicious easing of permissions of your mail archive directories or queue becomes less of a risk.