srb(_at_)cuci(_dot_)nl (Stephen R. van den Berg) writes:
If there still are any compilation or runtime problems left, *report* them.
2 things:
- I still haven't figured out how to deal with mode-775 mailspool. If I
DROPPRIVS before delivering, it can't write to the dir (and hence can't lock
the .lock file and can't create a mailbox file if there wasn't one already).
If I deliver before DROPPRIVS'ing, it works fine (of course) except that the
file that gets created is owned by root.root instead of <user>.mail.
I guess the idea is that the files have to be created some other way and then
to deliver without .lock locking, is that right ? (when the error message
"procmail: Lock failure on "/var/spool/mail/news.lock" appears does it mean
that no locking took place or does it mean that it reverted to plain
kernel-locking ?)
- Actually the above example is a little wrong: I only use a 775 dir for a
backup-mailspool and the main delivery file is /var/mail/$LOGNAME/mailbox.
I slightly extended procmail so that it can be configured to do the right
thing. Basically, the normal concat(MAILSPOOLDIR, MAILHASH, LOGNAME) is
extended into concat(MAILSPOOLDIR, MAILHASH, LOGNAME, MAILDIRFILE) with the
default MAILDIRFILE being "". I've encountered the following problems:
- I had to do it
- I then defined MAILSPOOLDIR="/var/mail/" and MAILDIRFILE="/mailbox"
in config.h and recompiled: it did work, but with the ever recurring
warning that I was redefining MAILSPOOLDIR (because it's already
defined in autoconf.h which is #include'd before). Wouldn't it be
possible to include config.h before and wrap all #define's in
autoconf.h within the usual '#ifndef ... #endif" ?
It seems that few sites use a /somewhere/$LOGNAME directory (instead of file)
even though it has the advantage of allowing to put the .procmailrc and the
.forward there as well (which has the advantage of being (hopefully) on a local
disk so that if your home dir is unavailable, the forwarding will still work
and your procmailrc might also still work, depending on what you do in your
procmailrc) but I've appended my patch (which is supposed to be
100% "upward compatible) anyway, in case anyone is interesting
Stefan
PS: all the changes in config.h are (of course) specific to my setup, the
rest should be totally generic
procmail.patch
Description: procmail.patch