l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2004 Oct 15 14:09

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
[vox-tech] procmail problem SOLVED (was: procmail question:filtering message mangles headers)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vox-tech] procmail problem SOLVED (was: procmail question:filtering message mangles headers)

Hash: SHA1

På fredag, 15 oktober 2004, skrev Peter Jay Salzman:
> On Fri 15 Oct 04,  7:33 AM, Henry House <hajhouse@houseag.com> said:
> > I have the following procmail recipes to create a makeshift mailing list:
> > 
> > :0:
> > * ^To:.*m10-update
> > * !^X-Loop: m10@houseag.com
> > * ^Received: from wotan.hajhouse.org   # accept messages from my host only
> > {
> >       :0c
> >       updates.mbox
> > 
> >       :0fh
> >       | sed -e 's/^Subject: /Subject: \[M-10\] /'
> > 
> >       :0
> >       ! `$HOME/_sendmails`
> > }
> > 
> > The first recipe in the bracketed block archives to a mailbox and the third
> > forwards the message to the list of addresses produced by the script
> > _sendmails.
> > 
> > The second recipe is supposed to tag the subject header of incoming messages to
> > make them easy for their recipients to identify, just a many mailing lists do.
> > It does not work! Instead the messages are mangled---the subject is completely
> > blank and the To: and From: headers are re-written. This does not happen when I
> > comment-out the second recipe.
> > 
> > Offhand, I see no reason for this difference in behavior either in the
> > recipes or in the logfile. Clearly I am missing some subtlety. Can anyone
> > enlighten me?
> Probably not, I'm afraid.
> Clearly, your sed line is correct.  Total shot in the dark:
> 1. Isn't an email considered delivered when it hits a recipe?  Don't you need
>    a "c" on that 2nd recipe?

The 'f' flag implies 'c' and additionally causes the following recipes to run
on the captured output of the subprocess:

   Non-delivering  recipes are: those that cause the output of a program or
   filter to be captured back by proc mail or those that start a nesting block.

   You can tell procmail to treat a delivering recipe as if it were a
   non-delivering recipe by  specifying  the `c'  flag  on such a recipe.  This
   will make procmail generate a carbon copy of the mail by delivering it to this
   recipe, yet continue processing the rcfile.

   source: procmailrc(5)

> 2. How about sending the output of the 2nd recipe to an mbox to make sure
>    that the 3rd recipe isn't doing anything funky?
> Pretty mysterious --- I agree!

Okay, I solved it. 

- - if you have any of the characters in $SHELLMETAS in the string after the pipe
  character, procmail passes that string to a shell to execute.

- - the default value of $SHELLMETAS includes '[', which my filter recipe included:
     | sed -e 's/^Subject: /Subject: \[M-10\] /'

- - the user under which procmail ran had /bin/false as its shell for security

So of course the shell could not execute the command string. Since shell
interpretation was not actually needed or desirable in this case, I set
SHELLMETAS="" and the recipe works!

I figured this out by adding the w flag to the filter recipe, which causes
procmail to check the subprocess's exit code and complain if it is nonzero. It
did. Then I saw that the verbose log showed 

   procmail: Executing "sed -e 's/^Subject: /Subject: \[M-10\] /'"
   procmail: Program failure (1) of "sed -e 's/^Subject: /Subject: \[M-10\] /'"
   procmail: Rescue of unfiltered data succeeded

whereas it shows this if procmail executes the subprocess directly without a shell

   procmail: Executing "sed,-e,s/^Subject: /Subject: \[M-10\] /"

i.e., with commas separating the arguments instead of spaces.

I consider myself lucky to have figured this one out---that answer was really

- -- 
Henry House
Please don't send me HTML mail! My mail system will reject it.
The unintelligible text that may follow is a digital signature.
See <http://hajhouse.org/pgp> to find out how to use it.
My OpenPGP key: <http://hajhouse.org/hajhouse.asc>.

Version: GnuPG v1.2.4 (GNU/Linux)

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.