35.5 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
The flags that determine header use are listed in
Table 35.2
.
Note that each flag name is prefixed with an
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 (although you can trick sendmail with H_ACHECK see Section 35.5.16, "Replacing Headers with H_ACHECK" ). 35.5.1 H_EOHHeaders 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 RFC822-compliant header lines from headers created by a noncompliant network. 35.5.2 H_RCPT
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 35.5.3 H_DEFAULT
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 35.5.4 H_RESENT
The H_RESENT flag tells
sendmail
that the header line is prefixed
with the 35.5.5 H_CHECK
If a header definition in the configuration file begins with
a 35.5.6 H_ACHECK
The H_ACHECK flag marks a header that should normally be discarded unless
a delivery agent's 35.5.7 H_FORCEThe H_FORCE flag causes sendmail to always insert a header. It is used in the conf.c file with selected trace headers. It can be thought of as allowing duplicates. That is, the header will be inserted even if one like it is already present. 35.5.8 H_TRACEHeaders 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. 35.5.9 H_FROMHeaders 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. 35.5.10 H_VALIDThe 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 used in the conf.c file. 35.5.11 H_ERRSTO
The H_ERRSTO flag specifies which headers can be used
for returning error notification mail. Those headers take priority
over all others for that notification if the 35.5.12 H_CTEThe H_CTE flag specifies that a header is the MIME RFC1521 content transfer encoding header (see Section 35.10.8, Content-Transfer-Encoding: ). 35.5.13 H_CTYPEThe H_CTYPE flag specifies that a header is a MIME RFC1521 content-type header (see Section 35.10.9, Content-Type: ). 35.5.14 H_BCC
The H_BCC flag indicates that a header is either
a 35.5.15 H_ENCODABLEThe H_ENCODABLE flag tells sendmail that the field part may be encoded in the way described in RFC1522. As of V8.8, this flag is unsupported in code. 35.5.16 Replacing Headers with H_ACHECK
Some MUAs tend to insert their own
To delete the bogus
"message-id", 0, "message-id", H_ACHECK, change to this
Here, we changed the | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|