From procmail-bounces(_at_)lists(_dot_)RWTH-Aachen(_dot_)de Mon Jan 24
07:51:40 2011
Date: Mon, 24 Jan 2011 05:42:22 -0800
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
From: PSE-L(_at_)mail(_dot_)professional(_dot_)org (Professional Software
Engineering)
Subject: 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>
Yeah, well. My .procmailrc is close to a thousand lines long, with *LOTS*
of variable usage. I wasn't going to inflict _that_ on the list. <grn>
I've been using procmail for _decades_, literally, and this is the first
time I've failed to understand what it was talking about.
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.
I know. It's a matter of personal preference.
* $ ^Received: from [^ ]* \( *[^[].*${MAILHOST}
DELIVERABLE=|/bin/echo /home/bonomi/{{filename}}
Would you mind explaining what you THINK this is accomplishing?
I -know- exactly what it's doing. and it does the job just fine. <grin>
I'm examining the Received line added by _my_ external-facing mailserver, and
ensuring that there _was_ a rDNS entry for the IP address that connected to
it. The Received line is formatted as:
Received: from {heloname} ({rDNSname, if any}[{IP address]) by {server}...
Aside: occasionally, a rDNS name comes back with leading whitespace (it
*shouldn't* but _does_)
The " [^ ]* " matches the white-space-bounded heloname,
the "\( *[^[]" matches the start of the parenthetical information (with or
without the 'incorrect' whitespace), *IF* a rDNS name is present, (i.e.
it does *not* match "([", "( [", or similar variations)
and ".*${MAILHOST}" ensures that I only look at the received line that
my $MAILHOST added.
The action sets a variable specifying where the message should be filed.
I have a collection of actions that I take _only_ on 'deliverable' mail,
and not on spam. By coding this way, and using 'else' chains in the match
recipies, I can code that collection of actions _once_, as a block action
on a recipie that checks for a common characteristic in what ${DELIVERABLE}
is set to.
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?
Yeah, _everything_ incoming gets delivered 'somewhere'. I run statistical
analyses every once-in-a-while on the incoming spam.
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.
I'll have go go check logfiles, but that sounds very reasonable, and likely.
Practically all the legitimate mail I get is relatively small stuff. Except
for one mailing list that goes through _this_ rule.
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.
I thought of that, but it just covers up the problem, rather than fixing
it.
Given the way I'm doing things,
"echo {foo}; cat >/dev/null"
should do the trick.
And/or rethink how you're setting your variable. Why are you using echo?
"As opposed to?" <grin>
The only other way I know of to do it is along the lines of:
: 0
* <<condition>>
{
VARIABLE=value
}
____________________________________________________________
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