I received this report from a tech support person helping one of
our administrators with posting problems.  When he says 'the listserver',
I'm not sure we can rule out other agents on the way in, but since the
wrapping appears in the list archives, I think we can rule out listserv's
outgoing SMTP server (LSMTP).

Has anyone seen this problem, and if so, know of anything we could tweak
in the list setttings to avoid it?  Or perhaps the true culprit?

Thanks,
Jean Snow

Problem Summary
---------------
If the "Content-Type:" mail header in an incoming mail message is longer
than 80 characters, the listserver (or the SMTP server used by the
listserver) wraps and indents the header onto multiple lines before
distributing the message.  If the wrap (newline) and indent (space)
characters are inserted within the "Boundary=" parameter of the header,
some mail user agents are unable to locate and differentiate attachments
in the body of the mail message.

Examples
--------
This header line is 80 characters long and will not be wrapped by the listserver:
Content-Type: multipart/mixed; Boundary="--=_Friday, February 15, 2001
11:57 AM"

This header line is 81 characters long and *will* be wrapped by the listserver:
Content-Type: multipart/mixed; Boundary="--=_Tuesday, February 15, 2001
11:57 AM"

The listserver wraps the 81 character header into two lines by adding a
newline character and 14 space characters.  The header looks like this
when it exits:
Content-Type: multipart/mixed; Boundary="--=_Tuesday, February 15,
              2001 11:57 AM"

What the user sees
------------------
The alteration of the contents "Boundary=" parameter causes problems
with Eudora 4.3x and Netscape Messenger 4.7x mail clients.  In our tests
both clients present the user with only the message headers, and display
no body or attachment at all.

Reference
---------
RFC822 describes the standard format for text messages, including header
fields and header field bodies.  It also describes the standards for
"folding" (splitting) and "unfolding" headers.  If the "Boundary="
parameter is understood as a "structured field body", as described in
that RFC, then the question may come down to whether it is proper to add
multiple white space characters to that field body when folding the
header.
--