All-
I have a question that I hope can be answered easily. In addition to
reading the man pages, I've searched dejanews, and the mail-list
archives, and didn't find an answer. Perhaps I'm just not understand the
options correctly, and I hope that is the case.
I have an e-mail architecture where I basically have a Sparc ULTRA2 as
the mailserver and message store for the entire location. It serves
e-mail via POP3/IMAP4 to desktop clients, and NFS to UNIX clients. I'm
using sendmail 8.8.5 as the MTA.
For performance reasons (with user's home directories spread out across
NFS servers, WAN links, firewalls, etc.) I've configured sendmail to
check for .forward files in a locally mounted directory in the format of
/dir/user.forward .. This has increased the delivery times, and
decreased memory usage on the server and mail backlogs due to $HOME
unavailability markedly.
I have to temporarily move the normally locally mounted mail directory
to another NFS server (due to space and hardware failure reasons). I've
switched to procmail as the delivery agent rather than /bin/mail for
integrity, performance, and security concerns. (ie: Fixing mailbox
permissions, properly locking the mailbox during delivery, and
delivering to NFS mounted mailboxes that will also be accessed via NFS)
The problem is, that procmail mounts $HOME to look for
$HOME/.procmailrc. I'd like to disable that behavior when procmail is
run as the delivery agent. If a user has setup a /dir/user.forward file
that runs procmail I'd then like it to look at the user's
$HOME/.procmailrc obviously.
I used the normal FEATURE('local_procmail') to gen the appropriate
Mlocal command in my sendmail.cf file. I have not edited it.
Looking at the manuals and the src files, I see I can define (in
config.h) a default location for the .procmailrc ... All I want is to
disable the lookup (and thus parsing, etc.) of that file when procmail
is invoked from sendmail to deliver mail. If procmail is invoked as an
IFS as part of a .forward, I'd like it to look in $HOME/.procmailrc
Any help would be appreciated.
Thanks.
-j
--
Joseph F. Dries III
Lockheed Martin Government Electronics Systems
EIS Sr. Network Engineer IBP Systems Engineering Group
mailto:jdries(_at_)motown(_dot_)lmco(_dot_)com