Peter Jaeckel asked,
| Now for the problem. As this pc here is sitting in a site-wide network
| where all incoming mail is stored in a central mail server whose
| drives can be accessed via nfs and in no other way, I have a symbolic
| link to the right point in the mounted file system tree. Everything is
| fine as long as incoming mail is actually stored by the central mail
| host on the server's file system. However, if I happen to send mail to
| another userid on my Linux pc, procmail insists on removing the
| symbolic link to something like BOGUS.xxx (as described in the man
| pages).
|
| How do I stop procmail doing that (security is not an issue _at_
| _all_) ?
I'm wondering if perhaps the problem is not one of security but of procmail's
refusal to deliver to a symlink (or to an existing folder with more than one
hard link) because then one folder could have two or more valid .lock files,
and two processes could believe they had the lock at the same time.
HOWEVER, note that procmail does not mind delivering to a folder whose
absolute path is through a directory name that is actually a symlink to
another directory, because then the two names for the .lock file would be
equivalent, and two processes could not get simultaneous local lockfiles.
The problem comes only if the folder's basename is a symlink.
If that's the situation, there may be no need to hack the source. Perhaps,
instead of an individual symlink to each folder, symlinks could point to the
true physical locations of the directories where those folders lie, and
procmail would happily save mail to a real folder in a symlinked directory.