procmailrc question

[Waldher, Travis R]

> -----Original Message-----
> From: Rick Stevens [mailto:rstevens at vitalstream.com]
> Sent: Wednesday, March 16, 2005 9:31 AM
> To: Getting started with Red Hat Linux
> Subject: Re: procmailrc question
> 
> Waldher, Travis R wrote:
> >
> >>-----Original Message-----
> >>From: Bob McClure Jr [mailto:robertmcclure at earthlink.net]
> >>Sent: Thursday, March 10, 2005 4:23 PM
> >>To: Getting started with Red Hat Linux
> >>Subject: Re: procmailrc question
> >>
> >>On Thu, Mar 10, 2005 at 04:02:00PM -0800, Waldher, Travis R wrote:
> >>
> >>>>-----Original Message-----
> >>>>From: Bob McClure Jr [mailto:robertmcclure at earthlink.net]
> >>>>Sent: Thursday, March 10, 2005 3:50 PM
> >>>>To: Getting started with Red Hat Linux
> >>>>Subject: Re: procmailrc question
> >>>>
> >>>>On Thu, Mar 10, 2005 at 03:41:27PM -0800, Waldher, Travis R wrote:
> >>>>
> >>>>>Ok.. good question here.
> >>>>>
> >>>>>If I don't want an /etc/.procmailrc, and I have users that have
> >
> > an
> >
> >>>>>invalid $HOME path on the sendmail server, how can I support
> >>>
> >>>.procmailrc
> >>>
> >>>>>files for those users as procmail only appears to look at
> >>>>>$HOME/.procmailrc.
> >>>>
> >>>>Not true.  Procmail looks at /etc/procmailrc (not
> >
> > /etc/.procmailrc)
> >
> >>>>and then at $HOME/.procmailrc.  Note also that the latter must be
> >>>>owned by the user and be writable only by that user (644 perms).
> >>>>
> >>>>I'm curious.  What users have an invalid $HOME, and why?
> >>>
> >>>In short, I have a mess here.
> >>>
> >>>We have multiple user account file systems.  The one for our
> >
> > sendmail
> >
> >>>server is say /acct, the one for our HP machines would be /acct.hp.
> >
> > But
> >
> >>>our sendmail server also mounts that so mail can be handled
> >
> > properly.
> >
> >>>The problem is, I can't create user directories in /acct, even if
> >
> > it's
> >
> >>>just to put a .procmailrc link to their /acct.hp directory.
> >>>
> >>>So I need procmail to be able to use /acct/username/.procmailrc
> >>>(otherwise known as $HOME) and /acct.hp/username/.procmailrc.
> >>>
> >>>Hope that made some sense.
> >>
> >>Hmm.  Well, sendmail determines each user's HOME directory from
> >>/etc/passwd.  That (his HOME) is where the user's .procmailrc should
> >>reside.  How does that relate to the two user worlds?
> >
> >
> > On an HP, their home directory would be /acct.
> >
> > On a linux box their home directory would be /acct
> >
> > On an SGI their home directory would be /acct
> >
> > The problem is, none of those are the same files system. :(
> 
> Did you ever see my responses?  I repeat:
> 
> You can set up the "ForwardPath" option in the sendmail.cf file to
give
> a list of directories to search for the .forward file.  For example,
> this line:
> 
>      O ForwardPath=/usr/local/etc/forwards/$u.forward:$z/.forward
> 
> If the incoming mail was for user "fred", that line would cause the
> system to first look for a "/usr/local/etc/forwards/fred.forward" file
> If found, it is used.  If not, it tries to find a ".forward" file in
> fred's home directory.  The system defaults to:
> 
>      O ForwardPath=$z/.forward.$w:$z/.forward
> 
> "$z" is filled in with the user's home directory after sendmail does a
> getpwent()-style call, "$w" is filled in with the host name of the
> machine running sendmail.

Sorry, yes, I got them and it helped.  I've just been really busy and my
mind is shot that and got pretty sick.  I find myself forgetting more
than I used to, like replying to email. *sigh*

After we did this, I discovered that sendmail needed some other changes.
Below are some excerpts I sent to the end users explaining why it broke
and how to fix their stuff.

Originally, we had "DontBlameSendmail=forwardfileinunsafedirpath" in the
sendmail.cf file.  While this allowed group and world writeable
directories .forward files to be read.  If those .forward files called a
program, it wouldn't allow them to execute.  So we changed it to
"DontBlameSendmail=forwardfileinunsafedirpath,
forwardfileinunsafedirpathsafe".  This allowed the .forward file to be
executed.

Next step was figuring out why we still got permission errors.  It turns
out that even with the sendmail.cf file set properly to allow .forward
to execute.  Sendmail still won't execute the .procmailrc if world write
is set on the file AND you aren't using the .procmail found in the $HOME
directory IF the file and/or parent directory is set to 777, 775 works.
Remember in LCAS2's case $HOME is acct.common, not acct.hp.

Since your .procmailrc is in your acct.hp directory, you need to modify
your .forward file in acct.hp to look something like this:

"|/usr/bin/procmail -t -m /acct.hp/<username>/.procmailrc"

 The -m turns procmail in to a general mail filter.  It also allows you
to use any .procmailrc file you want.  But that file and it's parent
directory must not have world write.  If they do, it won't work.

Inside the .procmailrc, you need to make sure $HOME is changed to
/acct.hp/username otherwise the path's won't resolve properly for those
with HP accounts.