Not all MTAs are as RFC822-compliant as sendmail.
Occasionally, headers appear that were legal under the
defunct RFC733. The In-Reply-To:
header (see Section 35.10.16),
for example, used to be a comma-separated list of addresses under RFC733
and may cause problems. Note also that
RFC733 date and time syntax differs from that of RFC822 and RFC1123.
Prior to V8 sendmail,
if the name
part of a header definition was missing (the H
was followed by a colon), a header whose name is the character value
zero was silently accepted and wrongly propagated.
Prior to V8 sendmail,
long header lines in messages (such as To:
with many
recipients listed) could cause the internal buffer used by sendmail
to overflow. The size of that buffer was defined in conf.h
as MAXLINE and was 1024 characters. The IDA version defined it as
2048 characters. V8 sendmail dynamically allocates memory
and so can handle headers of any size.
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 (see Section 35.5.2) in conf.c is ignored. V8.7 sendmail will produce an Apparently-To:
header only if the NoRecipientAction
option is set to add-apparently-to.
Prior to V8.7 the sendmail program's handling of unbalanced special characters could lead to an explosion of error mail. Instead of simply bouncing the offending mail message, it both returned an error message and forwarded the message to the recipient. If the message was being exploded through a series of mailing lists, the error messages continued to increase, possibly drowning the original site with mail.
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.