procmail
[Top] [All Lists]

RE: Recipe Suggestion

2007-09-29 05:56:42
I was wondering if you might take a look at this recipe that I have
crafted from different messages on this list.  I am still trying to
get my head around all the procmail flags etc.  Things seem to be
working, with the exception of the SpamAssassin section.  Spam with a
13 score (or whatever the number of stars I put in) is directed to a
folder named devnull (for testing at the moment, in the future it will
go to /dev/null).  The rest of the spam designated does not go into
the spam folder, it by passes and ends up in the Sites folder.  There
is a whole commented out section dealing with myspace mails/form
mails.  I am a technology teacher and need to do some monitoring of
myspace for my school.  Those emails aren't doing what they should be
doing either.

I'm interested in how to get this to be more efficient, if you think
the order of the recipe is right... and any (quite possibly) stupid
errors I made.  Any suggestions would be greatly appreciated.  I get
so many emails I need to get this to work to help me out.

A fair bit of it looks competent enough to me at a quick glance.
Regarding style, I would amalgamate up near the top the parsing of 
headers you're interested in evaluating further down below.
For example, you do some Subject stuff up-top and then later
bother to find and save the value of Subject: to a variable.
I'd save all the vars I was interested in early on and then
evaluate them.  You could also use more data abstraction with vars
so you don't have to repeat ugly and near incomprehensible
(at first glance) regex phrases such as this --

        [^ <@]+(_at_)[^>]+

(you have nearly the same thing a couple of times).  Note that
in 6+ months when you go back and look, you'll be glad you
abstractified that and can re-grok your algorithm without sweating
so much.

I've gone to writing a flowchart for my more complex rcfiles
and putting common abstractions in INCLUDERCs.  Yes, it's another
file read, but I think it's worth it, and I've proven to myself
that it gets cached and is damn fast enough that way.  It makes
the programmer's life much easier.  If you object philosophically
to using a number of INCLUDERC calls, you could still have them
but use a script, perhaps crontabbed, to paste the "makefile" subparts
together into a working rcfile.  But personally, I don't find that
at all necessary.

  LOGFILE     = "$_.log"

Have you tested this?  It may need to be:

   LOGFILE     = "${_.log}"

That is because of an anomaly with the reading of
vars with leading underscores.

  :0
  * ^Subject: .*SEXUALLY.*
  /dev/null

You don't need the trailing ".*" on the condition.  It
works exactly the same without it.


Good luck.  Looks like you're thinking in the right
direction and just need to get the details further
hashed out.

-- 
dman
____________________________________________________________
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

<Prev in Thread] Current Thread [Next in Thread>