Man, CHOCK full of meat! I wish now I'd seen this reply before I did the
other tinkering!
Quoth Philip Guenther <guenther(_at_)gac(_dot_)edu>:
"Tom Betz" <tbetz(_at_)panix(_dot_)com> writes:
I posted a few days ago about 8MB core dumps I'm getting, with the
INCLUDERC recipe that causes the dumps. I've played with it some
more, and this is the current version:
Have you done a stack backtrace from the core file? You may need to
recompile with debugging to get any useful info from a debugger, but
that would also be a chance to turn *off* optimization: some compilers
generate incorrect code when optimizing procmail, and if the problem
goes away when compiled sans -O then there's your problem. What plaform
on you running this on?
I haven't done any of this, because (as I mentioned before) I'm using the
procmail provided by my ISP, and didn't compile it myself... all I have to
go on is the procmail log itself (but that is subject to change as I dig
deeper, I suspect.)
I *strongly* suggest recompiling procmail without -O and with -g,
then if it continues to coredump, get a backtrace a go from there.
(You're using procmail version 3.11pre4, right?)
Nope, 3.11pre4. Should I nag?
If all the delivering recipes inside a nested block have the 'c' flag,
then there are no "delivering recipes" and procmail will keep
processing past the block. About the only time you need the 'c' flag
on a nested block is when who need to filter a message for some
processing, but still keep around the original for latter processing.
That's what I thought, thanks for the confirmation.
Is there a way I may instruct procmail to complete one recipe before
launching the next one, so they run and release memory sequentially?
If there is memory and/or swap left, then it shouldn't
coredump unless there's a bug somewhere to be tracked down and
eliminated or worked around.
Thanks. I suspect the bug theory, myself.
Now some comments on your recipes:
#
# Handle potentially Junk E-Mail from mailmasher.com
#
# Match on any email to or from mailmasher.com
:0 H
* (^Return-Path:|^Received:|^Message-ID:|^Reply-To:|^From:).*[(@
](mailmasher\
.com)
{
The 'H' flag is the default, and we can do some 'factoring' on that
regexp:
:0
* ^(Return-Path|Received|Message-Id|Reply-To|From):.*[(@ ]mailmasher\.com
{
BTW: do you ever close this nested block?
Yes, I do. I may have inadvertenly deleted it in the cut+paste
reformatting (unwrapping long lines that Pegasus wrapped, etc) into my
mailer... but the actual recipe does close that block.
# log all matches
:0 c
mm_junk.log
Perhaps you should have a locallockfile on that? How important is the
integrity of this 'log'.
It's an "evidence" file -- I guess I should have one. I like having a
file, separate from the normal LOGFILE, in a format that I can just point
'elm -f' at and clean up easily later.
If you just want to log things, perhaps you
should just set LOGABSTRACT to "all" and use the normal LOGFILE to keep
track of things.
# Is the complaint feature turned on?
:0 c
* COMPLAIN ?? on
{
# if so, first make a temporary copy of the email
:0 c
| cat > $MAILDIR/spam.tmp
# then form a reply from just the header, with appropriate
substitutions; con
catenate an autoresponse
# message on the end of it; add a copy of the original email, with
full head
ers; then add a .signature
# and email it back to sender and to a fixed list of Cc: addresses
:0 ch
| ($FORMAIL -rk -i"Subject: HI, MailMasher user! I'll get back to
you." \
-i"Errors-To: tbetz(_at_)pobox(_dot_)com" -i"Reply-To:
tbetz(_at_)pobox(_dot_)com" \
-A"X-Loop: tbetz(_at_)panix(_dot_)com" -i"Cc:
tbetz(_at_)pobox(_dot_)com,numnuts(_at_)mailmasher(_dot_)com" -X
""; \
cat $PMDIR/autoresponse.mm $MAILDIR/spam.tmp; \
echo "";\
echo "-- ";\
cat $HOME/.signature \
) | $SENDMAIL -oi -t
}
# Indicate that a match was found -- the value of $FOUND is later
# assigned to $DELIVER
FOUND=on
}
Actually, the setting of FOUND will *never* be noticed by later recipes:
the variable is set in the child process of the fork and is thus never
seen by the parent which processes the rest of the .procmailrc.
I have noticed that recently, when (having managed to get through the whole
.procmailrc) DELIVERED was not correctly set... in fact, after having
asked the question, I realized that the 'c' flag was useless there, and had
already removed it.
Next, you need to do some locking in the above to keep simultaneous
messages from overwriting spam.tmp before the complain goes out.
Since this is between multiple recipes you have to the the global
lockfile variable LOCKFILE.
You could also use some more paranoia, but that's because I'm a sysadmin.
# Is the complaint feature turned on? (Use ^^on^^ for paranoia.)
:0
* COMPLAIN ?? ^^on^^
* ! ^X-Loop: tbetz(_at_)panix(_dot_)com
{
# Is the incoming message too big to deal with? If it's larger than
# 1 Meg then something bogus is going on, possibly a Denial Of
Service
# attack. Just drop it on the floor. Alternatives to /dev/null'ing
# include using "head" to extract the first N characters (*not*
lines)
# but you need a newer version of "head" that has the -c flag for
that,
# or you can simply move your message from the top of the body to the
# bottom, as that doesn't require a temporary file to hold the
original
# body. If they expect you to read the entire message, why shouldn't
# you do the same of them? You'll need to rewrite this entire recipe
# if you do.
:0
* > 1048576
/dev/null
LOCKFILE = $MAILDIR/spam.tmp.lock
:0 c
|cat >spam.tmp
# There are some occasions where setting FORMAIL to the full path to
# formail makes sense, but usually it's easier and better to just
make
# sure PATH contains the correct directory. a) Never hardcode a path
# that can break in the future (just wait till formail is moved to
# /usr/bin); and b) let the computer do the work. But that's just my
# opinion...
# I've also left off both the -k and the -X "" args, as they cancel
# each other. In fact, since you included the 'h' flag on the
recipe,
# the -k wouldn't have done anything to begin with.
:0 ch
| (formail -r -i"Subject: HI, MailMasher user! I'll get back to
you." \
-i"Cc:
tbetz(_at_)pobox(_dot_)com,numnuts(_at_)mailmasher(_dot_)com" \
-i"Errors-To: tbetz(_at_)pobox(_dot_)com" -i"Reply-To:
tbetz(_at_)pobox(_dot_)com" \
-A"X-Loop: tbetz(_at_)panix(_dot_)com"; \
cat $PMDIR/autoresponse.mm $MAILDIR/spam.tmp; \
echo ""; echo "-- "; \
cat $HOME/.signature \
) | $SENDMAIL -oi -t
# Remove the lockfile
LOCKFILE
### Indicate that a match was found -- the value of $FOUND is later
### assigned to $DELIVER
# What's this variable "$FOUND". The variable is named "FOUND", and
# you don't assign to $DELIVER, you assign to DELIVER. The name is
# not the object, and in this case, the interpolation is not the
# variable!
Verzeihung, Herr Professor! ;^)
Sloppy writing, hasty commenting.
BTW: do you mean the magic variable DELIVERED?
Yep -- in fact, despite the error in the comments, the last line in the
actual .procmailrc is
DELIVERED=FOUND
I really appreciate your help with this... even more than the
documentation, seeing the mind behind procmail employing it in a task the
purpose of which I pretty much understand helps me to understand procmail
itself a lot better.
I guess I gotta get off the digest -- having this message earlier would
have prevented my later, more embarassing
mistake with the 'f' flags.
--
|We have tried ignorance for/ Tom Betz (914) 375-1510 |
|a very long time, and it's/ Want to sent me email? Read this page: |
|time we tried education. /<http://www.panix.com/~tbetz/mailterms.html>|
|<http://www.pobox.com/~tbetz>| I mock up my reactive mind twice daily.|