procmailrc question

Rick Stevens rstevens at vitalstream.com
Wed Mar 30 19:29:55 UTC 2005


Waldher, Travis R wrote:
>>-----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*

Ah, senior moments!  I have them frequently!

> 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.

Cool.  Glad I could at least aim you in the general direction.

> 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. 
> 
> 
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request at redhat.com
> Subject: unsubscribe
> 


-- 
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-  The problem with being poor is that it takes up all of your time  -
----------------------------------------------------------------------




More information about the Redhat-install-list mailing list