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

[Henry House]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

På fredag, 15 oktober 2004, skrev Peter Jay Salzman:
> On Fri 15 Oct 04,  7:33 AM, Henry House <hajhouse at houseag.com> said:
> > I have the following procmail recipes to create a makeshift mailing list:
> > 
> > :0:
> > * ^To:.*m10-update
> > * !^X-Loop: m10 at 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
obscure.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBcABli3lu92AVGcIRAoz2AJ9x/1TuZiJLVzLuy9T/L4+KAxfTZgCdHMVF
w9mHMtwgslYP9IgXiUCBoX8=
=ofQJ
-----END PGP SIGNATURE-----