Harry Palmer <hpalmer(_at_)ns1(_dot_)jerky(_dot_)net> writes:
...
This seems to accomplish what I was looking for. Does anyone know if
this will break any other functions of procmail? Or is there a better
way to accomplish this?
If any of the following mode bits are set on a mailspool, procmail will
not change the permission on it:
user execute
sticky
So, pre-creating the mailboxes with permissions 766 or 1666 should
work.
Ya I noticed that. The only problem with that is that it is not
uncommon for me to have a large number of user accounts that are
essentially idle. I naturally don't want wasted space and inodes for a
user that isn't getting any email. This may seem like an insignificant
matter but when you talk about a system with tens of thousands of users
your spool directory gets a tad silly. I'd much rather prefer playing
about with 5000 active spools than 5000 active, and 15,000 empty
(useless) files.
Hmm, I see. If I was in such a situation I would probably move to a
hashed mailspool tree (e.g., /var/mail/g/u/guenther) or putting
mailspool in home directories. Both of those have possible
compatibilty problems, and the latter may also be difficult on AFS or
DCE systems, depending on how authentication/authorization is done by
the file servers.
Besides the security concern, do you forsee any problems with the
solution I proposed? My main concern is whether it will break any
functionality of procmail.
I can't think of anything that would break.
Philip Guenther