Your message dated Sat, 14 Feb 2015 15:23:04 +0100 (CET)
with message-id <alpine.deb.2.11.1502141509200.12...@cantor.unex.es>
has caused the report #776094,
regarding dovecot-imapd: corrupts mailbox after trying to retrieve it
to be marked as having been forwarded to the upstream software
author(s) dove...@dovecot.org
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
776094: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776094
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Hello.
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.
---------- Forwarded message ----------
From: Santiago Vila <sanv...@unex.es>
To: sub...@bugs.debian.org
Date: Fri, 23 Jan 2015 22:32:28 +0100 (CET)
Subject: dovecot-imapd: corrupts mailbox after trying to retrieve it
Package: dovecot-imapd
Version: 1:2.2.13-11
Severity: serious
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
Description: application/gzip
--- End Message ---
