On 14 Feb 2015, at 16:23, Santiago Vila <sanv...@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@localhost:1 of 12 (171 header octets) (3 body > octets) flushed > reading message someuser@localhost:2 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:3 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:4 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:5 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:6 of 12 (171 header octets) (3 body > octets) flushed > reading message someuser@localhost:7 of 12 (171 header octets) (3 body > octets) flushed > reading message someuser@localhost:8 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:9 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:10 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@localhost:11 of 12 (245 header octets) (3 body > octets) flushed > reading message someuser@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 r...@example.com Tue Jan 13 10:18:20 2015 > rstuvwxyzabcdefghijklmnopqrstuvw...@example.com > To: a...@example.com > Subject: a > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > Message-Id: <20150113091737.b5ada5f...@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>
