>> 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 _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
