On Fri, Sep 26, 2003 at 09:44:14PM -0500, Michael D Schleif wrote:
I observed something weird, so I did this:
:0
* -2^0
* 1^0 > 240000
* 1^0 > 140000
* 1^0 < 165000
Now, in my logs I get this:
procmail: Score: -2 -2 ""
procmail: Score: 1 -1 "> 240000"
procmail: Score: 1 0 "> 140000"
procmail: Score: 1 1 "< 165000"
Wow! Every single file qualifies ;>
What am I missing?
The answer is that scoring syntax is not compatible with
the special size tests ( > or < ) that we can alternatively
use. This is just one of those things one learns about
procmail (and then forgets, and has to learn again).
In my recently published virussnag.rc file there is an
example of size-checking. I had to do the check without
weighting (scoring) the results, for the reason stated.
* > 50000
* $ $GO^0 CTYPE ?? ^^(attachment|multipart)
* $ $STOP^0 CTYPE ?? /report^^
* $ $GO^0 VFROM ?? MAILER-DAEMON
* $ $GO^0 VFROM ?? Lyris ListManager
If you really want to give a score, you can do it, albeit
more convolutedly than you had in mind:
:0
* > 240000
{ SCORE = 1 }
:0 E
* > 140000
{ SCORE = 1 }
:0
* < 165000
{
:0
* $ $SCORE^0
* 1^0
{ SCORE = $= }
}
There are other things one can do, too, to get around the
limitation. For example, here is something from my .procmailrc:
:0: # 030404 () if body within limits, delete instances of list noise
* SUBJECT ?? ()\<(remove|unsubscribe)\>
* ! SUBJECT ?? ^^(Fw(d)?|Re):
* 350^0 CTYPE ?? (html|multipart)
* 500^0
* $ -$MAXINT^0
* -1^1 B ?? > 1
* $ $MAXINT^0
$TRASH/listnoise
The penultimate condition gives a weight of the negative of the size of
the body. It also uses my previously described "infinity skip" method
to minimize the impact of counting bytes of very large messages. The
recipe is part of what I use to get rid of "unsubscribe" messages that
occasionally come to this list.
Here's another from my .procmailrc:
:0 # 030603 () deliver read-receipts
* $ SUBJECT ?? ^^$DISPOSITION\>
* $ $GO^0 CTYPE ?? ^^multipart/report
* $ $GO^0 TO ?? ()\<$MYFORENAME[$WS]
* B ?? < 2500
* $ 1^0 B ?? ()\<$DISPOSITION\>
* -2^1 B ?? ()\<remove(d)?\>
{ SWITCHRC = $SPOOL }
Keep in mind that when you mix weighted and unweighted conditions,
all weighted conditions are processed before any unweighted condition
is looked at. I mention this only because it might be a consideration
when deciding on a particular algorithm. I try, when I can and when
I think of it, to minimize server load at all times. (Here I may
not have thought hard enough about that.)
The point of the recipe is that I don't want to run read-receipts
(which I usually request when I send mail out with Outlook) through
my virus- or spam-check routines. I send them right to my inbox
if they look kosher according to the above cursory checks.
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail