First let me start by showing my appreciation to Sean and Bart for your long
answers.
I'll be the first to admit that I need more knowledge about both procmail
and formail.
As you correctly point out, the file is ~./procmailrc.
I have to admit that I just read a few .procmailrc examples on the net,
until alteret it until I got it to pass _something_ to my script. And
somehow formail seemed to make it work. The 'echo' part? Honestly I don't
know why it's there, but it seemed to make it work. The formail-flags used
didn't really seem to make a difference, so I focused on the perl-script. It
wasn't until now that I realized that things didn't work like it should.
The script I've written is a bayesian spamfilter (bet you've all read Paul
Grahams A Plan For Spam article) in Perl.
The way it works (now) is that it juggles the $ARG[] words around a bit, and
does a little dance with a mysql db and finally updates the mail header.
I have two large corpus of mail, one with ham and one with spam. To teach my
filter the difference between spam and ham I first start out with an empty
database, and use fetchmail to get one of the corpus. These 500+ mails
(eventually) reaches procmail and this is the process that starts about
20-30 versions of the perl-script.
I'm beginning to realize that I need to rewrite the way I use both
procmailrc and my perl-script. Instead of working with $ARGV[] I need to use
<STDIN> instead. No more of this environment variable passed as a command
line parameter.
What I want is to pass the entire message (header + body) to the perlscript,
and get it to alter the header. Possibly use an exitcode in a functionable
way.
Any hints on how I should set up my ~/.procmailrc? And do I need to use
formail? Perhaps this -n flags could be usefull.
Thanks
Frode
-------Original Message-------
From: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Date: 14. juli 2003 18:25:36
To: procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
Subject: Re: Serious error!? Procmail supplies filenames in /root as
arguments to script
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
.
IMSTP.gif
Description: GIF image
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail
IMSTP.gif