Philip, thanks for the quick response.
I have no intent to access/munge my mailspool from shell scripts. My
intent is to retrieve the mail using a pop3 client (the ipop3 daemon is
running as a part of xinetd). I'm using the imap package from
www.washington.edu/imap
I have tried all sorts of permission scenarios, all short of making
/var/spool/mail world writable. I have seen plenty of cautions against
that, so I think I'll live with the messages I described. Sounds like
the impacts are all scenarios I don't plan to use.
----- Original Message -----
From: "Philip Guenther" <guenther(_at_)gac(_dot_)edu>
To: "Mike McCandless" <michael(_at_)prismbiz(_dot_)com>
Cc: <procmail(_at_)Lists(_dot_)RWTH-Aachen(_dot_)DE>
Sent: Sunday, September 29, 2002 5:59 PM
Subject: Re: Help with Lock Failures Using /etc/procmailrc
"Mike McCandless" <michael(_at_)prismbiz(_dot_)com> writes:
I am using procmail v3.22 on RH7.2. I recently switched from having
an
individual .procmailrc in each $HOME directory to one in
/etc/procmailrc. I invoke procmail from postfix with the mailbox
command '/usr/bin/procmail -m /etc/procmailrc'. Within procmailrc, I
am
using Email Sanitizer and lastly Spamassassin. I check the log file
that procmail is writing to (in my $HOME directory) and keep seeing:
Lock failure on /var/spool/mail/michael.lock
...
The permissions on the /var/spool/mail directory is:
drwxrwxr-x 2 root mail 1024 Oct 1 14:09
/var/spool/mail
If those are the permissions set by Redhat when the machine was
installed,
then you _may_ be able completely ignore the failure to create
lockfiles,
as Redhat should have verified that all the program that access the
mailspool all use fcntl()-style kernel locking. That's fine, but you
need to remember that you can't access/munge your mailspool from shell
scripts as they have no way to apply kernel locks. For most people,
that's
not a requirement, so it may be alright for you.
Note that if you export that directory to other systems via NFS, then
*you* need to verify that all the programs are using fcntl() locking
and that all the systems having working lock daemons.
If that isn't fine and you need to be able to create dotlock
lockfiles,
then you should consider changing the permissions on the mailspool to
1777. Note that there are tradeoffs in such a change, so you
shouldn't
do it 'just because'. Indeed, the RPM system may try to change it
back
to 775 in certain cases...
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail