#181 ns_sendmail should encode subject if it contains non-ASCII

[Tilmann Singer]

When sending mail with non-ASCII characters in the
subject, it is the responsibility of the MUA (aolserver) to
encode the subject accordingly. Aolserver's ns_sendmail
currenly sends out the mail with non-ASCII characters in
the subject without encoding.

I got this bounce message from a MTA who did not accept
the mail generated by aolserver:

Non-encoded 8-bit data (char E4 hex) in message header
'Subject'
Subject: Passwort ge\344ndert\n
^

This nondelivery report was generated by the
amavisd-new program
at host mail2. Our internal reference code for your
message
is 23623-01-57.

WHAT IS AN INVALID CHARACTER IN MAIL HEADER?

The RFC 2822 standard specifies rules for forming internet
messages.
It does not allow the use of characters with codes above
127 to be used
directly (non-encoded) in mail header (it also prohibits
NUL and bare CR).

If characters (e.g. with diacritics) from ISO Latin or other
alphabets
need to be included in the header, these characters need
to be properly
encoded according to RFC 2047. This encoding is often
done transparently
by mail reader (MUA), but if automatic encoding is not
available (e.g.
by some older MUA) it is the user's responsibility to avoid
the use
of such characters in mail header, or to encode them
manually. Typically
the offending header fields in this category are 'Subject',
'Organization',
and comment fields in e-mail addresses of the 'From', 'To'
and 'Cc'.

Sometimes such invalid header fields are inserted
automatically
by some MUA, MTA, content checker, or other mail
handling service.
If this is the case, that service needs to be fixed or
properly configured.
Typically the offending header fields in this category are
'Date',
'Received', 'X-Mailer', 'X-Priority', 'X-Scanned', etc.

If you don't know how to fix or avoid the problem, please
report it
to _your_ postmaster or system manager.