Hello,
I've been having problems with qpopper corrupting mailboxes when a
user is at their disk quota. Here's the background;
* User has a disk quota in /var/mail where mail is spooled (by
sendmail/procmail).
* User is close to or at disk quota due to "leave mail on server" setting.
* User pops mailbox, mail gets copied to a tempdrop on a different
filesystem with no quota (.user.pop file).
* Mail gets delivered to spool directory (/var/mail) during pop session
since the mailbox and quota are empty.
* Qpopper fails to copy mail back in it's entirety to spool directory due
to a quota violation (i.e. old mail + new mail > quota).
* Mailbox gets written up to quota limit resulting in the first header
of message being corrupted. The first line is binary data the size of the
quota. For example, if the quota is 10MB the first line would be 10MB in
size. Delete the first line and the mailbox returns to the size of the
message just delivered in the box (a few hundred k bytes).
* Subsequent popper sessions result in the following error :
-ERR [SYS/PERM] Unable to process From lines (envelopes), change
recognition modes or check for corrupted mail drop.
The problem seems to stem from the fact that qpopper does not lock the
mail spool file during the entire popper process. A .lock file is created
in /var/mail while the spool is copied to the temp drop directory, then
removed while the .user.pop file is being processed during the session.
Procmail (used as the LDA) respects .lock files and would not be able to
deliver mail if the mailbox was locked during the entire popper session,
I've tested this.
I've looked through the list archives (not searchable :-( ) and do not see
any report of this exact problem. I did however find an indication that
per the RFC that locking the mailbox during the entire popper process is
allowed. Previous versions of Qpopper did not corrupt mailboxes, but did
leave the mail behind in the tempdrop directory. The release notes
indicated that Qpopper 4.0 is supposed to handle disk quotas more
gracefully but this doesn't appear to be the case in my situation.
I'm running BSD/OS 4.3 with user quota on /var, but not on /usr
(tempdrop) Here's the compile and runtime options.
compile :
# --sbindir=/usr/local/libexec --libexecdir=/usr/local/libexec
# --enable-keep-temp-drops
# --enable-temp-drop-dir=/usr/local/var/mailtmp
# --enable-log-facility=LOG_LOCAL1
# --enable-log-login
# --enable-specialauth
# --enable-uw-kludge
# --enable-debugging
inetd :
pop stream tcp nowait root /usr/local/libexec/popper popper
-s -c -C
Due to user requirements, I cannot force them to remove mail from server.
Is the above a known bug, or is there an option I can change to fix this?
Regards,
Chris
