Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 15779

Summary:	random mail loss occurs due to no locking between mail delivery agent (procmail) and POP/IMAP daemons
Product:	[Retired] Red Hat Linux	Reporter:	Rich Drewes <rpdrewes>
Component:	imap	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	6.2	CC:	rpdrewes
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-08-09 04:35:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rich Drewes 2000-08-09 01:22:41 UTC

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.

Comment 1 Bill Nottingham 2000-08-09 01:36:15 UTC

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.

Comment 2 Rich Drewes 2000-08-09 04:34:59 UTC

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 . . .

Comment 3 Nalin Dahyabhai 2000-08-28 16:23:37 UTC

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.

Comment 4 Vidar Langseid 2001-05-25 08:25:50 UTC

Hi

Has this been fixed in  Advisory ID RHSA-2000:102-05
(http://www.redhat.com/support/errata/RHSA-2000-102.html) ?

If not, it really should.....