procmail
[Top] [All Lists]

Re: Locking folders and .forward files

1996-06-11 05:06:01
Hiram Lester asked,

| ...  I also have
| procmail installed for personal use and get the error locking message only
| on my main incoming mail file.  I believe this has to do with the fact
| that it's trying to create the lock file in a directory (/usr/mail) that I
| don't have write privileges in.  I'm using Pine 3.93 (which I also have my
| own copy of) and I'm not sure what it does to lock the INBOX since it also
| shouldn't be able to write in that directory.  Is there a way to either
| get it not to lock or a way to get it to work the same way Pine is?

As Guy Geens posted, Pine probably is installed setgid mail (and the mail
spool directory probably is group mail with 775 permissions).  If you can't
get the same done for procmail (or can't get the mail spool directory's perms
loosened to 1777 -- note the sticky bit), then there are two basic ways to go
that don't require help from the sysadmin:

1. Keep your default mail spool in a directory where you have write
   privileges (somewhere under your $HOME, for example) and set DEFAULT
   accordingly in your .procmailrc.

2. Finish off your .procmailrc with a recipe that saves unconditionally to
   $ORGMAIL but provides a name for the local lockfile.  That named local
   lockfile should be in a directory where you have write privileges.

#2 is not as good as #1, because #2 will prevent two procmail processes from
writing to your main spool at the same time but will no prevent procmail and
your mail reader from writing to it at the same time.

| I have another account that I want to use procmail on, but I'm not sure if
| it will cause a problem.  My other account has several different types of
| machines (mostly HP's, some Linux, and 1 or 2 DEC's).  The sysadmin people
| have placed a .forward file in there to route mail to one specific machine
| (the most powerful of the HP's).  This is where I would like to run
| procmail, but I'm afraid that if I just replace the .forward file with one
| for procmail that mail coming to one of the other types of machines (Linux
| or DEC) will go off the deep end when it tries to run a copy of procmail
| compiled for a different machine.

There is an example somewhere in the docs of how to include a call to uname
in your .forward to figure out which procmail binary to run.

| My question is would it be acceptable
| to user a forward file like:
| 
| user(_at_)machine(_dot_)domain(_dot_)edu
| |IFS=... (procmail line here)

No.  The first line will be a problem if it's called on the named machine,
and the second line will cause a problem if that path to procmail doesn't
exist or doesn't run on the machine where it is called.

<Prev in Thread] Current Thread [Next in Thread>