Here are some proposed solutions to the problem:
Currently, require_files causes message deferral if it can't tell
if the file is there. If there's a general way to distinguish
between NFS mount failures and permission failures, I'd opt for
treating permission failures as "file not present".
Another possibility is to add an option, like:
require_files_unknown (defer|assume_present|assume_absent)
which would affect require_files' behavior when it can't tell if
the file exists. For my situation, users who protected their home
directories wouldn't be able to use the auto-.procmailrc feature
but would, instead, have to put the call to procmail into their
.forward files. I can live with this. (I don't run NFS -- I regard
it as a cancer that should be killed by extreme methods. :-)
The third possibility would be to have an equivalent of
require_files but which defers the actual testing until a userid
can be found to do the testing under. I suspect with the design of
exim that this would be difficult....
A final possibility, which others mentioned, is to do the
require_files check as root. Because of the NFS problem, this
would have to be optional. A variation of this is to run it as
root and then if that failed, run it as the exim user id. Or,
even:
require_files_users userlist
and the test is run under each user in the list until a definite
answer is obtained.
