On Mon, 5 Mar 2001, Glenn A. Malling wrote:

+ [log in to unmask] said:
+
+ > 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.
+
+ I think RFC822 says:
+
+ 1) Quoted strings (qtext) may be folded.  See Appendix D

Yes. Folding within quoted strings is permitted. But see below.

+ 2) There is no syntactic difference between a single linear-white-space
+    character and multiple contiguous linear-white-space characters in
+    structured field bodies.  See Section 3.4.2

This is a bit ambiguous in RFC 822. And in a way still ambiguous (without
carefull reading) in RFC822bis (waiting to become an RFC "real soon now").

+ If so, the MUAs having trouble with folded boundary strings are broken.

Depends. Although RFC822 is currently still "the standard" the folding is
one of those things that needed a clean up. The problem here is:

1) How and where to fold ?

In RFC822bis folding is more or less restricted to putting a CRLF in front
of a 'whitespace-char', so just a CRLF is inserted, no extra spaces or
tabs to make a nicely formatted header (which seems to be the problem in
this case). Furthermore it is recommended to do so only between
syntactical elements, i.e. not within for example quoted strings used in
parameters for things like Content-Type: etc., just to prevent problems
like above.

2) How to unfold ?

Basically, just remove the CRLF. Compression of multiple LWSP is permitted
where the LWSP is not "meaningfull". Within a quoted string or
in a 'free text' (unstructured) header field, chances are that the
multiple spaces are meaningfull so a MUA that leaves the extra spaces as
they are is probably doing the right thing. It has no way to know whether
the extra spaces are significant or not.

Anyway, we used to have an MTA that folded 'the wrong way' (i.e. within
quoted strings (allowed) and putting lots of extra whitespace to line up
the folded lines (dangerous and as I understand it not allowed)). This
completely broke many messages with boundary parameters containing a space
character. Needless to say that the vendor eventually fixed it by
restricting the folding to occur only 'between syntactical elements',
never had the problem again ;-)

Please note that the above is just my understanding of the RFC's involved
(and the many discussions on this matter). I could of course be completely
wrong.

Now finding the culprit is another story but Ben already addressed that
one.

Cheers,

Xander