Nancy McGough <nm-this-address-is-valid(_at_)no(_dot_)sp(_dot_)am> writes:
On 10 Mar 2002 Andy Arbon (andy(_at_)andrewarbon(_dot_)co(_dot_)uk) wrote:
I have a system wide rc file in /etc which just contains:
DROPPRIVS=yes
LOGFILE=/var/log/procmail
VERBOSE=on
:0
*
$HOME/Maildir/
The global procmailrc is processed before the user's procmailrc
so maybe that's the entire problem. To set the user's default
inbox, you could put this in the global procmailrc
DEFAULT=$HOME/Maildir/
and then that's where messages that fall through all their
recipes will go. But, from what I've read here, I think it is
best to rebuild procmail so that the default mailbox (and ORGMAIL
and errors) are handled correctly. I'm not an expert in this so
hopefully someone who is will chime in here.
You are correct. There are two main reasons to prefer recompiling
procmail with the correct path over simply setting the path in the
/etc/procmailrc file:
1) Procmail performs a series of security checks on the compiled in path
to guarantee that it's both possible and safe for the user to save mail
there. If the mailbox is owned by some other user procmail will even
try to move it out of the way and create a new one. If it can't do
that, it'll unset DEFAULT and ORGMAIL to disable the default delivery.
Setting DEFAULT yourself doesn't do any such checks.
2) The /etc/procmailrc file is not read if a rcfile or variable
assignments are put on the command line, so procmail would use the
compiled in spool location then. It's a great way to make people
think their mail is being lost, delivering it to somewhere unexpected.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail