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.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail