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