On Tue, Jun 03, 2003 at 04:49:12PM -0700, Professional Software Engineering
wrote:
Ideally, the users .forward would be run, then if delivery is still local,
the global procmailrc would be used, then the per-user procmailrc.
That might be ideal for you. In my book, 'ideal' would be:
(procmail as LDA, as it should be)
global procmailrc (regardless of whether there is a .forward or not)
forward (if present, to do whatever)
~/.procmailrc (if the forward invoked procmail, or didn't exist)
Well you are the admin of your box yes? :) Perhaps a method to "get
arround" this limitaton is in order. Wether '.forward' works is
dependant on a config option in sendmail.
define(`confFORWARD_PATH',
`$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
is the default on my system, but if you do a :
define(`confFORWARD_PATH', `');
it will turn the .forward mechanism off.
But in your case you want to still let people use .forward. Well
.forward can do two things, forward email to another address, or run
the mail through a program. Seems to me that procmail can handle both
these tasks. So create a recipie like the following:
:0 w
* ? test ! -e $HOME/.forward
{
# Parse and excute the contents of the .forward file
}
as the last thing in your /etc/procmailrc. Then except that there
might be traces of your other filters in the mail. The user should
never know he was forced to go through the global scripts and that
eveything was handled just fine by his .forward file.
--
Till Later, Jake <karrde+procmail(_at_)viluppo(_dot_)net>
-----------------------------------------------
Direct replys are likley to be flagged as spam.
Drop the +addy if you need to reply direct.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail