Inline we go.. On Mon, 2004-04-26 at 17:26, Aaron Stone wrote: > 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?
I don't think that's ok.. I'm not sure though\ > 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%. I'll do a release of 2.0rc5 tomorrow. :) Ilja
