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/
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: 8B5D315CCD:
to=<firstname.lastname@example.org>, 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
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.
I am able to overcome the problem by manually creating the users spool file
with permissions 0660 and ownership rickf.mail.
I tried updating to the version of procmail in the current rawhide
(procmail-3.15.1-1.i386.rpm) and the problem persists.
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 <email@example.com>
- lose setuid/setgid (root,mail) bits (#23257).
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 ***
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".
Reassigning to postfix owner... he's currently on holiday, so a response from
him might take some time.
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
- 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.
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?
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
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
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.
*** Bug 60073 has been marked as a duplicate of this bug. ***
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.