25.6 Header Behavior in conf.c

The sendmail program has a built-in understanding of many header names. How those names are used is determined by a set of flags in the source file conf.c supplied with the source distribution. Site policy determines which flags are applied to which headers, but in general, conf.c applies them in the way that is best suited for almost all Internet sites. If you desire to redefine the flags for a particular header name, look for the name's declaration in the C-language structure definition HdrInfo in conf.c. Be sure to read the comments in that file. Changes to header flags represent a permanent site policy change and should not be undertaken lightly. (We illustrate this process after explaining the flags.)

The flags that determine header use are listed in Table 25-3. Note that each flag name is prefixed with an H_.

Note that there is no flag that always causes a particular header to be removed, nor is there a flag that always causes a particular header to be replaced (but see Section 25.6.1.1 for one way around this limitation).

25.6.1 H_ACHECK Header Flag (V5 and above)

The H_ACHECK flag marks a header that should normally be discarded unless a delivery agent's F= flag calls for its inclusion. It is usually set for the Bcc: header, which is discarded for the privacy of a blind carbon copy list, and the Full-Name: header, which is intended as a way for a user to add a full name (see the $x macro, $x) when there is no full name defined in the passwd(5) file. Note that H_ACHECK, when combined with bogus ?flags? of a header configuration file declaration, can cause appropriate headers to always be deleted or replaced. Also note that under V8 sendmail the H_ACHECK flag alone always causes a header to be replaced.

25.6.1.1 Replace headers with H_ACHECK

Some MUAs tend to insert their own Message-ID: header (Message-ID:). This can cause difficulty when tracing email problems because those MUA headers lack the sendmail queue identifier. At sites that have a central mail hub machine, where client machines forward all mail to the hub, you can solve this problem by redefining Message-ID: in conf.c on the clients, to delete the bogus Message-ID:, so that a good one can be generated on the hub:

"message-id",           0,
"message-id",           H_ACHECK,    change to this

Here, we changed the 0 flag for the Message-ID: header into an H_ACHECK flag. We do this only on the client machine versions of sendmail but not on the hub. The Message-ID: header will then be stripped from every outgoing message on every client machine and a new one will be created (if missing) on the hub.

By default, only the Full-Name:, Return-Path:, and Content-Length: headers have this flag defined. The Message-ID: header does not have this flag defined by default because the Message-ID: values are logged. By removing and regenerating Message-ID: headers, you lose the ability to track any given message on the local machine and the hub using a common Message-ID: value.^[6]

^[6] Some mail-sending programs also use Message-ID: headers of their own design to track messages.

25.6.2 H_BCC Header Flag (V8.7 and above)

The H_BCC flag indicates that a header is either a Bcc: (Bcc:) or a Resent-Bcc: header. The disposition of those headers is covered under the NoRecipientAction option (NoRecipientAction).

25.6.3 H_BINDLATE Header Flag (V8.10 and above)

Ordinarily, header fields that contain sendmail macros have those macros expanded (their values inserted) when the header is first processed. Some headers, such as the Return-Path: header, should not have sendmail macros in their field expanded until just before final delivery. Such headers can have the initial macro expansion skipped by specifying this H_BINDLATE header flag.

25.6.4 H_CHECK Header Flag (V5 and above)

If a header definition in the configuration file begins with a ?flags? conditional, this flag is set for that header. It tells sendmail to insert this header only if one of its ?flags? corresponds to one of the delivery agent's F= flags (Section 25.4). This flag must never be specified in conf.c—it is set automatically when sendmail reads H lines with ?flags? header flags.

25.6.5 H_CTE Header Flag (V8.7 and above)

The H_CTE flag specifies that a header is the MIME RFC2045 content transfer encoding header (Content-Transfer-Encoding:).

25.6.6 H_CTYPE Header Flag (V8.7 and above)

The H_CTYPE flag specifies that a header is a MIME RFC2045 content-type header (Content-Type:).

25.6.7 H_DEFAULT Header Flag (V5 and above)

The sendmail program automatically sets the H_DEFAULT flag for all headers declared in the configuration file. This flag tells sendmail to macro-expand the header just before it is used. Only one of each header that is marked with this flag is allowed to exist in the headers portion of a mail message. If such a header already exists, sendmail does not add another. The H_FORCE and H_TRACE flags override this flag in that regard. This flag must never be specified in conf.c—it is set automatically by the H configuration command (Section 25.1).

25.6.8 H_ENCODABLE Header Flag (V8.8 and above)

The H_ENCODABLE flag tells sendmail that the field part can be encoded in the way described in RFC2047. As of V8.10, this flag is defined for the Comment: and Subject: headers. Prior to that it was defined for no headers.

25.6.9 H_EOH Header Flag (V5 and above)

Headers that are marked with the H_EOH flag cause sendmail to immediately stop all header processing and treat the rest of the header lines as message body. This is useful for separating RFC2822-compliant header lines from headers created by a noncompliant network.

25.6.10 H_ERRORSTO (Was H_ERRSTO) (V8.7 and above)

The H_ERRSTO (V6 and earlier) and H_ERRORSTO (V7 and above) flags specify which headers can be used for returning error notification mail. Those headers take priority over all others for that notification if the UseErrorsTo option is true (UseErrorsTo).

25.6.11 H_FORCE Header Flag (V5 and above)

The H_FORCE flag causes sendmail to always insert a header. It is used in the conf.c file with selected trace and X-Authentication-Warning: headers. It can be thought of as allowing duplicates. That is, the header will be inserted even if one like it is already present.

25.6.12 H_FROM Header Flag (V5 and above)

Headers that are marked with the H_FROM flag are assumed to contain a valid sender address. This flag is intended for use in the conf.c file.

25.6.13 H_RCPT Header Flag (V5 and above)

Headers that are marked with the H_RCPT flag are assumed to contain valid recipient addresses in their fields. Only headers with this flag can lead to message delivery. These addresses will be rewritten. These headers are used to determine the recipient address only if the -t command-line switch (-t) is used.

25.6.14 H_RECEIPTTO Header Flag (V8.7 and above)

Some headers contain information about to whom a return-receipt should be sent. Return notification is triggered by NOTIFY=SUCCESS extension to the RCPT TO: command. If the PrivacyOptions option's noreceipts (See this section) keyword is specified, no success return notification will be sent. Beginning with V8.10, if the RrtImpliesDsn option is set, the presence of any header with H_RECEIPTTO set will cause sendmail to act as if NOTIFY=SUCCESS was specified, even if it was not.

Prior to V8.10, no headers had this flag set. For V8.10 and above, the only header that has this flag set is the Return-Receipt-to: header (Return-Receipt-To:).

25.6.15 H_RESENT Header Flag (V5 and above)

The H_RESENT flag tells sendmail that the header line is prefixed with the resent- string. Only headers that are marked with this flag can tell sendmail that this is a "forwarded" message. If no "forwarded" headers are found, sendmail strips any bogus resent- header lines from the message's header.

25.6.16 H_STRIPCOMM Header Flag (V8.10 and above)

The $> operator with header definitions causes the RFC2822 commentary to be removed from the field before it is passed to a rule set. The $>+ operator with header definitions causes the RFC2822 commentary to be retained. This flag is set to tell sendmail how to handle that commentary. It is not set by default for any header, but is set based on the presence of the + with the $> for header rule sets. You should never define this in conf.c.

25.6.17 H_TRACE Header Flag (V5 and above)

Headers that are marked with the H_TRACE flag are counted in determining a mail message's "hop" count. This flag is intended for use in the conf.c file. By default only the Received:, X400-Received:, Via, and Mail-From: headers have this flag defined.

25.6.18 H_USER Header Flag (V8.11 and above)

Certain headers are set by the submitting user, such as Subject:, while others can be added by sendmail, such as Message-Id:. Those that were supplied in the submitted message are marked with this flag so that sendmail can differentiate them from headers it generated itself.

No headers have this flag defined by default, and you should never define it in conf.c.

25.6.19 H_VALID Header Flag (V5 and above)

The H_VALID flag is set and cleared internally by sendmail to indicate to itself that a particular header line has been correctly processed and can now be used as is. This flag should never be set in the conf.c file.