procmail
[Top] [All Lists]

Procmail based thread watch - A review for gotchas please

2002-02-07 20:29:28
Doing some experimenting lately that is aimed at delivering incoming
messages that contain a reference to certain mesg ids to two
destinations.

My procmail usage is pretty primitive.  I just want to generate an
includrc with a perl script that puts a copy of certain messages in an
`urgent' or interesting type spool.

I'm wondering if there are non-obvious gotchas here that will bite me
in the butt later on.

I couldn't think of better way offhand, so decided to use an INCLUDERC
for the dynamically generated file, keeping it from effecting the
basic .procmailrc.  In this snippet from ~/.procmailrc, the comments
are to show intent for this mail message purposes.


[...]
  :0 c

## Everthing is sent thru another list of recipes (.spec_vars) and
## a different log records the action.  There must be a better way, I
## think.  But I wanted the recipies to be changed on the fly so
## didn't put the selection regex here in ~/.procmailrc


{
    LOGFILE=/home/reader/projects/proc/no_bak/.new_log
    INCLUDERC=.spec_vars
    LOGFILE=$HOME/t/var/log/procmail.log
}

[...] numerous other rules follow

========================================

Once a copy is diverted it runs into this recipe:
A list of ORed message ids to look for in reference headers

cat ~/spool/.spec_vars

        :0
        * References:.*(@reader\.newsguy\.com|other_msgid|other_msid)
        hotstuff.in

## I wondered if using several rules that point to the same infile
## instead of massive ORing in one rule,  will cause a big mess         
## And if many ORs if worse than several rules dividing the work

## Here for example only:

#        :0 References:.*(other_msgid|other_msgid)
#        hotstuff.in
#

## Originally this /dev/null rule was lacking and I started getting
## dups of everything that fell off the end of .spec_var.  That was the
## first gotcha...

        :0
        /dev/null


This script is generated by a perl script that I invoke inside my
mailreader.  It scans the headers for the message id and rewrites
.spec_vars accordingly.  It allows me to either add to or overwrite
the existing rules.

Aside from the mass of duplication in my first experiment I wonder
what other things I've overlooked.



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>
  • Procmail based thread watch - A review for gotchas please, Harry Putnam <=