Bug#776094: dovecot-imapd: corrupts mailbox after trying to retrieve it (fwd)

[Timo Sirainen]

On 14 Feb 2015, at 16:23, Santiago Vila <sanvila at unex.es> wrote:

> I wrote about this three weeks ago but got no answer. I'm going to
> officially "forward" the Debian bug this time, with all the details.
> 
> The test case is just 840 bytes long. Please give it a try.
..
> Package: dovecot-imapd
> Version: 1:2.2.13-11
> Severity: serious

I can't reproduce with latest Dovecot hg. But just in case it's still not fixed, there are two important things:

1) Send your doveconf -n output, since there are some settings that can affect this

2) rm -rf ~/mail/.imap/inbox-b before testing to make sure indexes don't cause this problem.

> The following mbox folder, when put in $HOME/mail, becomes corrupted after
> trying to retrieve it with fetchmail.
> 
> The problem may be reproduced by using the same machine as server and client:
> 
> * Put "inbox-b" in $HOME/mail
> 
> * Put this in $HOME/.fetchmailrc
> 
> server localhost proto imap port 143:
> user "someuser"
> pass "thepassword"
> 
> * Retrieve email using this command line:
> 
> fetchmail -a localhost --folder inbox-b -m "true"
> 
> 
> Note: By looking at the "true" above it is clear that whatever
> fetchmail does with the message is not important at all.
> 
> 
> You will see something like this:
> 
> 12 messages for someuser at localhost (folder inbox-b).
> reading message someuser at localhost:1 of 12 (171 header octets) (3 body octets) flushed
> reading message someuser at localhost:2 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:3 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:4 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:5 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:6 of 12 (171 header octets) (3 body octets) flushed
> reading message someuser at localhost:7 of 12 (171 header octets) (3 body octets) flushed
> reading message someuser at localhost:8 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:9 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:10 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:11 of 12 (245 header octets) (3 body octets) flushed
> reading message someuser at localhost:12 of 12 (273 header octets)fetchmail: incorrect header line found - see manpage for bad-header option
> not flushed
> 
> 
> And in fact "inbox-b" in the server is now like this:
> 
> [...]
>> From root at example.com  Tue Jan 13 10:18:20 2015
> rstuvwxyzabcdefghijklmnopqrstuvwxyz at example.com
> To: a at example.com
> Subject: a
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> Message-Id: <20150113091737.B5ADA5F8B1 at example.com>
> Date: Tue, 13 Jan 2015 10:17:25 +0100 (CET)
> X-UID: 16035
> Status: O
> 
> a
> 
> 
> Note how the From: line has been truncated from its original state.
> 
> 
> I have been suffering from this problem for months. At first I believed
> it was some misbehaving procmail/formail recipe I had on the server,
> but that's not the case as this example shows.
> 
> Thanks.<inbox-b.gz>