When I ran into these problems with mail merge jobs, I found it was due
to the email client of the person sending the mail merge job.

Outlook Express, in our case. We set it to wrap lines at 132 characters
(its maximum) to minimize the impact on mail merge jobs. For jobs with
lines longer than that I send them as a text file from unix.

Do you think this applies to your situation?

Best,
Al Iverson

Jean Snow wrote:
>
> 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.
> --

--
Al Iverson -- [log in to unmask] -- Minneapolis, Minnesota
Support Jazz in Minnesota! -- http://www.mnjazz.com/
All opinions are mine alone unless I state otherwise.