Well, it looks like the nul character theories were all red herrings (for this
bug at least) and that the problem was not in rfcmsg.c but in mime.c. Looking
into why the MIME headers that follow right after a MIME boundary were not
being recognized, I finally took a look into mime.c. In mime_readheader(), we
have this chunk of code right at the top:
if (blkdata[0] == '\n') {
trace(TRACE_DEBUG,
"mime_readheader(): found an empty header\n");
(*blkidx)++; /* skip \n */
return 1; /* found 1 newline */
}
Note that if the message was delivered without \r's and only \n's, that's
exactly what's going to be the first character immediately following the MIME
boundary! Commenting this block out, MIME things start working again :-)
Ilja, do you know of a specific purpose for this check?
Will simply removing it cause more problems elsewhere?
We're not totally out of the woods yet. I have a couple of messages sent from
MS-Outlook in a weird multipart/mixed format that causes the parser to
recognize only the first part and then bomb out. I'm looking into that now...
Aaron
