procmail
[Top] [All Lists]

Re: using procmail as delivery agent to change mailbox location

1999-04-22 16:15:05
Matthew Hixson <hixson(_at_)frozenwave(_dot_)com> writes:
On Thu, 22 Apr 1999, Philip Guenther wrote:

Check out the comments at the top of the src/authenticate.c source
file.  You should be able to do the above by defining MAILSPOOLHASH to
"/.mailbox".

Thanks Philip.  Last night after I sent my message to the list I tried this in
/etc/procmailrc
...
This works just fine, with one small exception.  For some reason procmail is
creating a 0 length file in /var/spool/mail/<username>.  I can delete it, but
the next time mail arrives for a user it creates that empty file and then
proceeds to put the mail into $<username>/.mailbox.
 So, its not a big deal, but I would just like to know why its doing that.
 Also, is there any reason not to leave the system like it is with the above
int /etc/procmailrc?  Any advantage to modifying the source as you suggested?


"If you lie to the compiler, it will have it's revenge" -- Henry Spencer

...and that's true not only of compilers but any program.  As you have
it compiled, procmail believes /var/spool/mail/$LOGNAME to be the spool
file and it therefore performs several security checks on it,
culminating in the creation of the file if it doesn't already exist.
If you tell procmail the truth it will do what you want.

As for the /etc/procmailrc you show...

PATH=$HOME/bin:/usr/bin:/usr/ucb:/bin:/usr/local/bin:.
MAILDIR=$HOME
DEFAULT=$MAILDIR/.mailbox
LOCKFILE=$HOME/.lockmail

The first should be set int he config.h file when you compile procmail,
though I would *strongly* recommend that "." not be included at all in
the PATH.  There's little reason for it to be in the path of a
interactive shell, and even less for a non-interactive application.

The second line is completely redundant: if the /etc/procmailrc is
being used, then procmail will have already chdir'ed to $HOME.  The
assignment to DEFAULT is better handled as I described before, and the
LOCKFILE assignment will just act to slow down mail delivery by
restricting there to be at most one procmail running at once.  To quote
the procmailrc(5) manpage's entry for LOCKFILE:

                 The use of a  global  lockfile  is
                 discouraged,  whenever  possible  use locallock-
                 files (on a per recipe basis) instead.


Philip Guenther

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