25.11 Pitfalls

• Not all MTAs are as RFC2822-compliant as sendmail. Occasionally, headers appear that were legal under the long-time defunct RFC733. The In-Reply-To: header (In-Reply-To:), for example, used to be a comma-separated list of addresses under RFC733 and can cause problems. Note also that RFC733 date and time syntax differs from that of RFC2822 and RFC1123.

• When generating an Apparently-To: header, sendmail checks for the absence of only the To:, Cc:, Bcc:, and Apparently-To: headers. The H_RCPT flag (Section 25.6.13) in conf.c is ignored. V8.7 and later sendmail will produce an Apparently-To: header only if the NoRecipientAction option is set to add-apparently-to.

• Precedence values are stored in integer variables, so care should be exercised on 2-byte integer machines to avoid having priorities wrap unexpectedly.

• Macros are not expanded in the P command. That is, expressions such as $U do not have the desired effect. The literal text $U is wrongly listed as the name or the value.

• The $={persistentMacros} class should not be used without first researching the macros to be included in that class. The sendmail program can be harmed by including an improper macro in that class because that macro's value will survive queue runs. This creates a danger in the use of the H?${macro}? header expression. The only way to use a sendmail program's internal macro in that expression is by also including that macro in the $={persistentMacros} class. If a macro is not in that class, its value will not survive queueing, and the included header might not appear when delivered from the queue.