Some header lines need to be declared in the configuration
file by using the
H command. Others are created internally by
sendmail. Still others are created by mail MUAs.
These differences are described individually with each
The following discussion of header names is in alphabetical order.
The unknown sender(Smail)
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.
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.
Apparently-From:header should never be declared in the configuration file and should not be added to conf.c.
When the message lacks a recipient(sendmail)
If the header of a mail message lacks recipient information (lacks all of the
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
NoRecipientActionoption (see Section 34.8.43).
Apparently-To:header name is not defined in RFC822. It is added by pre-8.7 sendmail because RFC822 requires at least one
Cc:header, and neither is present.
Apparently-To:header should never be defined in the configuration file.
Why the bounce(sendmail)
Auto-Submitted: auto-generated (reason)
The reason can be one of four things: It can be
warning-timeoutif the message has reached its
Timeout.queuewarnoption threshold (see Section 34.8.70, Timeout (r)). It can be
postmaster-warningif 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-receiptif 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
failurefor 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
Mline (see Section 23.9.9, M line).
Auto-Submitted:header should never be defined in the configuration file.
Blind carbon copy(RFC822)
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
Cc:lines. When there are multiple blind carbon copy recipients, knowledge of each other is also hidden.
When run with a
-tcommand-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
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.
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.
Cc:header should never be declared in the configuration file.
The field for the
Cc:header must contain one or more properly formed addresses.
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
Comments:header should rarely be declared in the configuration file. If it is, it should be prefixed with appropriate
?. 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
localdelivery agent, because that delivery agent is the only one to include the
F=Bflag:Mlocal, P=/bin/mail, F=rlsDFMmnP
B, 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 size of the body of the message(System V Release 4)
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
-d80debugging switch (see Section 37.5.190, -d80.1). All other versions of sendmail ignore this header.
Auxiliary MIME encoding used in the message(RFC1521)
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:
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).
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 nature of the body of the message(RFC1521)
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
DefaultCharSetoption (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 origin date(RFC822)
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
$amacro (see Section 31.10.2, $a) is mandatory in the field for this header. The value in
$ais the current time in RFC822 format. (See Section 5.1 in RFC822 and Section 5.2.14 in RFC1123.) Only the
$amacro 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.
?D?flag is always included with the
Date:declaration in the configuration file. All the standard delivery agents always include a
F=Dflag (see Section 30.8.17, F=D). The
?D?allows custom delivery agents to be designed that do not need a
Mark a mailing list expansion(qmail)
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:
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:
Delivered-To:header should never be declared in the configuration file.
Message is transformed(RFC822)
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
The field contains one mandatory item, the
prog, and one optional item, the
progis the name of the program that was used to transform the message body. The optional
keyis 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.
Encrypted:header should never be declared in the configuration file.
Error notification redirect(sendmail)
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
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-errorsso 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
m(see Section 22.214.171.124, "ErrorMode=m").
Under V8 sendmail the
Errors-To:header is ignored unless the
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.
Errors-To:header should never be declared in the configuration file.
From: address From: <address> From: Full Name <address> From: address (comment)H?F?From: $?x$x <$g>$|$g$.
$gcontains the official return address of the sender.
$xcontains the full name for the sender.
$xmay be undefined for some addresses, so it should be wrapped in the
$.conditional operators (see Section 31.6).
From:header must be prefixed by the
?F?flag because all the traditional delivery agents use the
F=Fflag (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
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 sender's full name(sendmail)
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
$xmacro (see Section 31.10.42):H?x?Full-Name: $x H?x?Full-Name: (User names hidden for security)
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=xflag. It can be useful, however, for mailing through sites that strip or destroy
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=xflag (see Section 30.8.44, F=x) is set for the recipient's delivery agent.
Identify previous correspondence(RFC822)
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 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
In-Reply-To:header should never be declared in the configuration file.
Index to contents(RFC822)
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.
Synonym for Received:(obsolete)
Unique identifier for message(RFC822)
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 (
>). 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
$tmacro (see Section 31.10.35, $t) is an integer representation of the current time to the nearest second. The
$imacro (see Section 31.10.19, $i) is the unique queue identifier that is used to identify this message locally. The
$jmacro (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>
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=Mflag set. The standard delivery agents include this flag.
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.
Marks end of headers(sendmail)
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: firstname.lastname@example.org (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 <email@example.com> 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.
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.
Notify that error return contains MIME support(RFC1521)
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
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
j) option for further details about this header.
MIME-Version:header should never be declared in the configuration file.
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
$amacro (see Section 31.10.2).
Posted-Date:header is not a part of the RFC822 standard, so it should not be declared in the sendmail configuration file.
Set ordering in queue(sendmail)
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".
Precedence:header should never be declared as an
Hline in the configuration file. However,
Pprecedence lines should be declared in that file.
Determine timeouts in the queue(sendmail)
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:
prican have one of three possible values:
non-urgent. These values correspond directly to the priorities specified by the
Timeout.queuewarnoption (see Section 126.96.36.199, "Timeout.queuewarn") and
Timeout.queuereturnoption (see Section 188.8.131.52, "Timeout.queuereturn"):O Timeout.queuereturn.urgent=1d O Timeout.queuereturn.normal=2d O Timeout.queuereturn.non-urgent=4d
normalwill cause the message containing it to bounce after it has remained in the queue for two days.
Priority:header should never be declared in the configuration file.
Trace routing of mail(RFC822)
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:
Full canonical name of the sending host (if available)
Full canonical name of the receiving host (required)
Physical network that was used to transmit the message, such as INTERNET, JANET, or XNS (optional)
Protocol used to receive the message, such as SMTP (optional)
Unique queue identifier assigned by the local host (required)
Initial, untranslated address of the recipient (seldom used)
Date this message was received (required)
Received:header must be declared in the configuration file. It is a mandatory header, so it should never be prefixed with
?. 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 $.
$smacro contains a value, the word
fromand that value are inserted into the header. The
$smacro (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
$smacro lacks a value the word
fromis inserted in front of 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)
$jmacro 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$.
$rmacro contains a value, the word
withfollowed by the value of
$ris inserted into the header. The
$rmacro (see Section 31.10.31, $r) contains a string that indicates the protocol used to receive the message (such as SMTP or ESMTP).
$imacro contains the identifier created by sendmail to uniquely identify this mail message at this host (see Section 31.10.19).
$?u for $u$
$umacro contains a value, the word
forfollowed by the value of
$uis inserted into the header. The
$umacro (see Section 31.10.36, $u) contains the recipient's username.
$bmacro contains the current date and time in RFC822 format (see Section 31.10.3, $b).
Received:declaration shown above is the one typically used by most sites running V8 sendmail.
Reference to original message(RFC822)
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
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.
References:header should never be declared in the configuration file.
Alternative reply address(RFC822)
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: firstname.lastname@example.org Reply-To: email@example.com
-requestsuffix is used by many mailing lists to specify the list maintainer.
Reply-To:header should never be declared in the configuration file.
Return address of sender(RFC822)
Return-Path:header is intended to show the envelope address of the real sender as opposed to the sender used for replying (the
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>
?P?flag ensures that only delivery agents that perform final delivery insert this header. Those delivery agents are usually
local, which usually contain an
F=Pdelivery agent flag.
$gmacro (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
localdelivery 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
?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.
Verify delivery(sendmail prior to V8.7)
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).  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=lflag 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:
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
$nmacro (see Section 31.10.26, $n), and contains a copy of the original header as its body.
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
p) option (see Section 34.8.47, PrivacyOptions (p)).
The real sender(RFC822)
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 should never be declared in the configuration file.
Topic of the message(RFC822)
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 firstname.lastname@example.org Fri Aug 7 12:57 22/770 "About yesterday's meeting"
Subject:header is not used by sendmail, but it is often wrongly (albeit harmlessly) included in the configuration file:HSubject: This actually does nothing
A synonym for Message:(sendmail)
The primary recipients(RFC822)
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 (
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
NoRecipientActionoption (see Section 34.8.43).
An unofficial trace header(obsolete)
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.
Via:header should never be declared in the configuration file.
Notification of security matters(V8 sendmail)
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
hostis the canonical name of the host that inserted this header. The
messageis one of the following:
- Processed by user with
An attempt was made by a user other than root to run sendmail with the
-Ccommand-line switch. That switch caused sendmail to read file in place of the system sendmail.cf file.
- user set sender to other using
A user or program's user identity used the
-fcommand-line switch to change the identity of the sender to other (and user was not listed with the
Tconfiguration 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
A user or program's user identity used the
-bscommand-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
Tconfiguration 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
- 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
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.
Received via X400(X400)
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.
X400-Received:should never be declared in the configuration file.