One of the recent 1.0 commits relating to CRLF handling (maybe 2006-06-24) has changed the behaviour of APPEND when using mbox files with ordinary plain text emails.
When a client stores a new message using an APPEND command (eg. saving a draft or copy of a sent message), it uses CRLF consistently as a line-ending throughout the literal data block over the wire - both for the header and the body. At least, this is what both Pine and Thunderbird do, so I suspect it's correct according to the IMAP specs, though perhaps there are grey areas around 8bit messages with no transfer-encoding. When Dovecot stores the message in the mbox file, it *used* to convert all the CRLFs to LF. Since the change, it is still converting the CRLFs in the header, but is leaving them intact in the body. The result is a weird hybrid format within the file.
FETCH seems to undo the damage - at least, it sends back data with CRLF in both the header and the body - so provided the only access to the mail-store is through Dovecot, the clients are none the wiser. Dovecot also seems to handle existing messages (stored with LF only) OK too, and doesn't seem to be re-encoding them on update (eg. status changes). However, direct local access to the hybrid new messages will only work if the client is lenient about line endings: Pine seems OK, but others might not be, expecting an mbox file to be consistently "Unix" format.
Is this a regression introduced while trying to fix the attachment corruption problem, or just a brand new bug?! Hopefully there is a way of reverting this change without reintroducing the attachment problem.
Richard