The H (header) configuration file command
specifies headers that are required for inclusion in the header
portion of mail messages. Some headers, such as
Date:, are added only if one is not already
present. Others, such as Received:
(§25.12.29[3ed]), are added
even if one or more are already present.
One major and three minor changes have been made regarding the handling of headers under V8.13:
The
$>+operator no longer balances special characters (Section 25.1.1 [V8.13]).The
Message-Id: (§25.12.23[3ed]) header’s value is now stored in the new${msg_id}macro (Section 21.1.5 [V8.13]).The
Delivery-Receipt-To: header used by SIMS (Sun Internet Mail System), is treated the same as aReturn-Receipt-To: header (§25.12.33[3ed]). That is,sendmailnow converts it to a DSN reply.The
confMESSAGEID_HEADERmcmacro has been added, which allows you to define a differentMessage-Id: header value (Section 25.1.2 [V8.13]).
Recall (§25.5[3ed]) that header values
can be passed to rule sets using the
$> and $>+ operators:
Hname: $>rule setHname: $>+rule setdon't strip comments
Prior to V8.13, the $>+ operator caused a
header’s value to be passed to the specified rule
set with RFC2882 comments intact:
text (comments) <address> commment
Also, prior to V8.13, the $>+ operator checked
for special balancing characters and performed a correction when they
were not found. For example, if a Subject:
header’s value arrived like this:
Subject: ----> test <----
The $>+ operator would cause it to be corrected
to the following:[41]
Subject: <----> test ----
The $>+ operator would then cause the result to
be passed to the appropriate rule set. But if a rule set was designed
to detect the first form (the ---> test), it
would fail because it would actually receive the second form.
Beginning with V8.13 sendmail, however, the
$>+ operator now no longer tries to balance
special characters. And because header values are passed to rule sets
as is, rule set header-checking is now more accurate, and useless
warnings about unbalanced characters have been eliminated.
The characters that used to be special (and that needed to balanced) are shown in Table 25-1.
See also (Section 18.1.1 [V8.13]) for a discussion of rules and how they, too, no longer need to balance.
V8.13 has introduced a new mc macro
that
makes it possible to define a new value for the
Message-Id: header:
define(`confMESSAGEID_HEADER´, `newvalue´)The default for the Message-Id: header
(§25.12.23[3ed]) looks like
this:
<$t.$i@$j>
Here, the default provides an address of the form
identifier@domain, which is enclosed in
angle brackets. The $t macro
(§21.9.86[3ed]) is an integer
representation of the current time to the nearest minute, in the
format YYYYMMDDhhmm. The
$i macro
(§21.9.49[3ed]) is the unique
queue identifier that is used to identify this message locally. The
$j macro
(§21.9.56[3ed]) is the fully
qualified domain name of the local host.
We recommend that if you change Message-Id:
header’s value from this default, you maintain the
format identifier@domain because that
format is required by RFC2821, and because some sites will reject the
message if it is not in that format.