I have encountered this bug as well at current versions in lenny and sarge.
I tracked it down to bug 450665 (which is also bug: 499189)
On Debian, /var/spool/mail is set with 02775 permissions (which seems
reasonable) but libc-client wants the permissions to be 01777.
Normally, the program will fallback to using "mlock" to lock the
mailboxes, but Debian installs mlock in the wrong directory.
(libc-client looks in /usr/sbin/ but the mlock program is installed to
/usr/bin/)
The result is that there is no file locking of users mailboxes at all.
This means new mail can arrive into the mailspool while imapd or popd is
reading mail out of it.
Corruption exactly as described in this bug occurs.
The FAQ document found in /usr/share/doc/libc-clientxxxx and online here:
http://www.washington.edu/imap/IMAP-FAQs/index.html#7.10
has more information.
There are 3 solutions I can see:
1) Change /var/spool/mail to 01777 and risk some petty mischief. (Users
locking each others mailboxes is the worst I can come up with.)
2) move /usr/bin/mlock to /usr/sbin/mlock (or create a symlink to it)
3) patch libc-client to look in /usr/bin rather than /usr/sbin
#2 seems the easiest and safest in terms of security/permission
implications. Since mlock is shipped by the libc-client package and is
only used by it as far as I can tell, it doesn't seem to be a problem
for the package to move it entirely (versus making a symlink) since no
one else should be using mlock or relying on it in /usr/bin.
Thanks,
--Mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
