At 12:18 2003-07-14 +0200, Frode Lillerud wrote:
My .procmail looks like this:
Well, that's a potential issue. It should be ~/.procmailrc, if you're
talking about the rcfile which procmail automatically invokes for new
mail. If you're talking about some other rcfile, please explain the EXACT
form in which you are invoking procmail, since it better describes the
environment in which you are running your rcfile.
#### .procmail ####
MESSAGE = `formail -f`
:0fhw: spamwizard.lock
| formail -t -X ""; /www/lillerud.no/spamwizard.pl $MESSAGE; echo
I use fetchmail to get mail from a very large mailbox (500+ mail) and this
gives the server a lot to work with.
"Everytime a new mail arrives" implies that procmail is being invoked
during the LDA phase, which means it should simply be handed THE
message. No fetching the message from whatever size mailbox you think you
may have. If you're running it via a formail splitting invocation, then
this IS NOT being invoked for new mail.
How about you endeavour to explain what it is you're doing at each step of
the way -- it certainly appears that you're trying to pass THE CONTENT OF
THE MESSAGE on the commandline to your program. The only plausible
explanation is that you're smoking some bad ganja, which perhaps your cat
pee'd on a few months ago.
Why the -t parm to formail anyway? You're not extracting any headers (say
for auto-reply), and the best I can figure is that the '-X ""' might do is
deal with killing the body portion of a message if you invoked formail with
a complete message, but you're using the 'h' flag anyway, so that's not
going to happen. Please explain what made you decide to run formail here
and with those arguments.
Please, also take a moment and explain each step of your rcfile and why
you're doing things the way you are. why the 'echo' at the end of the
filter, and how does this recipe actually succeed in filtering your
message? I assume your perl script is emitting a modified header?
Before I added the .lock-file to procmail it would run 20-30 versions of
spamwizard at the same time.
If you're trying to process an existing mailbox (which should NOT be the
smame file which procmail is delivering into), you should be splitting the
mailbox with formail, which has a throttle option:
formail -n 5 -s procmail -m reprocessor.rc < moved_mailbox
HOWEVER, the "-n maxprocs" bit shouldn't be necessary - formail should be
invoking ONE process and waiting for it to complete before invoking the next.
Now the problem is this; After a while it seems that the variable $MESSAGE
suddenly contains the name of the files in my /root directory!
Have you considered that you're running out of system resources and
something in your invocation is barfing as a result? Owing to the
"pass-the-potentially-enormous and even more potentially malicious file
content on the commandline" invocation above, I'll shoot for the
commandline invocation giving you grief. Methings all a body needs to
contain is:
/*
(Commonly seen in C-language source code comments, but also seen
elsewhere), and your invocation is going to do bad things.
Ever stop to wonder what would happen if `rm -r ~/*` were found in a
message body?
Has anyone seen similar errors out there?
Never. I don't pass body content as a commandline parameter. Please
explain why you do, instead of using a standard FILTER operation.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail