When Sean advised Bill,
You're better off using the sendmail virtusertable feature.
Bill replied,
| Ok, I agree with that.
|
| The current system is setup to automatically update the .procmailrc file.
| .procmailrc is nice in that the user "foo" has permission to do this.
|
| This is a bit off topic, but any suggestions how to best setup to allow
| user "foo" to rewrite the virtuseratble, rebuild the hash and restart
| sendmail?
Should the user have the access to change the set of aliases or only the
destinations of a set of aliases among which additions and deletions are
infrequent?
If you set up the aliases like this:
alias1: "|/path/to/procmail -a keyword1 -d user"
alias2: "|/path/to/procmail -a keyword2 -d user"
alias3: "|/path/to/procmail -a keyword3 -d user"
[where the binary at /path/to/procmail is either suid root or, if the man page
for procmail(1) built there says it is acceptable, both setuid the user and
setgid to the user's login group], then the user can put
ALIASKEY=$1
near the top of his/her .procmailrc. Whenever (s)he wants to change what
happens with mail to alias2, for example, (s)he needs just to change the
.procmailrc actions applied when * ALIASKEY ?? ^^keyword2^^ with no
involvement from an administrator and no rebuild or restart. Root privileges
are needed only when aliases are added (not even really when they're removed,
unless the admins want mail for a canceled alias bounced in the SMTP
transaction or want to revoke control of it from the user.)
If your MTA is qmail, it's even easier. As I understand, the alias table can
be something like this:
alias1: user
alias2: user
alias3: user
and the user sets up ~/.qmail-alias1 for alias1, ~/.qmail-alias2 for alias2,
et cetera.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail