Peter Koch <pk(_at_)TechFak(_dot_)Uni-Bielefeld(_dot_)DE> writes:
we're using procmail 3.14 in a site wide installation for mail delivery as
sendmail's local mailer. For various reasons, the mail has to be delivered
into the users' (NFS mounted) home directories, i.e. the file $HOME/mail/inbox.
This is achieved by defining MAILSPOOLHOME to "/mail/inbox" as suggested in
config.h and works fine.
However, some users may want to change their default inbox to something else
by defining DEFAULT in their .procmailrc, which also works fine.
But then, procmail creates $HOME/mail/inbox anyway and there's no easy way to
stop it because this is done in screenmailbox() which is called before
the system wide or private .procmailrc files are even opened.
I've found an old patch from Peter Jaeckel <pj(_at_)jet(_dot_)uk> in the
archive
(<Pine(_dot_)LNX(_dot_)3(_dot_)95(_dot_)970310112702(_dot_)14836A-100000(_at_)pc_pjaeck(_dot_)jet(_dot_)uk>)
introducing an
option "-n" to prevent procmail from screening the mailbox (and thus from
creating this unwanted default directory and file), but I'm not sure that's
the right way to go. The whole code in screenmailbox() to me seems not
applicable to mailboxes inside the user's $HOME, so shouldn't it be skipped
in case MAILSPOOLHOME is defined?
Not really.
The UNIX community has come to the conclusion that any program that can
be run as a user (or root) without the user's direct action must not
trust a file in a user's home directory without checking the files's
ownership and permissions. To do otherwise probably opens up a security
hole. This is why sendmail checks the ownersip and permissions on a
.forward file before reading it, why rshd/rlogind check the ownership
and permissions on a .rhosts file before reading it, why tcsh checks
your .tcshrc/.cshrc and .login files, and why procmail checks both your
.procmailrc and your mailspool before using them. In the case of your
mailspool, procmail *really* wants to set DEFAULT to something useful.
It can't delay the check to the end of the .procmailrc because you may,
with good reason, put
:0:
* conditions
$DEFAULT
in your rcfile and procmail wants to be able to protect you from evil
in that case, as you don't have original control over the value of the
DEFAULT variable.
If I have a regular file at $HOME/mail prohibiting the creation of $HOME/mail/
(as a directory) and $HOME/mail/inbox, screenmailbox() will return zero (via
the ``fishy'' label). Delivery is not influenced by this, but this also means
the result of calling screenmailbox() depends on strange effects.
These people so annoyed with the presence of $HOME/mail as an empty
directory that you feel you need to patch procmail to not require its
existance? My initial reaction as a sysadmin would be to tell them to
just ignore it, but perhaps I'm missing something.
(We currently use $HOME/.mailspool at the place where I'm the sysadmin.
That has the advantage of being a dotfile and therefore both less obvious
and more likely to be lost in the other 20 dotfiles the user has.)
Philip Guenther