For security it is desirable to control the manner and circumstances under which messages are delivered to files. Beginning with V8.7 sendmail you can enhance the security of writing to files with the SafeFileEnvironment option. It is used like this:

O SafeFileEnvironment=path           configuration file (V8.7 and later) 
-OSafeFileEnvironment=path           command line (V8.7 and later) 
define(`confSAFE_FILE_ENV',path)     mc configuration (V8.7 and later) 

The path is of type string and, if present, must be the full pathname of a directory. The default, if either path or the entire option is missing, is NULL, causing this feature to be ignored.

When preparing to save a message to a file, sendmail first obtains the permissions of that file, if the file exists, and saves them (Section 12.2.2). The sendmail program uses lstat(2) to obtain those permissions if it was compiled with HASLSTAT defined (HAS...). Otherwise, it uses stat(2).

If the path for this option is non-NULL and nonempty, sendmail then precedes that chroot(2) with a:

chroot(path)

If the chroot(2) fails, sendmail prints the following error and bounces the mail message:

mailfile: Cannot chroot(path)

If the name of the file begins with path, that prefix is stripped after the chroot(2) and before the fopen(3).

For example, consider the need to safely store all mail archive files on the mail hub in a directory called /archives. You would first create this configuration declaration:

O SafeFileEnvironment=/archives

Then every file archive notation in the aliases database should be changed to reference this base directory:^[59]

^[59] This is not strictly necessary. Both /archives/admin/log and /admin/log will work equally well. The former, however, is preferred for clarity.

adminlist:   :include:/usr/local/maillists/admin.list,
             /archives/admin/log

For safety, sendmail will henceforth chroot(2) into the /archives directory before delivering to any files. Note that this SafeFileEnvironment option affects all writes to files, so a user's ~/.forward entry (such as the following) will become relative to /archives and so might fail depending on your specific setup:

/u/bill/tmp/incoming  written as /archives/u/bill/tmp/incoming

The SafeFileEnvironment option also causes sendmail to verify that the file that is being written to is a plain file. If it is anything else, sendmail prints the following error and bounces the messages:

/dev/tty... Can't create output: Error 0

Here, an attempt to dump the message to /dev/tty failed because sendmail discovered it was a device rather than an ordinary file. But note that beginning with V8.8, it is always legal to write to the special device named /dev/null.

The SafeFileEnvironment option is not safe. If specified from the command line, it can cause sendmail to relinquish its special privileges.