dman writes:
Jeff Orrok <jeff(_at_)rt(_dot_)com> wrote:
Hello, I am having a few problems with the "centerpiece" of my .procmailrc
1) Usually it works, but approx 5% of the time, it will let addresses
not on my whitelist slip through.
2) When it works, the autoresponder usually gets the message off, but
once in a while, I get the Error while writing to "x" message listed
in the procmail man page. My interpretation of the man page leaves me
with "pipe died" as the only possible cause. Why would the pipe die?
I haven't studied the rc snippet you supplied. But from your description,
the first thing I'd suspect is that you've run out of memory. Increase
the value of LINEBUF near the top of your rc.
Ok, I've set LINEBUF=4096 now (double the default). I'm still getting the
errors. I was not under the impression that LINEBUF controlled memory in
general, and my calculations of the length of the command line over all of the
continued lines, is that it shouldn't be much more than 1024. Is there any way
to get it to print out the line after all of the variable substitutions and
whatnot have occurred?
Next, turn on verbose logging and look at the errors, if any remain after the
above.
Oops forgot to turn VERBOSE back on. But anyway, the last time I did that,
there was no indication what the problem was. Just a cryptic Error while
writing to "alltheactionlinetext". Nothing ever goes into the REPORT variable.
Nothing ever goes into the 2>> ERROR${LASTMSG} redirects. I have to run cron
every night to clean out dozens of zero length ERRORmsg.xxxx files. I'll post
some verbose output tomorrow.
4) When the autoresponder succeeds, I would expect processing to be
complete, but there is always another copy left over, which is why I
have the blacklist recipe at the end.
I wonder if this is a separate issue, masked by the first.
I'm not sure how the first issue masks this one, because I get the same sort of
"message echo" when my munpack recipe (that I just posted to the list for the
newbie guy) fires. All the attachments get squirreled away where I want them,
but then a copy of the original message shows up in my /var/spool/mail/file as
if nothing had happened.
5) In case you're wondering, the echo's are there because formail
refuses to add those fields no matter which flag [AaIi] I use :-(
You've certainly got some syntax issues going on. I won't study
the below intently (no time), but will give a couple of quick ideas.
Well if you or anyone gets the time, I could use another pair of eyeballs --
I've looked at it at least a half dozen times, but formail just doesn't want to
cooperate.
:0D
* ^To: .*REDEEM\/msg\(_dot_)[^(_at_)(_dot_)/]+
| cat $MAILDIR/nonwhitelist/$MATCH >> $MAILDIR/review
The action seems to have nothing to do with the contents
of the message. So use the `i' and the `h' flags to help
procmail out.
Good point. I also added a trailing colon.
:0B:
* ^X-Loop: procmail(_at_)lastname(_dot_)com
blacklist
What does the X-Loop have to do with the body of the mail?
It seems as if this recipe will never trigger.
I was getting messages from some Mailer Demon that stripped off my X-Loop from
the headers, but had the entire original message including headers in-lined in
its message body.
:0
* ^To: \/.*
* ! ? formail -rzxTo: | fgrep -iwqsf $HOME/whitelist
* ! ? formail -rtzxTo: | fgrep -iwqsf $HOME/whitelist
This seems horribly inefficient; but I don't have time to
think up a better way.
Yes it may well be, but it does what I want :o) Or I should say, it usually
does what I want. It's easier for me to keep my whitelist in a separate file
that I can just cat >> into rather than edit my .procmailrc all the time. It
would be really cool if I could get fgrep to say which line in the file it
thought it was matching.
{
SENTTO="$MATCH"
:0c:
nonwhitelist
# cron will delete nonwhitelist messages after they are one week old
LASTMSG=`echo $LASTFOLDER | sed -e "s#.*/##"`
Lots of these pipes could easily be done inside procmail. You'd be
less likely to suck up your buffer space that way, too.
:0 hi
* LASTFOLDER ?? ^^\/.*#
{ LASTMESSAGE = $MATCH# }
Again, I'm confused about "buffer space" -- my reading of the man page said
that the buffer was merely what held the next command line from the .procmailrc
-- not a heap or anything like that. Could you clarify? Your rewrite of my
string manipulation looks like you're going to give me everything from the
start of $LASTFOLDER up to the first #. There are no #'s. sed uses the char
after the s as the delimiter. I want everything after the *last* / ie just the
filename, not the path. I am afraid that * LASTFOLDER ?? .*/\/[^/]+ would
confuse the parser.
:0W
* !^FROM_DAEMON
* !^X-Loop: procmail(_at_)lastname(_dot_)com
REPORT=| (formail -q- -r \
-XSubject: \
-XTo: ; \
[deleteded rest]
I'd think hyou could algorithmically combine this formail -r with one
or both of the others up-top.
I was borrowing from someone else's example, who had one recipe for non-demon
senders, and another for demon senders. If it's from a demon, I don't think
there's any point asking it to validate that what it sent me isn't spam.
The train of thought behind this block of recipes was this:
0) all the stuff in .procmailrc up to this point: handle all of my special
purpose email addresses first; pretty much all that's left now is generic mail
coming in to me.
1) handle replies to the autoresponder: move corresponding original message
from nonwhitelist holding area to review holding area
2) throw away bounces from the ill-behaved mailer demon
3a) capture who they were sending to (I realize my address won't appear here if
I was CC'ed or Bcc'ed)
3b) check both the From_ and From: fields because I got careless when I built
my whitelist
4) write a copy to nonwhitelist
5) if not from a demon, fire up the autoresponder
6) if from a demon dump into my demon review holding area
Jeff
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail