Wieboldt, David wrote:
>
> It has been quite a chore getting procmail to run at all here. No
> success
> at all with the .forward hack; any time it is run, the mail goes to
> "nobody." Anyway I managed to get procmail running after finding a clue
> and hacking /etc/smail/transports like this:
>
> # This is the Smail transports file, which gives details of how ...
> # It was originally generated by `smailconfig', part of the Smail
> package
> # distributed with Debian, but it may edited by the mail system
> administrator.
> # Hacked 5 May 97: redid "local"
>
> local: from, local, inet, return_path, driver=pipe; user=root,
> cmd="/usr/bin/procmail -d $($user$)"
>
> smtp: uux: pipe: file: (all unchanged)
>
> At this point the hope is that I replaced my local delivery agent with
> procmail. Therefore, according to TFM, it should run if the user has a
> .procmailrc file. Those look like this:
>
> #Set on when debugging
> VERBOSE=off
>
> #Replace 'mail' with your mail dir
> MAILDIR=$HOME/mail
>
> #directory for storing procmail log and rc files
> PMDIR=$HOME/.procmail
>
> LOGFILE=$PMDIR/log
> INCLUDERC=$PMDIR/rc.filter
>
> Now that is well and good, but it does not run! Mail gets forwarded by
> procmail to the user's account just fine, but the user's recipie does
> not
> get executed.
>
> Additionally, any attempt to run procmail with -m (filter mode) simply
> hangs up and does not run. I suspect more smail hacking is in order.
>
> Does anybody have a clue?
>
Just a guess, but instead of
local: from, local, inet, return_path, driver=pipe; user=root,
cmd="/usr/bin/procmail -d $($user$)"
how about
local: from, local, inet, return_path, driver=pipe; user=$user$,
cmd="/usr/bin/procmail -d $($user$)"
otherwise will procmail really know whose recipie to run?
--
Jens B. Jorgensen
[EMAIL PROTECTED]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
