Query for finding nul's:
select replace(messageblk, "\0", "<null>")
from messageblks
where physmessage_id = 'suspect id here'
Query for fixing nul's:
update messageblks
set messageblk = replace(messageblk, "\0", "")
where physmessage_id = 'problem id here'
Indeed, the message that was confounding me had a pile of nul characters and
other unprintable crap at the end. db_start_msg() reads a singlepart message
until either the end of the buffer or until the stopbound is found. Unless
otherwise specified by the MIME headers, stopbound will be nul and thus the
message output will be truncated at the first nul.
This means that we are thoroughly incompatible with any email containing nul
characters that are not inside of a MIME part. Is that OK? RFC 2822 anyone?
My guess is that the pile of unprintable crap (like thirty nul's and a bunch
of control characters) is due to the buffers not being cleared, which Ilja has
already taken care of. The particular email I was looking at was inserted a
while ago, using either 2.0-rc3 or 2.0-rc4. The changes that should take care
of this problem have been made since 2.0-rc4, so we should be alright.
I can't remember what else was left to fix besides the LMTP error messages.
I'll work on those this week. Ilja, I suggest that we should do a 2.0-rc5, as
I'm not 100% confident that we've gotten everything working 100%.
Aaron
""Aaron Stone"" <[EMAIL PROTECTED]> said:
>
>
> 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
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
