[Dovecot] Inconsistent handling of CRLF in APPEND

[Richard Birkett]

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