The default local mail delivery agent in RH (procmail) uses fcntl locking
(as revealed by procmail -v) when delivering mail to user mailboxes in
/var/spool/mail. The POP and IMAP daemons use incompatible flock locking
on the mail spool files. Since neither locking method respects the other's
locks, no locking is actually performed. Random loss of mail messages is
the frequent result when both programs access a mail spool file
simultaneously. This data loss has been experimentally confirmed.
(Both the POP/IMAP servers and procmail also attempt to perform dot file
locking on the mail spool files, but strace reveals that the attempts fail
due to RH's default directory permissions on the mail spools.)
Note that while it is possible to lose messages for the above reason any
time a POP/IMAP retrieval attempt occurs at about the same time as the
receipt of a message, certain circumstances make loss of data much more
likely. In particular, large mail spool files and high system loads
increase the likelihood of data loss greatly.
This same problem existed in RH 5.0 and 5.1. I reported the problem at
that time as well, and it appeared to be fixed in RH 5.2.
This problem appears to exists on all RH 6.x releases.
The problem is relatively easy to fix. The procmail package is
configurable to use several locking styles, including flock, lockf, and
fcntl. Currently, a patch in the procmail SRPM disables all styles except
dot file locking and fcntl. If this patch is changed so that procmail will
compile with flock locking instead (which is what the POP/IMAP servers use)
then this problem will go away. Note that other packages that modify the
mail spool files, such as pine and elm, should also be examined to make
sure they use the same locking style as the POP/IMAP daemons and procmail.
Another fix would be to change file permissions on the mail spool directory
to make sure that dot file locking can succeed. Default permissions on the
mail spool appear to be different in some RH derived releases (including
Mandrake), perhaps to address this problem. This might work better for
spool directories stored over NFS.
That's the wrong fix. The POP and IMAP servers need to
be fixed to use fcntl; flock doesn't work over NFS.
Assigning to imap.
Bad news: pine and mail both appear to use flock too and should also be
patched. Elm seems to use fcntl.
Obviously all of these programs should use the same locking scheme as procmail
and the imap and pop daemons. I'm sure there must be a few more programs that
access mail spools that I didn't think of . . .
The kernel used to implement flock() over fcntl(), but that changed in 2.2. All
mail programs will use fcntl() for locks in the final release.
Has this been fixed in Advisory ID RHSA-2000:102-05
If not, it really should.....