If the PrivacyOptions option (PrivacyOptions) is declared with authwarnings, V8 sendmail inserts a special header line for possible security concerns. That header line looks like this:

X-Authentication-Warning: host: message

Here, host is the canonical name of the host that inserted this header. The message is one of the following:

Processed by user with -C file

An attempt was made by a user other than root to run sendmail with the -C command-line switch. That switch caused sendmail to read file in place of the system sendmail.cf file.

user set sender to other using -f

A user or program's user identity used the -f command-line switch to change the identity of the sender to other (and user was not listed with the T configuration command). This can be legitimate when the user is uucp or daemon. It can also be legitimate when the user is sending to some mailing lists (Section 10.8). Such a warning can also indicate that someone is trying to forge mail.

user owned process doing -bs

A user or program's user identity used the -bs command-line switch to make sendmail receive a mail message via its standard input/output using the SMTP protocol (and user was not listed with the T configuration command). This parallels network notification set up by defining IDENTPROTO when compiling sendmail and by use of the $_ macro ($_) in Received: headers.

Processed from queue dir

A user other than root used the -oQ (or similar) switch (QueueDirectory) to process mail from a queue directory (dir) that was different from the one specified with the QueueDirectory option in the configuration file. The sendmail program can run as an ordinary user because this or some other command-line switch caused it to give up its special privileges.

Host name1 claimed to be name2

In the HELO message of an SMTP conversation the remote host name1 specified its canonical name as name2, and the two didn't match. This always indicates a problem. Either the remote host is misconfigured (a bad value in $j, $j), the DNS information for that host is wrong, or someone is trying to spoof the local sendmail.

Host name didn't use HELO protocol

Every SMTP conversation for transfer of mail must start with the HELO (or EHLO) greeting. If a MAIL command was first instead, this header is inserted in the incoming message. The most likely cause of a missing HELO or EHLO is the mistake of someone attempting to carry on an SMTP conversation by hand.