Hello. Sorry for the late reply. I have just realized about your messages.
Please note that in this bug I'm just the submitter, not the maintainer, and therefore any message sent to the 776...@bugs.debian.org address is received only by the maintainer abd the bug system, but not by me. The error may be reproduced on any Debian system running jessie if you do exactly what I describe in the bug report. In particular: > I ended up with the messages re-appearing into /var/mail/amw which I > then re-copied to the inbox-b and ran fetchmail again. Please don't do it that way. The error is not about the --folder option of fetchmail not working in a "generic sense". It's about a *particular* mbox which does not work, namely this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=inbox-b.gz;att=1;bug=776094 > I did this in a loop and gave up after running it over 250 times with > any corruption. Please test it on a Debian system running jessie exactly as I describe, do not change *anything*. > But note my comment at the bottom I did see one possible configuration > problem on locking files - which isn't set on the default set up - but > it made *NO* difference > to me... > > 1. I created a vanilla dovecot-imapd installation with one user and > sent some mail to it's account in /var/mail/amw > 2. I then created the remote folder by copying the mbox so: > cp /var/spool/mail/amw /home/amw/mail/inbox-b > > 3. Then I confirmed the remote folder was ok as below: > > jessie% fetchmail -c localhost --folder inbox-b Please do this instead: fetchmail -a localhost --folder inbox-b -m "true" as I wrote in the initial bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776094 Here, we are not interested at all in whatever fetchmail does with the messages once they have been retrieved, only about dovecot giving them to fetchmail, and how the remote folder is corrupted afterwards. > * I repeated this in a loop: > while true; do > cp /var/spool/mail/amw /home/amw/mail/inbox-b && fetchmail -a > localhost --folder inbox-b -m true && sleep 1 \nT=$(($T+1)) > echo Try $T\nsleep 1 > done No loop, please. This is not a "random" error, it's an error that I can always reproduce with the provided inbox-b test case. Please make sure that a) You are using Debian jessie. b) The inbox-b file is exactly the one I provided. c) You run fetchmail using the provided command line. BTW: We are releasing jessie as Debian 8 today, but I still hope that this may be fixed in a point release. Note: By looking at the test case one might think about the typical blurb in security announcements: "A specially crafted message makes program foo to crash..", as if this needed some kind of "bad faith" from an attacker. This is not really the case. I hit this bug nearly one day every two with real email. I wonder: nobody is able to reproduce this, or just nobody *tried*? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
