DontBlameSendmail |
Relax file security checks | V8.9 and later |
Item |
§ |
Meaning |
---|---|---|
AssumeSafeChown |
See this section |
Assume chown(2) is safe. |
ClassFileInUnsafeDirPath |
See this section |
Allow F class macro files in unsafe directory paths. |
DontWarnForwardFileInUnsafeDirPath |
See this section |
Omit warnings about forward files in unsafe directories. |
ErrorHeaderInUnsafeDirPath |
See this section |
Allow ErrorHeader file in unsafe directory paths. |
FileDeliveryToHardLink |
See this section |
Allow delivery to hard-linked files. |
FileDeliveryToSymLink |
See this section |
Allow delivery to symbolic links. |
ForwardFileInGroupWritableDirPath |
See this section |
Allow forward files in group-writable directory paths. |
ForwardFileInUnsafeDirPath |
See this section |
Allow forward files in unsafe directory paths. |
ForwardFileInUnsafeDirPathSafe |
See this section |
Unsafe forward files can forward to files and programs |
GroupReadableKeyFile |
See this section |
Accept a group-readable key file for STARTTLS |
GroupReadableSASLDBFile |
See this section |
Accept a group-readable Cyrus SASL password file |
GroupWritableAliasFile |
See this section |
Allow alias files that are group-writable. |
GroupWritableDirPathSafe |
See this section |
Consider group-writable directory paths safe. |
GroupWritableForwardFile |
See this section |
Allow forward files that are group-writable. |
GroupWritableForwardFileSafe |
See this section |
Allow unsafe forward files to write to files and programs. |
GroupWritableIncludeFile |
See this section |
Allow:include: files that are group-writable. |
GroupWritableIncludeFileSafe |
See this section |
Allow unsafe :include: to write to files and programs. |
GroupWritableSASLDBFile |
See this section |
Accept a group-writable Cyrus SASL password file. |
HelpFileInUnsafeDirPath |
See this section |
Allow the help file to live in an unsafe directory path. |
IncludeFileInGroupWritableDirPath |
See this section |
Allow:include: files to live in group-writable directory paths. |
IncludeFileInUnsafeDirPath |
See this section |
Allow :include: files to live in unsafe (group- or world-writable) directory paths. |
IncludeFileInUnsafeDirPathSafe |
See this section |
Allow :include: files in unsafe directory paths to deliver to files or programs. |
InsufficientEntropy |
See this section |
Use STARTTLS even if the PRNG for OpenSSL is not properly seeded |
LinkedAliasFileInWritableDir |
See this section |
Allow a hard-linked aliases file to live in an unsafe directory. |
LinkedClassFileInWritableDir |
See this section |
Allow a hard-linked F class macro file to live in an unsafe directory. |
LinkedForwardFileInWritableDir |
See this section |
Allow a hard-linked forward file to live in an unsafe directory. |
LinkedIncludeFileInWritableDir |
See this section |
Allow a hard-linked :include: file to live in an unsafe directory. |
LinkedMapInWritableDir |
See this section |
Allow a hard-linked database map file to live in an unsafe directory. |
LinkedServiceSwitchFileInWritableDir |
See this section |
Allow a hard-linked service switch file to live in an unsafe directory. |
MapInUnsafeDirPath |
See this section |
Allow database-map files to live in unsafe directory paths. |
NonRootSafeAddr |
See this section |
When not running as root, allow delivery to files and programs. |
RunProgramInUnsafeDirPath |
See this section |
Allow programs to run from inside unsafe directory paths. |
RunWritableProgram |
See this section |
Allow programs to run that are group- or world-writable. |
Safe |
See this section |
Like the default, completely safe. |
TrustStickyBit |
See this section |
Writable directories are safe if the sticky bit is set. |
WorldWritableAliasFile |
See this section |
Allow the aliases file to be world-writable. |
WorldWritableForwardFile |
See this section |
Allow forward files to be world-writable. |
WorldWritableIncludeFile |
See this section |
Allow :include: files to be world-writable. |
WriteMapToHardLink |
See this section |
Write to database maps that are hard links. |
WriteMapToSymLink |
See this section |
Write to database maps that are symbolic links. |
WriteStatsToHardLink |
See this section |
Write to the status file that is a hard link. |
WriteStatsToSymLink |
See this section |
Write to the status file that is a symbolic link. |
Note that you can have a configuration file that you think might require one of these flags. But before you set it, think carefully about how setting it might affect other files that might also be involved. If you do set one of these flags, and then your machine is broken into, don't blame sendmail!
In the sections to follow, we describe the purpose and use of each item. Note that not all items produce error messages that might indicate a risk to be corrected. Also note that these items are grouped alphabetically, not by related function.
Assume that the chown(2) system call is restricted to root. Some versions of Unix and some implementations of NFS permit regular users to give away their files to other users. On such systems sendmail is unable to safely assume that a file was necessarily created by the owner of that file, particularly when that file is in a directory that is writable by anyone other than just root. You can enable this item if you know that file chown(2) is restricted to root on your system. If in doubt, see test/t_pathconf.c for a way to test this.
When reading a file using the F configuration command (Section 22.1.2), sendmail will disallow that reading when the file lives in an unsafe directory path. Should such a file be found, sendmail will print and log one of the following messages and skip reading that file:
configfile: line num: fileclass: cannot open Ffile: Group-writable directory configfile: line num: fileclass: cannot open Ffile: World-writable directory
An unsafe directory path is one where any component is writable by a user other than root or the trusted user specified in the TrustedUser option (TrustedUser). If your site needs to place such F files in unsafe directory paths, and if you are not able to correct the situation, you can enable this item. With ClassFileInUnsafeDirPath enabled, you increase risk but allow sendmail to read F files that live in unsafe directory paths.
Before sendmail will read a user's ~/.forward file (Section 13.7), it will first check to see that the directory it is in is safe. A safe directory in this instance is one whose path components are writable only by root or by the owner. Beginning with V8.10, if the path is unsafe, sendmail will print and log one of the following warnings and skip reading that file:
user... forward: /path: Group-writable directory user... forward: /path: World-writable directory
Here, user is the user whose login directory probably has bad permissions set on it, and path is the full path to the ~/.forward file. Note that many lines such as these will be logged because sendmail tries variations with + and host-based suffixes when looking for a ~/.forward file (see also the ForwardPath option, ForwardPath). Also note that these warnings will be logged even if the ~/.forward file does not exist.
Some circumstances might require you to allow users to maintain group-writable directories. If you cannot avoid that risky situation, you can enable this item. With this DontWarnForwardFileInUnsafeDirPath item enabled, you turn off only the logging. Note that any unsafe forward files will still not be used.
The ErrorHeader option (ErrorHeader) is used to (optionally) declare the name of a file that contains the text of a message to include in bounced email messages. Ordinarily sendmail requires a file to live in a safe directory path. A directory path is safe when all components are writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). If the ErrorHeader file is found in an unsafe directory path, sendmail will silently skip using that file.
Site policy might require you to maintain that file in an unsafe directory path (perhaps on a central disk served via NFS). If you cannot remedy this situation you can enable this item. By specifying the ErrorHeaderInUnsafeDirPath item, you increase risk but allow the ErrorHeader option's file to live in an unsafe directory path.
Ordinarily, sendmail will not append mail to files that have more than one link. Such files pose a problem because sendmail has no idea if such links are to special files (such as /etc/passwd), and so cannot check to see if those other links live in safe directory paths. If sendmail finds such a file when trying to deliver, it will bounce the message with an error such as this:
/path
(reason: can't create (user) output file)
Here, path is the full pathname to the file that had more than one link. If you need to maintain hard links for administrative reasons, you can enable this item. When you enable the FileDeliveryToHardLink item you increase risk but allow sendmail to deliver to files that are hard links.
Ordinarily, sendmail will not append mail to files that are symbolic links to other files. Although V8.10 correctly checks the path to the link and to the pointed-to file, it still will not append mail to such files. If sendmail attempts to deliver to a file that is a symbolic link, it will bounce the message with an error such as this:
/path
(reason: can't create (user) output file)
Here, path is the full pathname to the file that is a symbolic link. If you need to maintain symbolic links for administrative reasons, you can enable this item. When you enable the FileDeliveryToSymLink item you increase risk but allow sendmail to deliver to files that are symbolic links.
In general, the path to a user's home directory, and that home directory, should be writable only by root or that user. There are circumstances, however, when groups of users or pseudo-users must share a single home directory. In such an instance, it might be desirable for them all to have writable permission to that directory. This can be done by enabling group write permissions. If you do, however, sendmail will begin to reject the common ~/.forward file found in that directory with the following warning:
user... forward: /path: Group-writable directory
To prevent this warning but allow sendmail to honor that ~/.forward filebut at increased risk to your systemyou can enable this item. By enabling this ForwardFileInGroupWritableDirPath item, you increase risk but allow ~/.forward files (Section 13.7) to reside in group-writable directory paths.
Generally, ~/.forward files (Section 13.7) must live in safe directory paths. A directory path is safe when all components are writable only by root, and when its last component is writable only by root or the owner. If some component of the path to a user's home is unsafe, one of the following messages will be printed and logged when mail is sent to that user:
user... forward: /path: Group-writable directory user... forward: /path: World-writable directory
When this message is printed, sendmail refuses to honor that user's ~/.forward file.
If your site places user homes under directory paths that are unsafe, and if you are unable to correct this flaw, you might need to enable this item. By enabling this ForwardFileInUnsafeDirPath item, you increase risk but allow sendmail to honor ~/.forward files that live in unsafe directory paths. (Also see ForwardFileInUnsafeDirPathSafe in the next section.)
Even if you allow ~/.forward files (Section 13.7) to live in unsafe directories, sendmail will still not honor lines in that file that forward mail to files or programs because it is felt that an insecure ~/.forward file poses a grave risk to the user. If you disagree, or have some reason to relax this rule, you can define this item. With it, you increase risk but allow any ~/.forward file that is in an unsafe directory path to forward mail to files and programs.
The TLS key file used by STARTTLS should normally be readable only by the owner of the file. That owner should be root or the trusted user specified in the TrustedUser option (TrustedUser).
At some sites, for ease of administration, it is sometimes necessary to allow that file to be group-readable. At such sites you will need to define this item. If you don't, sendmail will refuse to honor that key file.
The Cyrus SASL password file, as set up with the saslpasswd(8) program, must be readable only by the owner of the file. That owner should be root or the trusted user specified in the TrustedUser option (TrustedUser).
If, for possible administrative reasons (such as to share it with other SASL applications, such as Cyrus IMAP), you need that file to be group-readable, you will have to define this item. If you don't, sendmail will refuse to honor the file.
The aliases file (Section 12.1) should generally be writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). By allowing it to be writable by others, you risk allowing bogus and dangerous entries to be placed into it. Some sites, however, allow system administrators to edit that file, without the need to become root. Permission to edit is granted by allowing group-writability. But if you do that, the following message will be printed and logged and you will be unable to rebuild the aliases database:
cannot open /etc/mail/aliases: Group-writable file
If you need to allow group-writable aliases files, you can enable this item. By enabling this GroupWritableAliasFile item, you increase risk but allow sendmail to rebuild the aliases database without complaint, even if it is group-writable.
An unsafe directory path is one in which any component is writable by a user other than root or the trusted user specified in the TrustedUser option (TrustedUser). Normally, :include: and ~/.forward files can only contain lines that cause writes to files or writes through programs, if those :include: and ~/.forward files live in safe directory paths.
If you wish :include: files to live in directory paths in which one or more directories have the group-writable permissions set, and if you expect to retain the same ability to write to files or through programs, you must define this item, and one more:[23]
[23] When the argument to an m4 define command contains one or more commas, that argument should be enclosed in double half-quotes.
define(`confDONT_BLAME_SENDMAIL',``GroupWritableDirPathSafe, IncludeFileInGroupWritableDirPath'')
If you wish ~/.forward files to live in directory paths in which one or more directories have the group-writable permissions set, and if you expect to retain the same ability to write to files or through programs, you must define this item, and one more:
define(`confDONT_BLAME_SENDMAIL',``GroupWritableDirPathSafe, ForwardFileInGroupWritableDirPath'')
Note that if a group-writable directory is not the last directory in the path, all directories and files under it can be at risk. If you require a group-writable directory, we recommend you make it the last in the path.
Generally, ~/.forward files (Section 13.7) should be writable only by root or the owner. Such safe files allow sendmail to honor lines in them that deliver via file or program entries. If a ~/.forward file has group-write permission set, sendmail will refuse to open the file and will log the following error (if the LogLevel (LogLevel) option's value is 12 or higher):
/path: group-writable forward file, marked unsafe
Sometimes it can be unavoidably necessary for a user's ~/.forward file to be group-writable. If so, you can define this item to allow ~/.forward files to be group-writable. Although this will allow sendmail to read such files, sendmail will still disallow delivery via file or program entries.
Generally, ~/.forward files (Section 13.7) should be writable only by root or the owner. Sometimes it can be unavoidably necessary for a user's ~/.forward file to be group-writable. If group-writable ~/.forward files exist at your site, such files will be considered unsafe. And if the LogLevel (LogLevel) option's value is 12 or higher, you will see the following warning:
/path: group-writable forward file, marked unsafe
An unsafe ~/.forward file causes sendmail to disallow delivery via files or program entries. If you cannot avoid group-writable user ~/.forward files, you can enable this item. By enabling this GroupWritableForwardFileSafe item, you increase risk, allow sendmail to accept group-writable ~/.forward files, but allow those group-writable ~/.forward files to deliver to files and to programs. But note that this GroupWritableForwardFileSafe item will be ignored unless GroupWritableForwardFile is also set to allow the file to be read in the fist place (that is, before determining if the contents are safe).
Generally, :include: files (Section 13.2) should be writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). Such safe permissions allow sendmail to honor lines in :include: files that write to files, or through programs. If a :include: file has group-write permission set, sendmail will refuse to open the file and will log the following error (if the LogLevel (LogLevel) option's value is 12 or higher):
/path: group-writable :include: file, marked unsafe
Sometimes it can be unavoidably necessary for a :include: file to be group-writable. You can define this item to allow :include: files to be group writable. Although this will allow sendmail to read such files, sendmail will still disallow delivery via file or program entries.
Generally, files that are included with the :include: (Section 13.2) directive from inside an aliases file must be writable only by root or the trusted user specified in the TrustedUser option (TrustedUser), but some sites find it easier to administer mailing lists when system administrators can edit those files using only group permissions on each file, instead of having to become root each time. If this is the situation at your site, you will see the following warning logged when the LogLevel (LogLevel) option's value is 12 or higher:
/path: group-writable :include: file, marked unsafe
An unsafe :include: file causes sendmail to disallow delivery via files or program entries. If you cannot avoid group-writable :include: files, you can enable this item. By enabling this GroupWritableIncludeFileSafe item, you increase risk but allow sendmail to accept group-writable :include: files. But note that this GroupWritableIncludeFileSafe item will be ignored unless GroupWritableIncludeFile is also set to allow the file to be read in the first place (that is, before determining if the contents are safe).
The Cyrus SASL password file, as set up with the saslpasswd(8) program, must be writable only by the owner of the file. That owner should be root or the trusted user specified in the TrustedUser option (TrustedUser).
Sometimes for administrative reasons you might need to have that file group-writable (for example, to share it with other SASL applications). If you do, you will need to define this item. If you don't, sendmail will refuse to honor the file.
The HelpFile option (HelpFile) specifies the location of the file from which sendmail gathers the help lines for its SMTP connections and for its -bt mode. That file must live in a safe directory path, or sendmail will not be able to offer help:
% /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > ? Sendmail *[sendmail_release] -- HELP not implemented
A safe directory path is one in which all components are writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). If your site is set up in such a way that this file must live in an unsafe directory path, and if you cannot fix the problem, you can enable this item. With this HelpFileInUnsafeDirPath item enabled, sendmail will run at greater risk, but will allow the help file to live in an unsafe directory.
Generally, files that are included with the :include: (Section 13.2) directive from inside an aliases file must live in a directory path, all components of which must be writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). But some sites find it easier to administer mailing lists when administrators can add files without the need to become root each time. By setting the group-writable permission on the directory in the directory path, you can enable anyone in that group to create new files. (Of course, they might still need to be root to add new references to the aliases file.) If you set group-write permission, however, sendmail will ignore the :include: files in that directory and will log this error:
:include:/path... Cannot open /path: Group-writable directory
If you need to maintain group-writable directory paths for :include: files, you can enable this item. By enabling this IncludeFileInGroupWritableDirPath item, you increase risk, but allow :include: files to live in group-writable directory paths.
Files that are included with the :include: (Section 13.2) directive from inside an aliases file must live in a safe directory path. A safe directory path is one in which all components are writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). But sometimes, such :include: files must live in a directory in which some component of its directory path is writable by root as well as others. When that is the case, sendmail will log one of the following errors and will ignore those :include: files:
:include:/path... Cannot open /path: Group-writable directory :include:/path... Cannot open /path: World-writable directory
If yours is such a site, and if you cannot correct the permissions, you can specify this item. By enabling this IncludeFileInUnsafeDirPath item, you increase risk, but allow :include: files to live in unsafe directory paths.
Even if you allow :include: files (Section 13.2) to live in unsafe directories, sendmail will refuse to honor any references in them for delivery to files or programs. This behavior is benign when only lists of addresses exist in those :include: files. But if you need to further reference files and programs, you will also need to enable this item. With it enabled, sendmail will run at greater risk, and will allow a :include: file that is in an unsafe directory to include references to programs and files.
The TLS library requires a strong pseudorandom number generator to operate at maximum security. Depending on the version of the library you have installed, you might be required to initialize that random number generator with random data. The OpenSSL library uses the /dev/urandom device to perform that initialization. On systems that lack /dev/urandom, a random file must be specified in its place. This is done with the RandFile option (RandFile).
If the RandFile option's file is not properly initialized with random data, or if that file is not updated in a timely fashion, sendmail will refuse to honor STARTTLS. Although you are strongly encouraged to either set up a good RandFile option's file, or to run the egd(8) daemon (Section 10.10.1.3), you might be unable to do so. In such a circumstance, you can define this InsufficientEntropy item. When defined, it allows sendmail to use STARTTLS even though the pseudorandom number generator was not properly initialized, which silently weakens the cryptography used.
When a file lives in a directory that is writable by users other than root, or the trusted user specified in the TrustedUser option (TrustedUser), it should not be a link because other users can remove the link and replace it with a file or link of their own. The aliases file (Section 12.1) should generally be a file, not a link, but if it is a link, and if that link exists in an unsafe directory, sendmail will refuse to use it. If your aliases file is a link, and if that link must live in a writable directory, you can enable this item. By enabling this LinkedAliasFileInWritableDir item, you cause sendmail to run at increased risk, and to allow aliases files that are links to live in a writable directory.
When a file lives in a directory that is writable by users other than root, or the trusted user specified in the TrustedUser option (TrustedUser), it should not be a link because other users can remove the link and replace it with a file or link of their own. When reading a file using the F configuration command (Section 22.1.2), sendmail will ordinarily not allow such files to be links that live in writable directories. When such files are links, and if that link lives in a directory that is unsafe, sendmail will run at increased risk and will allow F files that are links to live in writable directories.
When a ~/.forward file lives in a home directory that is writable by users other than the owner or root, it should not be a link. Those other users can remove the link and replace it with a file or link of their own. Generally, sendmail will not honor ~/.forward files that are links that live in writable directories. When such links are necessary, and when a writable directory cannot be avoided, you can enable this item. With this LinkedForwardFileInWritableDir item enabled, sendmail will run at increased risk, and will honor ~/.forward files that are links and that live in writable directories.
When a file lives in a directory that is writable by users other than root, or the trusted user specified in the TrustedUser option (TrustedUser), it should not be a link. Those other users can remove the link and replace it with a file or link of their own. If you feel you can control this risk, you can enable this item. With this LinkedIncludeFileInWritableDir item enabled, sendmail will run at increased risk and will allow :include: files to be links that can live in writable directories.
When a database-map file lives in a directory that is writable by users other than root, or the trusted user specified in the TrustedUser option (TrustedUser), it should not be a link. Those other users can remove the link and replace it with a file or link of their own. Database-map files (Section 23.2) that are links and live in writable directories will not be honored by sendmail. When such database-map files must be links, and when those links must unavoidably live in writable directories, you can enable this item. With this LinkedMapInWritableDir item enabled, sendmail will allow map (database) files that are links to live in writable directories.
When a service switch file lives in a directory that is writable by users other than root, or the trusted user specified in the TrustedUser option (TrustedUser), it should not be a link. Those other users can remove the link and replace it with a file or link of their own. The ServiceSwitchFile option (ServiceSwitchFile) specifies the file that defines how aliases and other services will be handled. It can, for example, define aliases to be first looked up with NIS, and if that fails to be looked up in the aliases database. Sometimes it might be desirable for this file to be a link. When such a link must unavoidably live in a writable directory, you can enable this item. With this LinkedServiceSwitchFileInWritableDir item enabled, sendmail will run at increased risk, and will allow the ServiceSwitchFile option's file to be a link even if it lives in a writable directory.
Map (database) files (Section 23.2) must live in safe directories. A safe directory is one in which all components of its path are writable only by root or the trusted user specified in the TrustedUser option (TrustedUser). If your site stores maps (databases) in a directory, some component of which is writable by a user other than root, and if you cannot correct that situation, you can enable this item. With it enabled, sendmail allows map (database) files to live in unsafe directories.
The sendmail program usually runs as root because it is run by root. With the RunAsUser option (RunAsUser), sendmail can run as a user other than root. When the RunAsUser option (RunAsUser) specifies a non-root user, all file and program delivery will be banned, and such messages will be bounced. If you wish to allow file and program delivery to succeed, even though the RunAsUser option defines a non-root user, you can define this item. With this NonRootSafeAddr item enabled, sendmail will run at increased risk, but will honor file and program delivery when it is running as a non-root user.
Generally, sendmail prefers to run a program for delivery that is in a safe directory path. A safe directory path is one in which all components are writable only by root, or the trusted user specified in the TrustedUser option (TrustedUser). If a program lives in an unsafe directory, sendmail will execute it anyway, but will log this warning:
Warning: program program_name unsafe: reason
If, for some reason, you are unable to put all required programs in safe directories, you can enable this item. With this RunProgramInUnsafeDirPath item enabled, sendmail ceases logging such warnings.
For sendmail to trust a program, it prefers that the program be writable only by its owner and root. If sendmail is required to run a program that is group- or world-writable, it will do so, but will log the following warning:
Warning: program program_name unsafe: reason
If, for some reason, you are unable to prevent all required programs from having bad permissions, you can enable this item. With this RunWritableProgram item enabled, sendmail ceases logging such warnings.
When sendmail first starts, it clears (zeros) all the DontBlameSendmail items to establish a default condition of maximum safety (minimum risk). This Safe item does the same thing by clearing all the other items. As a side effect, if you list Safe last in a sequence of items, you cancel any preceding items. For example:[24]
[24] When the argument to an m4 define command contains one or more commas, that argument should be enclosed in double half-quotes.
define(`confDONT_BLAME_SENDMAIL',``TrustStickyBitSafe, Safe'') define(`confDONT_BLAME_SENDMAIL',`Safe')
Here, both lines are equivalent. In the first line, the TrustStickyBitSafe item was cancelled because it was followed by a Safe itemwhich cancels all items.
If the sticky bit is set on a directory, a user other than root cannot delete or rename files of other users in that directory. If your operating system correctly honors the sticky bit on a directory, and if you wish to use that mechanism instead of safe directories, you can enable this item. With this TrustStickyBit item enabled, sendmail can run at increased risk and will honor group- and world-writable directories that have the sticky bit set.
At small sites, sometimes everyone is trusted to add and remove aliases from the aliases file. To allow this, some sites make the aliases file world-writable. Ordinarily, sendmail will refuse to use an aliases file that is so extremely unsafe. If you enable this WorldWritableAliasFile item, sendmail will run at extreme risk, and will go ahead and use an aliases file that is world-writable.
Despite the security risks (Section 10.5.3), some sites allow world writable ~/.forward files. If your site is one of these, you can prevent sendmail from complaining and ignoring those world-writable ~/.forward files by defining this item.
Note, however, that we recommend you prohibit world-writable ~/.forward files and not use this item as a bandage.
Despite the security risks (Section 10.5.2), some sites allow world-writable :include: files. If your site is one of these, you can prevent sendmail from complaining and ignoring those world-writable :include: files by defining this item.
Note, however, that we recommend you prohibit world-writable :include: files and not use this item as a bandage.
Ordinarily, sendmail will not update database-map files that have more than one link. Such files pose a problem because sendmail has no idea if such links are to special files (such as /etc/passwd), and so cannot check to see if those other links live in safe directory paths. A directory path is safe when all components are writable only by root or the trusted user specified in the TrustedUser option (TrustedUser).
To allow updates to database-map files that are hard links, set this item.
Ordinarily, sendmail will not update map (database) files that are symbolic links to other files. Although V8.10 correctly checks the path to the link, and to which the file points, it still will not update such files. To allow updates to map (database) files that are symbolic links, enable this item. With this WriteMapToSymLink item enabled, sendmail will run at increased risk and will update map (database) files that are symbolic links.
Ordinarily, sendmail will refuse to update the file indicated by the StatusFile option (StatusFile) when that file has more than one link. Such a file poses a problem because sendmail has no idea if links are to special files (such as /etc/passwd), and so cannot check to see if that other link lives in a safe directory. A directory is safe when all components of its path are writable only by root or the trusted user specified in the TrustedUser option (TrustedUser).
To allow updates to the status file, when that file has hard links, enable this item. With this WriteStatsToHardLink item enabled, sendmail will run at increased risk, and will update the status file even if it is a hard link.
Ordinarily, sendmail will not update the file indicated by the StatusFile option (StatusFile) when that file is a symbolic link. V8.10 correctly checks the path of both the link and the file pointed to, but it still will not update the file. To allow updates to a status file that is a symbolic link, just define this item. With this WriteStatsToSymLink item enabled, sendmail will run at increased risk, and will update the status file even if it is a symbolic link.