Re: inconsistent recipie failure

At 02:38 2011-01-24, Robert Bonomi wrote:

>Relevant ~/.procmailrc fragments

You might be surprised at how much of the irrelevant fragments play a role <g>

>   MAILDOMAIN="r-bonomi[.]com"

More typically, one escapes a dot when one wants it treated as a literal:
         MAILDOMAIN=r-bonomi\.com

Yes, you character class will evaluate the same in the end, but it's 
not the more commonly used method.

>     * $ ^Received: from [^ ]* \( *[^[].*${MAILHOST}
>     DELIVERABLE=|/bin/echo /home/bonomi/{{filename}}

Would you mind explaining what you THINK this is accomplishing?

>Every once-in-a-while, for no reason that I can ascertain, and with no
>apparent commonality in the messages involved, the following happens:

The ones you don't have problems with are all small messages, and the 
ones you do, are larger - they exceed a certain buffer size, and 
procmail detects that echo isn't reading all of the message procmail 
is putting on the pipe for it, and therefore expects the app choked.

It should be consistently reproduceable if you sandbox with one of 
the messages which has failed.  Are they eventually delivered to a 
mailbox?  Check the delivery summary lines in the procmail log - the 
number that trails the subject line text is the size of the 
message.  The pattern should be quite evident.

>   procmail: Error while writing to "/bin/echo"
>   procmail: Rescue of unfiltered data succeeded

>Does _anybody_ have any idea what might be going on, and how to fix it??

Quick solution: add an 'i' to the flags.

And/or rethink how you're setting your variable.  Why are you using echo?

---
  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.