On Thu, 19 Feb 2015 22:34:07 +0100 (CET) Santiago Vila <sanv...@unex.es> wrote: > On Sun, 15 Feb 2015, Timo Sirainen wrote: > > > 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. >
I have tried to reproduce this but I don't see a problem. - but it took me a while to understand what you are trying to do 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. I did this in a loop and gave up after running it over 250 times with any corruption. 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 3 messages for amw at localhost (folder inbox-b). 4. Then I triggered the problem as per: jessie% fetchmail -a localhost --folder inbox-b 3 messages for amw at localhost (folder inbox-b). reading message amw@localhost:1 of 3 (404 header octets) (8 body octets) flushed reading message amw@localhost:2 of 3 (394 header octets) (10 body octets) flushed reading message amw@localhost:3 of 3 (390 header octets) (4 body octets) flushed jessie% ls -l ~/mail/inbox-b -rw-r--r-- 1 amw amw 532 Mar 14 16:20 /home/amw/mail/inbox-b jessie% m ~/mail/inbox-b >From MAILER_DAEMON Sat Mar 14 16:20:19 2015 Date: Sat, 14 Mar 2015 16:20:19 +1100 From: Mail System Internal Data <MAILER-DAEMON@jessie> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1426310419@jessie> X-IMAP: 1426309513 0000000003 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. * So this appears to be okay - no corruption . * 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 .... Try 253 12 messages for amw at localhost (folder inbox-b). reading message amw@localhost:1 of 12 (404 header octets) (8 body octets) flushed reading message amw@localhost:2 of 12 (394 header octets) (10 body octets) flushed reading message amw@localhost:3 of 12 (390 header octets) (4 body octets) flushed reading message amw@localhost:4 of 12 (744 header octets) (8 body octets) flushed reading message amw@localhost:5 of 12 (733 header octets) (10 body octets) flushed reading message amw@localhost:6 of 12 (729 header octets) (4 body octets) flushed reading message amw@localhost:7 of 12 (744 header octets) (8 body octets) flushed reading message amw@localhost:8 of 12 (733 header octets) (10 body octets) flushed reading message amw@localhost:9 of 12 (729 header octets) (4 body octets) flushed reading message amw@localhost:10 of 12 (1069 header octets) (10 body octets) flushed reading message amw@localhost:11 of 12 (1065 header octets) (4 body octets) flushed reading message amw@localhost:12 of 12 (1081 header octets) (8 body octets) flushed Try 254 12 messages for amw at localhost (folder inbox-b). reading message amw@localhost:1 of 12 (404 header octets) (8 body octets) flushed reading message amw@localhost:2 of 12 (394 header octets) (10 body octets) flushed reading message amw@localhost:3 of 12 (390 header octets) (4 body octets) flushed reading message amw@localhost:4 of 12 (744 header octets) (8 body octets) flushed ... * NO problems seen. Am I doing this right? * I even tried constantly sending mail to the account but the worse I got was an occasional error message such as: ... reading message amw@localhost:104 of 254 (399 header octets) (0 body octets) flushed reading message amw@localhost:105 of 254 (399 header octets) (0 body octets) flushed fetchmail: Error writing to MDA: Broken pipe reading message amw@localhost:106 of 254 (399 header octets) (0 body octets) not flushed reading message amw@localhost:107 of 254 (399 header octets) (0 body octets) flushed .... but everything kept going... BUT: the default configuration of /var/mail doesn't have the sticky bit set nor is the configuration variable *mail_privileged_group* set to mail - which would suggest locking might be a problem. jessie% ls -ld /var/mail drwxrwsr-x 2 root mail 4096 Mar 14 16:27 /var/mail Note: I noticed that the dovecot wiki http://wiki2.dovecot.org/BasicConfiguration?highlight=%28mail_privileged_group%29 says: .... mbox If you're using mboxes, it's important to have locking configuration correct. See MboxLocking for more information. If you're using /var/mail/ or /var/spool/mail/ directory for INBOXes, you may need to give Dovecot additional permissions so it can create dotlock files there. A failure to do so will result in errors like these: open(/var/mail/.temp.host.1234.abcdefg) failed: Permission denied file_lock_dotlock() failed with mbox file /var/mail/user: Permission denied >From here on I'm assuming the INBOX directory is /var/mail. First check what the permissions of /var/mail are: # ls -ld /var/mail drwxrwxrwt 2 root mail 47 2006-01-07 20:44 /var/mail/ In this case everyone has write access there and the directory is marked sticky. This allows Dovecot to create the dotlock files, so you don't need to do anything. # ls -ld /var/mail drwxrwxr-- 2 root mail 47 2006-01-07 20:44 /var/mail/ In this case only the root and the mail group has write permission to the directory. You'll need to give Dovecot's mail processes ability to use this group by changing conf.d/10-mail.conf: mail_privileged_group = mail Note: Specifying the privileged user must be done as shown. Simply adding dovecot user to the mail group does not grant write permission. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
