Re: [Nmh-workers] 2 little issues

[Ken Hornstein]

>> Hm, I cannot reproduce this here, but are you displaying a message where
>> the text part has no blank line between it and the multipart separator?
>> That's allowed, I'm just trying to understand the problem.
>
>Yes, exactly:
>
>       (headers)
>       MIME-Version: 1.0
>       Content-Type: multipart/mixed;
>        boundary="=_foo"
>       [...]
>
>       --=_foo
>       Content-Transfer-Encoding: 8bit
>       Content-Type: text/plain; charset=ISO-8859-1
>
>       Message body
>
>       [...]
>
>       Last line of message body
>       --=_foo

Okay, so I finally tracked this down, and I'm not sure what the right solution
should be.

Our MIME parser routines explicitly eat the newline before boundary
delimiter.  We also make sure there's always a blank line between a MIME
part and the next boundary delimiter when generating MIME content.  I
thought that was just aesthetics, but it turns out we've doing it right.
>From RFC 2046, §5.1.1:

   The boundary delimiter MUST occur at the beginning of a line, i.e.,
   following a CRLF, and the initial CRLF is considered to be attached
   to the boundary delimiter line rather than part of the preceding
   part.  The boundary may be followed by zero or more characters of
   linear whitespace. It is then terminated by either another CRLF and
   the header fields for the next part, or by two CRLFs, in which case
   there are no header fields for the next part.  If no Content-Type
   field is present it is assumed to be "message/rfc822" in a
   "multipart/digest" and "text/plain" otherwise.

   NOTE:  The CRLF preceding the boundary delimiter line is conceptually
   attached to the boundary so that it is possible to have a part that
   does not end with a CRLF (line  break).  Body parts that must be
   considered to end with line breaks, therefore, must have two CRLFs
   preceding the boundary delimiter line, the first of which is part of
   the preceding body part, and the second of which is part of the
   encapsulation boundary.

So the text you describe that is right up against the boundary delimiter
is actually, according to the MIME standards, not ending with a CRLF
(which gets translated as a LF for us on Unix).  So yes, we're just
displaying the MIME part marker not on a new line, because that's
how the original text/plain part is set up.

I am unclear as to the right solution.  Obviously adjusting the MIME
parsing routines is wrong.  Making sure that the last character of
text/plain parts on output contains a newline might be better, but I'm
not sure that's technically right either.  Saying that we're displaying
the content as the message intended (doing nothing) is the easiest
solution, but somehow that feels unsatisfying.  I welcome suggestions.

--Ken