O DontBlameSendmail=for,for,...                   configuration file (V8.9 and later) 
-ODontBlameSendmail=for,for,...                   command line (V8.9 and later) 
define(`confDONT_BLAME_SENDMAIL',``for,for,...'') mc configuration (V8.9 and later) 

readcf: DontBlameSendmail option: bad item here unrecognized

DontBlameSendmail=AssumeSafeChown

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.

DontBlameSendmail=ClassFileInUnsafeDirPath

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.

DontBlameSendmail=DontWarnForwardFileInUnsafeDirPath (V8.10 and later)

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.

DontBlameSendmail=ErrorHeaderInUnsafeDirPath

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.

DontBlameSendmail=FileDeliveryToHardLink

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.

DontBlameSendmail=FileDeliveryToSymLink

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.

DontBlameSendmail=ForwardFileInGroupWritableDirPath

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 file—but at increased risk to your system—you 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.

DontBlameSendmail=ForwardFileInUnsafeDirPath

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

DontBlameSendmail=ForwardFileInUnsafeDirPathSafe

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.

DontBlameSendmail=GroupReadableKeyFile (V8.12 and later)

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.

DontBlameSendmail=GroupReadableSASLDBFile (V8.12 and later)

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.

DontBlameSendmail=GroupWritableAliasFile

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.

DontBlameSendmail=GroupWritableDirPathSafe

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.

DontBlameSendmail=GroupWritableForwardFile (V8.12 and later)

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.

DontBlameSendmail=GroupWritableForwardFileSafe

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

DontBlameSendmail=GroupWritableIncludeFile (V8.11 and later)

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.

DontBlameSendmail=GroupWritableIncludeFileSafe

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

DontBlameSendmail=GroupWritableSASLDBFile (V8.12 and later)

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.

DontBlameSendmail=HelpFileInUnsafeDirPath

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.

DontBlameSendmail=IncludeFileInGroupWritableDirPath

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.

DontBlameSendmail=IncludeFileInUnsafeDirPath

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.

DontBlameSendmail=IncludeFileInUnsafeDirPathSafe

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.

DontBlameSendmail=InsufficientEntropy (V8.11 and later)

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.

DontBlameSendmail=LinkedAliasFileInWritableDir

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.

DontBlameSendmail=LinkedClassFileInWritableDir

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.

DontBlameSendmail=LinkedForwardFileInWritableDir

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.

DontBlameSendmail=LinkedIncludeFileInWritableDir

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.

DontBlameSendmail=LinkedMapInWritableDir

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.

DontBlameSendmail=LinkedServiceSwitchFileInWritableDir

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.

DontBlameSendmail=MapInUnsafeDirPath

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.

DontBlameSendmail=NonRootSafeAddr (V8.10 and later)

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.

DontBlameSendmail=RunProgramInUnsafeDirPath (V8.12 and later)

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.

DontBlameSendmail=RunWritableProgram (V8.12 and later)

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.

DontBlameSendmail=Safe

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 item—which cancels all items.

DontBlameSendmail=TrustStickyBit

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.

DontBlameSendmail=WorldWritableAliasFile

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.

DontBlameSendmail=WorldWritableForwardFile (V8.12 and later)

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.

DontBlameSendmail=WorldWritableIncludeFile (V8.12 and later)

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.

DontBlameSendmail=WriteMapToHardLink

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.

DontBlameSendmail=WriteMapToSymLink

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.

DontBlameSendmail=WriteStatsToHardLink

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.

DontBlameSendmail=WriteStatsToSymLink

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.