Bug 43365 - procmail fails to create mail spool file for new users
procmail fails to create mail spool file for new users
Product: Red Hat Powertools
Classification: Retired
Component: postfix (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
David Lawrence
: 60073 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-06-03 23:11 EDT by Chuck Mead
Modified: 2007-04-18 12:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-16 12:49:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chuck Mead 2001-06-03 23:11:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9+)

Description of problem:
On several boxes I have in production, when I create a new user I have to
manually create their /var/spool/mail/$user file because procmail cannot
create a lock file in /var/spool/mail/

How reproducible:

Steps to Reproduce:
1. create a new user rickf
2. send new user rickf an email
3. procmail fails to deliver the mail


Actual Results:  Jun  3 22:56:40 server postfix/local[29238]: 8B5D315CCD:
to=<rickf@server.moongroup.com>, relay=local, delay=0, status=bounced
(can't create user output file. Command output: procmail: Couldn't create
"/var/spool/mail/rickf" procmail: Lock failure on
"/var/spool/mail/rickf.lock" procmail: Error while writing to
"/var/spool/mail/rickf" )

Expected Results:  procmail should have been able to create the users spool
file and it should be able to lock that file when needed. otherwise
procmail is useless as an MDA/LDA.

Additional info:

I am able to overcome the problem by manually creating the users spool file
with permissions 0660 and ownership rickf.mail.
Comment 1 Chuck Mead 2001-06-03 23:31:50 EDT
I tried updating to the version of procmail in the current rawhide
(procmail-3.15.1-1.i386.rpm) and the problem persists.
Comment 2 Chuck Mead 2001-06-03 23:43:20 EDT
I downgraded my version of procmail to the version that comes with RH7.0 and it
now works as expected. The only thing in the changelog between the 7.0 and the
7.1 release is this:

* Sat Jan  6 2001 Jeff Johnson <jbj@redhat.com>
- lose setuid/setgid (root,mail) bits (#23257).
Comment 3 Trond Eivind Glomsrxd 2001-06-03 23:57:55 EDT
It works with sendmail... postfix would like procmail to be setgid, and it isn't
trustworthy enough to get that.

*** This bug has been marked as a duplicate of 41693 ***
Comment 4 Chuck Mead 2001-06-04 15:04:49 EDT
In all likelihood this bug should be re-assigned to bero as Tim says that
postfix now belongs to him. Postfix' author has been apprised and has
communicated a bit with Trond. He wants to support postfix "out of the box".
Comment 5 Trond Eivind Glomsrxd 2001-06-05 10:00:49 EDT
Reassigning to postfix owner... he's currently on holiday, so a response from
him might take some time.
Comment 6 Bernhard Rosenkraenzer 2001-08-31 14:03:25 EDT
If you have any good suggestions at fixing this, let me know - I don't see a 
good way to do it.

The problem is that postfix isn't setuid/setgid (which is good), so if the 
delivery agent (procmail) isn't running setuid/setgid, the user's initial 
mailspool can't be created.

I can offer the following resolutions:
- Make postfix setuid/setgid. Bad idea, it would remove one of the best points
  of postfix.
- Make procmail setuid/setgid. Bad idea, for the reasons the setgid bit was
  removed in the first place.
- Mark this bug "RESOLVED: CURRENTRELEASE" with the note "package removed"
- Mark this bug "RESOLVED: NOTABUG" with the note that the admin should have
  created the initial mailspool and make it writable by the user

If you have any better ideas, let me know - I don't see any.
Comment 7 Chuck Mead 2001-08-31 14:12:26 EDT
Perhaps a simple way around it (woldn't hurt anything even if the intended shell
was /bin/false) is to add a touch string to the adduser script? Just an idea...
what do you think?
Comment 8 Bernhard Rosenkraenzer 2001-08-31 14:25:18 EDT
I actually did that initially, but it was reverted because it creates too much 
unnecessary junk on authentication servers with lots of users that aren't mail 
servers - and it doesn't fix the problem for mail servers that get user 
information over NIS, LDAP or something similar, so that's not an option 
Comment 9 Matthew Miller 2001-09-11 09:21:39 EDT
There is a problem beyond the creation of the initial mailspool. The non-setuid 
procmail (with postfix) also can't do much of what one might use procmail 
*for* -- delivering directly into various mailboxes in users' home directories.

If I understand what's going on, under sendmail, the MTA is already setuid 
root, and so there's not really any particular gain in removing the bit from 

I see above that postfix's author was contacted about this; does he have any 
Comment 10 Daniel Resare 2002-01-06 17:40:37 EST
Delivery into a user's own mailboxes in $HOME wouldn't be a problem, since the
delivery will be done as the user recieving the email.

The correct solution IMHO would be for procmail to use a specialized sgid helper
app that has the responsibility of delivering mail (and creating an initial
spool file) to /var/spool/mail, much like mutt does it.
Comment 11 Bernhard Rosenkraenzer 2002-02-21 10:59:42 EST
*** Bug 60073 has been marked as a duplicate of this bug. ***
Comment 12 David Lawrence 2003-05-16 12:49:08 EDT
Closing as WONTFIX due to end of life of the Power Tools product line. Please
open a new bug report under the Red Hat Linux product if the component is still
included in the base Red Hat distribution.

Note You need to log in before you can comment on or make changes to this bug.