The Smail 3.x program (a UUCP-oriented replacement for sendmail) produces an Apparently-From: header when it is unable to find any of the official sender headers in a mail message. The address that it provides to this nonstandard header is taken from the envelope of the message.

The sendmail program, on the other hand, places the envelope sender into a From: header in this situation. If there is no envelope sender and if the sender was not specified in the command line, sendmail sets the sender to be postmaster.

The Apparently-From: header is mentioned here only because it may appear in messages received at sites that run sendmail. It shouldn't cause problems, because a good sender address still appears in the SMTP envelope.

The Apparently-From: header should never be declared in the configuration file and should not be added to conf.c.

If the header of a mail message lacks recipient information (lacks all of the To:, Cc:, and Bcc: header lines), sendmail adds an Apparently-To: header line and puts the recipient's address from the envelope into the field of that line. This behavior is hard-coded into pre-8.7 sendmail, but beginning with version 8.7, it can be tuned with the NoRecipientAction option (see Section 34.8.43).

The Apparently-To: header name is not defined in RFC822. It is added by pre-8.7 sendmail because RFC822 requires at least one To: or Cc: header, and neither is present.

An Apparently-To: header should never be defined in the configuration file.

When a message is returned because of an error or because a "return receipt" was requested, V8 sendmail adds an Auto-Submitted: header. This header describes the reason for the return:

Auto-Submitted: auto-generated (reason)

The reason can be one of four things: It can be warning-timeout if the message has reached its Timeout.queuewarn option threshold (see Section 34.8.70, Timeout (r)). It can be postmaster-warning if the failure was delivered to the postmaster as a result of a problem that the postmaster should fix, such as an MX configuration error. It can be return-receipt if the message was returned because of a Return-Receipt-To: header (see Section 35.10.29) or a DSN NOTIFY=SUCCESS request (see RFC1891). Finally, it can be failure for any other reason.

In all instances, sendmail also adds a Subject: header that contains the actual text that led to the bounce or return. This text is identical to that saved in the qf file's M line (see Section 23.9.9, M line).

The Auto-Submitted: header should never be defined in the configuration file.

A blind carbon copy is a copy of the mail message that is sent to one or more recipients without the knowledge of the primary recipients. Primary recipients are listed in the To: and Cc: lines. When there are multiple blind carbon copy recipients, knowledge of each other is also hidden.

When run with a -t command-line switch (to gather recipients from the headers), the sendmail program achieves this end by saving a list of all the blind carbon copy recipients, deleting the Bcc: header line, and then delivering to each blind carbon copy recipient. (See the Apparently-To: header.)

The Bcc: header should never be declared in the configuration file.

The field for the Bcc: header must contain one or more properly formed addresses. Where there is more than one, each should be separated from the others by commas.

The Cc: header is one of a few that specify the list of primary recipients. The sendmail program treats the Cc: header no differently from the way it treats the To: header. From the user's point of view, the Cc: header implies that there are recipients to whom an informational copy of the message was supplied.

The Cc: header should never be declared in the configuration file.

The field for the Cc: header must contain one or more properly formed addresses.

The Comments: header is used to place explanatory text into the header portion of an email. The field portion of the Comments: header may contain arbitrary text.

One possible use for a Comments: header would be to notify recipients that one person is replying to mail for another:

Comments: Ben is in France for the next month or
          so gathering information for the meeting.
          I am handling his mail while he is away.
   
   whitespace

The Comments: header should rarely be declared in the configuration file. If it is, it should be prefixed with appropriate ?flags?. For example,

H?B?Comments: Local delivery is experimentally being handled
       by a new program. Complaints to root.

This comment is included only in headers that are delivered via the local delivery agent, because that delivery agent is the only one to include the F=B flag:

Mlocal, P=/bin/mail, F=rlsDFMmnPB, S=10, R=20, A=mail -d $u

For all versions of sendmail except V8, if there is already a Comments: header in the message, this configuration-file declaration is ignored. For V8 sendmail this declaration will always cause the new Comment: header to be added to the mail message.

The Content-Length: header describes the approximate size of the body of a message. The size is always a decimal expression of the number of bytes occupied by the body.

Content-Length: 5678

It is used by some MUAs to find a message faster in a large file of many messages. It is always created or added by MUAs or delivery agents and never by MTAs. It should never be declared in the configuration file.

For Sun's version of V8 sendmail the behavior of the Content-Length: can be traced with the -d80 debugging switch (see Section 37.5.190, -d80.1). All other versions of sendmail ignore this header.

The MIME Content-Transfer-Encoding: header describes what auxiliary encoding was applied to the message body to allow it to pass through email transport mechanisms that may have data or character set limitations. Specifically, RFC821 requires message bodies to contain only 7-bit data. To transport 8-bit data (such as images and sounds) via SMTP, it is necessary to convert that data to 7 bits. The Content-Transfer-Encoding: header specifies precisely how that conversion was done:

Content-Transfer-Encoding: how

Here, how is defined by RFC821 to be one of the following: base64 (see RFC1521), quoted-printable (see Section 34.8.22, EightBitMode (8)), 8bit (meaning that the message body contains unencoded 8-bit data in line length suitable for SMTP transport), 7bit (the message body contains 7-bit, SMTP-compliant data), or binary (the message body contains 8-bit data in a form that is completely unsuitable for SMTP transport).

See the EightBitMode (8) option (see Section 34.8.22) for a description of how V8 sendmail converts between 8- and 7-bit data. The Content-Transfer-Encoding: header should never be declared in the configuration file.

The Content-Type: header describes the nature of the body of a mail message. In the absence of such a header, the body is presumed to be composed of ASCII characters that have their high (most significant) bits turned off. One possible setting for this header might look like this:

Content-Type: text/plain; charset=ISO-8859-1

This header says that the body uses the ISO-8859-1 character set.

This header is usually created by the originating MUA. It should never be declared in the configuration file of pre-V8.7 versions of sendmail. Beginning with V8.7, the content type for 8- to 7-bit MIME conversions can be declared with the DefaultCharSet option (Section 34.8.14, DefaultCharSet).

When bouncing mail, V8 sendmail creates a MIME-compliant message and includes a Content-Type: header like this:

Content-Type: multipart/mixed; boundary="boundary"

If sendmail was compiled to include DSN support (see Section 18.8.5, DSN), the Content-Type: header will look like this:

Content-Type: multipart/report; report-type=delivery-status;
        boundary="boundary"

The Date: header specifies the date and time that the mail message was originally sent. All mail messages must include this header line. Consequently, the Date: header must be declared in the configuration file like this:

H?D?Date: $a

The $a macro (see Section 31.10.2, $a) is mandatory in the field for this header. The value in $a is the current time in RFC822 format. (See Section 5.1 in RFC822 and Section 5.2.14 in RFC1123.) Only the $a macro should be used with the Date: header, because it is the only one that is guaranteed to contain the current date and time in RFC822 (and RFC1123) format.

The ?D? flag is always included with the Date: declaration in the configuration file. All the standard delivery agents always include a F=D flag (see Section 30.8.17, F=D). The ?D? allows custom delivery agents to be designed that do not need a Date: header.

The qmail program uses a Delivered-To: header to trace all the alias and mailing list expansions through which an email message passes. This is similar to the way Received: headers are used to trace machine hops. When qmail expands a mailing list, it adds a Delivered-To: header to the top of the message:

Delivered-To: list@host

If an identical header is already present, qmail bounces the message. This prevents several kinds of mail loops. (Note that the SmartList program supports an X-Loop: header with the same function.)

This technique is further described in the following draft document:

ftp://koobera.math.uic.edu/pub/docs/RFCLOOPS

The Delivered-To: header should never be declared in the configuration file.

The Encrypted: header is used to describe a translation that has been performed on the body of the mail message. Although encryption is implied, other forms of translation, such as compression and uuencode(1), are perfectly legal.

The sendmail program ignores the Encrypted: header. This header is intended for use by MUAs. Unfortunately, most (if not all) UNIX MUAs also ignore this header. The form for the Encrypted: header is:

Encrypted: prog key

The field contains one mandatory item, the prog, and one optional item, the key. The prog is the name of the program that was used to transform the message body. The optional key is a decryption key.

If translating the message body into a different form, be aware that many versions of sendmail strip the eighth bit from all bytes of the body during transmission.

The Encrypted: header should never be declared in the configuration file.

Ordinarily, errors are bounced to the envelope sender. The Errors-To: header specifies the address, or addresses, to which sendmail should send additional notification of delivery errors.

The Errors-To: header is intended for use by mailing lists to prevent errors in a list from being rebroadcast to the list as a whole. For example, consider the mailing list allusers. Mail that is sent to this list should contain the following header lines:

To: allusers
From: allusers-submit
Errors-To: allusers-errors

The From: header allows reply mail to be submitted for distribution to the list. The Errors-To: header causes error notification to be sent to allusers-errors so that the maintainer can fix any errors in the list. The original sender also gets error notification unless the mailing list software represents the maintainer in the envelope (see Section 25.5.1, "Reply Versus Bounce").

Under SunOS and V8 sendmail the Errors-To: is flagged in conf.c with the H_ERRSTO header flag (see Section 35.5.11). This allows other headers to be declared in that file as error redirect headers. Under pre-V8 SunOS sendmail the Errors-To: header is ignored if the error mode set by the e option is m (see Section 34.8.24.2, "ErrorMode=m").

Under V8 sendmail the Errors-To: header is ignored unless the UseErrorsTo (l) option (see Section 34.8.74) is true. It does this because the Errors-To: header violates RFC1123. Errors-To: was needed only to take the place of the envelope sender in the days when most UNIX delivery agents couldn't differentiate between header and envelope.

The Errors-To: header should never be declared in the configuration file.

The From: header lists the address of the sender. There are only four legal forms that the field of this header can take:

From: address
From: <address>
From: Full Name <address>
From: address (comment)

A From: header must be declared in the configuration file, and its field is composed of the $x (see Section 31.10.42) and $g (see Section 31.10.16, $g) macros. For example,

H?F?From: $?x$x <$g>$|$g$.

$g contains the official return address of the sender. $x contains the full name for the sender. $x may be undefined for some addresses, so it should be wrapped in the $? and $. conditional operators (see Section 31.6).

The From: header must be prefixed by the ?F? flag because all the traditional delivery agents use the F=F flag (see Section 30.8.21, F=F) to force inclusion of that header. Use of the ?F? flag allows new delivery agents to be written that don't require the From: header. The resent- form of the From: header must also be declared in the configuration file:

H?F?Resent-From: $?x$x <$g>$|$g$.

This ensures that every mail message has a sender, even if the mail message has been forwarded.

Note that sendmail does not add the From: header or its resent- form if a From: header already exists in the header portion of the mail message. A possible exception occurs if the envelope sender is identical to the address in the From: header. In that instance, the From: header is discarded and a new one is created (see Section 35.7.1, "Remove and Recreate the From: Header").

The Full-Name: header is used to list the sender's full name if it is known. The field for this header may be arbitrary text but is usually the value in the $x macro (see Section 31.10.42):

H?x?Full-Name: $x
H?x?Full-Name: (User names hidden for security)

The Full-Name: header should be prefixed with the ?x? flag so that selected delivery agents may require inclusion of that header. This header definition is usually meaningless, because all traditional delivery agents omit the F=x flag. It can be useful, however, for mailing through sites that strip or destroy From: headers.

The Full-Name: header may be specified in the configuration file. If this header is already in the mail message, sendmail does not replace it. But note that V8 sendmail will remove the Full-Name: header if the F=x flag (see Section 30.8.44, F=x) is set for the recipient's delivery agent.

The In-Reply-To: header is used to identify previous correspondence that the current message is in reply to. This header is generated by MUAs, not by sendmail. The field for this header is arbitrary text with one restriction. If that text includes the message identifier, that identifier must be enclosed in angle brackets (< and >) and must adhere to the format for all message identifiers. Note that the message identifier should be included but is not required.

A typical use of the In-Reply-To: header might look like the following:

In-Reply-To: Your message of Fri, 13 Dec 1996 05:47:44 -0700
       The subject of which was: "Which came first?"
   
   whitespace

The In-Reply-To: header should never be declared in the configuration file.

The Keywords: header is used to list significant words from the body of the mail message that aid in the indexing of its contents. This header is never added by sendmail. Although some user mail-reading programs can create this header, it is usually created by Usenet news-posting programs.

The field for the Keywords: header is arbitrary text. This header should never be declared in the sendmail configuration file.

The Mail-From: header is not defined by any of the RFCs and is rarely seen in message headers. The sendmail program defines it internally as a synonym for the Received: header. The Mail-From: header is obsolete.

The Message-ID: header is used to uniquely identify each mail message. This header must be declared in the configuration file. The field for this header must be an expression in the form of a legal address enclosed in angle brackets (< and >). The address must be composed of elements that create an identifier that is truly unique worldwide. The Message-ID: header is declared in the configuration file:

?M?Message-Id: <$t.$i@$j>

Here, the field is an address of the form user@domain, which is enclosed in angle brackets. The $t macro (see Section 31.10.35, $t) is an integer representation of the current time to the nearest second. The $i macro (see Section 31.10.19, $i) is the unique queue identifier that is used to identify this message locally. The $j macro (see Section 31.10.20, $j) is the fully qualified domain name of the local host. The Message-ID: header as it might appear in an actual mail message would look like this:

Message-Id: <9207100411.AA14505@nic.cerf.net>

The Message-ID: header should be prefixed with a ?M? flag so that it is inserted only into headers of messages whose delivery agents have the F=M flag set. The standard delivery agents include this flag.

The resent- form of the Message-ID: header must also be declared in the configuration file:

?M?Resent-Message-Id: <$t.$i@$j>

This ensures that every mail message has a message identifier even if the message is forwarded.

Note that sendmail does not add a Message-ID: header or its Resent- form if a Message-ID: header already exists in the header portion of a mail message. Furthermore, the Resent- form is added only if sendmail determines that the message is a resent message.

Also note that you should never try to replace an existing Message-ID: header with one of your own. This could result in the loss of important information needed to trace the origin of a message.

The Message: header is used to mark an early end to a mail message's headers. When sendmail finds this header, it immediately stops gathering the message's header lines and treats the rest of the header as the start of the message body. This header is useful for including non-Internet headers in the header portion of a mail message. For example,

To: george@wash.dc.gov (George Washington)
Subject: Re: More text
Date: Tue, 04 Aug 92 14:14:56 -0400
Message-Id: <31842.AA01513@wash.dc.gov>
Received: by wash.dc.gov (4.1/1.12 $)
        id AA01513; Tue, 4 Aug 92 12:15:01 PDT
From: Ben Franklin <ben@philly.dc.gov>
Message:
ROUTED BY BITNET\/CO=US/ROUTE=INTERNET/
FORMAT OF MESSAGE /LANG=USENGLISH/FORM=PLAINTEXT/

Here, the last two header lines are non-Internet headers that may confuse some programs. But the Message: header that precedes them tells sendmail to treat them as message body, and problems are avoided.

Note that Message: is not defined by any RFC but is a convention that is shared by all versions of sendmail and most other MTAs. The Message: header should never be declared in the configuration file.

MIME (Multipurpose Internet Mail Extensions) is documented in RFC1521, with additional details in RFC1344, RFC1426, RFC1428, and RFC1437. The sendmail program cares about MIME only when bouncing messages and when determining how to convert the message body between 8 and 7 bits. If the SendMimeErrors (j) option (see Section 34.8.60, SendMimeErrors (j)) is set, V8 sendmail includes the following header in all returned (bounced) mail:

MIME-Version: 1.0

This is hard-coded into sendmail. See the SendMimeErrors (j) option for further details about this header.

The MIME-Version: header should never be declared in the configuration file.

The Posted-Date: header is used by some old Usenet news software and some mailing list software to indicate the date and time that a mail message was posted (submitted for distribution). The Date: header, on the other hand, shows when the message was mailed. In actual practice, the two usually show the same date and time.

When sendmail tries to determine the originating date of a mail message, it first looks for a Posted-Date: header. If one is found, it uses that date. Otherwise, it uses the date from the Date: header. Whichever is used, the result is stored into the $a macro (see Section 31.10.2).

The Posted-Date: header is not a part of the RFC822 standard, so it should not be declared in the sendmail configuration file.

The Precedence: header is used internally by sendmail to order the processing of messages in its queue. A full description of the possible field values for this header is given in Section 35.8.1, "The P Configuration Command". The effect of those values on ordering the queue is described in Section 23.5, "How the Queue Is Processed".

The Precedence: header should never be declared as an H line in the configuration file. However, P precedence lines should be declared in that file.

Mail messages may be placed into the queue either intentionally or because they could not be delivered immediately. Once they are in the queue, two time periods come into play. First is the period of time that the message should remain in the queue before a warning is issued to the sender. Second is the total period of time that the message should remain in the queue before it is bounced as a failed message.

Beginning with V8.7 sendmail, it is now possible to tailor these intervals on the basis of three distinct priorities of mail. The new Priority: header tells sendmail which priority a message possesses:

Priority: pri

Here, pri can have one of three possible values: urgent, normal, and non-urgent. These values correspond directly to the priorities specified by the Timeout.queuewarn option (see Section 34.8.70.15, "Timeout.queuewarn") and Timeout.queuereturn option (see Section 34.8.70.14, "Timeout.queuereturn"):

O Timeout.queuereturn.urgent=1d
O Timeout.queuereturn.normal=2d
O Timeout.queuereturn.non-urgent=4d

Here, a Priority: header of normal will cause the message containing it to bounce after it has remained in the queue for two days.

The Priority: header should never be declared in the configuration file.

The Received: header is used to record information about each and every site a mail message passes through on its way to ultimate delivery. First this header is inserted by the original sending site, then another is added by each site that the message passes through, including the site performing final delivery. Each new header is added to the top of the list of Received: headers, forming a chronological record (reading bottom up through the headers) of how the mail message was handled.

The contents of the Received: header's field is narrowly defined by RFC822. Its defined form looks like this:

Received: ["from" host] "by" host ["via" atom] ["with" atom]
       "id" string ["for" addr] ";" date
   
   whitespace

The field is composed of six items that may be split over multiple lines by using whitespace to indent the second. Items that are optional are enclosed in square brackets. Each item is composed of two parts a word (shown in quotation marks) and a value. All, or only the few required items, need to be present. When they are present, they must be in the following order:

from

Full canonical name of the sending host (if available)

by

Full canonical name of the receiving host (required)

via

Physical network that was used to transmit the message, such as INTERNET, JANET, or XNS (optional)

with

Protocol used to receive the message, such as SMTP (optional)

id

Unique queue identifier assigned by the local host (required)

for

Initial, untranslated address of the recipient (seldom used)

;date

Date this message was received (required)

The Received: header must be declared in the configuration file. It is a mandatory header, so it should never be prefixed with ?flags?. A typical declaration of this header would look like this:

HReceived: $?sfrom $s $.$?_($?s$|from $.$_) $.by $j ($v/$Z)$?r with $r$.
        id $i$?u for $u$.; $b

Here, seven items are included in the field:

$?from $s $.

If the $s macro contains a value, the word from and that value are inserted into the header. The $s macro (see Section 31.10.33, $s) contains the full canonical name of the sender's host.

$?_($?s$|from $.$_) $.

This is a nested conditional. If the $_ macro contains a value, the parentheses and all the information inside them are inserted into the header. If the $_ macro lacks a value, nothing is inserted into the header.

Inside the parentheses the value of $_ is inserted into the header. Another conditional expression determines if the $_ just inserted should also be prefixed with the word from. If the $s macro lacks a value the word from is inserted in front of the $_. The $_ macro contains the RFC1413 identd(8) identity of the connecting host and any IP routing information (see Section 31.10.1, $-).

by $j ($v/$Z)

The $j macro contains the full canonical name of the local host. The parentheses surround a comment that is formed from $v (see Section 31.10.38, $v), the version of the sendmail program, and $Z (see Section 31.10.47, $Z) the version of the configuration file.

$?r with $r$.

If the $r macro contains a value, the word with followed by the value of $r is inserted into the header. The $r macro (see Section 31.10.31, $r) contains a string that indicates the protocol used to receive the message (such as SMTP or ESMTP).

id $i

The $i macro contains the identifier created by sendmail to uniquely identify this mail message at this host (see Section 31.10.19).

$?u for $u$

If the $u macro contains a value, the word for followed by the value of $u is inserted into the header. The $u macro (see Section 31.10.36, $u) contains the recipient's username.

; $b

The $b macro contains the current date and time in RFC822 format (see Section 31.10.3, $b).

The Received: declaration shown above is the one typically used by most sites running V8 sendmail.

The References: header is used by mail-reading programs to include a reference to the original message in replies. Although this header may legally contain arbitrary text as its field, it usually contains a copy of the original Message-ID: header field.

The References: header typically looks something like this:

References: <9205041920.AA27932@wash.dc.gov>

Notice that the message identifier is wrapped in angle brackets, which cause it to look like an address.

The References: header should never be declared in the configuration file.

The Reply-To: header requests that replies to messages go to one or more addresses that are different from that of the original sender. This header is usually inserted by mailing-list software, where the From: is the address of the mailing list and the Reply-To: is the address of the list's maintainer.

The field for the Reply-To: header must obey the same rules as those for the From: header's field. One example of the use of this header might look like this:

From: mailinglist@list.server.com
Reply-To: mailinglist-request@list.server.com

The -request suffix is used by many mailing lists to specify the list maintainer.

The Reply-To: header should never be declared in the configuration file.

The Return-Path: header is intended to show the envelope address of the real sender as opposed to the sender used for replying (the From: and Reply-To: headers). In posting Usenet news, for example, the Return-Path: shows "news" and the From: shows the address of the posting user. But in general, Return-Path: should never be used for replying to mail. It is intended to be used solely for notification of delivery errors.

There must be only one Return-Path: header in any mail message, and it should be placed there by the site performing final delivery. This header should be declared in the configuration file like this:

H?P?Return-Path: <$g>

The ?P? flag ensures that only delivery agents that perform final delivery insert this header. Those delivery agents are usually prog and local, which usually contain an F=P delivery agent flag.

The $g macro (see Section 31.10.16) contains as its value the address of the sender relative to the recipient.

Unfortunately, two circumstances can cause the Return-Path: header to contain incorrect information. First, the message may arrive at your site with that header already there. If this happens, there is usually no way to get rid of it, because most versions of sendmail lack a conf.c H_ flag that means to replace an existing header. However, with V8 sendmail, defining H_ACHECK (see Section 35.5.16) in conf.c causes a header to be replaced even if one is already in the message.

The second problem stems from the fact that final delivery may not really be final. The local delivery agent program may be something like procmail(8), which allows mail to appear to be locally delivered, while also allowing users to run shell scripts that may forward their mail to another site.

To minimize these problems, always declare the Return-Path: header with the proper ?flags? in the configuration file. Doing this ensures that it will be inserted when legal and that the address your site places in it is usually correct.

he Return-Receipt-To: header causes sendmail to send a mail message back to the specified recipient confirming final delivery. It is no longer supported as of V8.7 sendmail (instead, see NOTIFY=SUCCESS in Section 36.7.28, -N). [4] If a pre-8.7 version of sendmail finds this header when it is processing mail for delivery, and if the selected delivery agent has the F=l flag set, sendmail creates a bounced mail message. The recipient is set to the person specified in the Return-Receipt-To: header, and the following subject header line is included:

[4] Return-Receipt-To: was a bad idea. It gave false information (such as the suggestion that a user who never reads mail accepted delivery). It can wrongly propagate (as, for example, when a mailing list gets the receipt instead of you). And it is insecure (a nasty person can use it to find "hidden" members of a mailing list).

Subject: Returned Mail: Return Receipt      prior to V8.7
Subject: Return Receipt                     starting with V8.7

The message appears to originate from the user defined by the $n macro (see Section 31.10.26, $n), and contains a copy of the original header as its body.

The Return-Receipt-To: header should never be declared in the configuration file and, in fact, should rarely be used at all. It is not intended as a routine delivery-verification mechanism but rather is intended for occasional use in debugging delivery problems. It is especially dangerous when used in outgoing mailing-list mail, because it can cause an avalanche of returned mail and can possibly bring a host to its knees. Beginning with V8.6 sendmail, a receipt is sent when the mailing list is first expanded, and the Return-Receipt-To: header is removed before forwarding the message to the list.

Beginning with V8.7 sendmail, processing of all Return-Receipt-To: headers can be skipped by specifying noreceipts with the PrivacyOptions (p) option (see Section 34.8.47, PrivacyOptions (p)).

The Sender: header is like the From: header. But whereas the From: header shows the address of one sender, the Sender: header shows the address of the real sender. For example, an assistant can mail a letter for the boss using the boss's account. The boss's address is in the From: header, and the assistant's address is in the Sender: header. The syntax for the two is identical. Newer MUAs allow the user to create a custom Sender: header. The Sender: header should never be declared in the configuration file.

The Subject: header can be included in mail messages to give the topic of the message. Most user mail-reading programs display the arbitrary text that forms the field of this header when listing received messages. Although such text can legally extend over multiple indented lines, most mail-reading programs recognize only the first such line:

Subject: About yesterday's meeting, I had some second
       thoughts about why the shape of the bonnet should
       remain so sharply curved at the ends.
   
   whitespace

This would be displayed by the mailx(1) program in truncated form as:

14   gw@wash.dc.gov Fri Aug  7 12:57  22/770 "About yesterday's meeting"

The Subject: header is not used by sendmail, but it is often wrongly (albeit harmlessly) included in the configuration file:

HSubject:             This actually does nothing

The Text: header is the same as the Message: header. Both cause all lines that follow in the header portion of a mail message to be treated as message body.

The Text: header should never be declared in the configuration file.

The To: header lists one or more of the recipients of the mail message. Other headers, such as Cc:, also list recipients.

The sendmail program attempts to deliver a copy of the mail message to every recipient address that it can find in all the recipient headers and in the envelope. If the header of a mail message lacks recipient information (To:, Cc:, and Bcc: header lines), pre-V8.7 sendmail added an Apparently-To: header line and put the recipient's address from the envelope into the field of that header. Beginning with V8.7, the way a recipientless message is handled is determined with the NoRecipientAction option (see Section 34.8.43).

The Via: header is not defined by RFC822 but occasionally appears in mail messages that sendmail needs to process. It is used by a few other networks to mark a mail message's transit through a forwarding host. It is an early, and now obsolete, version of the Received: header. The sendmail program counts the Via: header when determining the hop count but has no other use for it.

The Via: header should never be declared in the configuration file.

If the PrivacyOptions (p) option (see Section 34.8.47) 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 (see Section 22.8, "Security Features"). 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 (see Section 31.10.1) in Received: headers.

Processed from queue dir

A user other than root used the -oQ (or similar) switch (see Section 34.8.48, QueueDirectory (Q)) to process mail from a queue directory (dir) that was different from the one specified with the QueueDirectory (Q) 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 root privilege.

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; see Section 31.10.20), the DNS maps for that host are 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, instead, a MAIL command was first, this header is inserted in the incoming message. The most likely cause of a missing HELO is the mistake of someone attempting to carry on an SMTP conversation by hand.

The X400-Received: header is added by IDA sendmail to document receipt of a mail message from an X400 network. This header is used by both IDA and V8 to count the number of forwarding sites when computing the hop count of a mail message.

The X400-Received: should never be declared in the configuration file.