On Fri, 2004-02-06 at 00:35, Professional Software Engineering wrote:
<snip>
Either lose the scoring SCORING aspect, and just invert the conditions (all
conditions need to evaluate TRUE, that is NOT the lists):
* ! procmaillistcondition
* ! postfixlistcondition
* ! evolutionslistcondition
{
# do stuff
}
In a normal conditional evaluation, all conditions have to be true
before the code within the bracses is executed, or at least that's what
I understand. So the code above, #do stuff will execute as long as none
of the messages are for any of the three lists. No problem there...
or, use a NEGATIVE maximal value ('minus infinity', which for procmail is
anything larger than negative 2^31) in your scoring, but DO NOT invert the
list check (thus, if the list condition is met, the scored conditions stop
being checked and it skips the recipe). This is more efficient, since
condition evaluations stop as soon as any one of the conditions is found to
be true. Ordering the checks in order of list traffic levels allows you to
tweak the performance ever so slightly: if you receive 100 procmail
messages a day, five postfix messages, and one evolution message, you'd
want to order it so that the procmail list is checked first, since MOST
messages would match that condition and continue past this recipe right
away without wasting the (nominal, for sure) cycles on the other
checks. If you put evolution first, then the 100 procmail messages would
have to check that condition, fail it, and then check the procmail
condition and succeed on it. Minour optimization for sure, but in any
event, this is more efficient than the alternative above, which will check
all conditions for ALL messages.
* -9876543210^0 procmaillistcondition
* -9876543210^0 postfixlistcondition
* -9876543210^0 evolutionlistcondition
{
# do stuff
}
This one I'm having a problem with. If it works as you've said, won't
the code in the braces execute if any of them are true?
As an alternate approach, why couldn't you simply have three different
recipes preceding the virus and spam code that deliver the maillist
message to an Inbox listed in order of mail volume as you've suggested?
Because I use Evolution, I have all incoming messages delived to one
maildir/, and then the filters in Evo separates them into their
respective folders. The only reason I do this is because Evo can't
handle a separate maildir/ for each Folder name.
I'm thinking it would be as efficient as the scoring method, as a
maillist email would only go as far as the matching condition, and not
continue through any other evaluations.
signature.asc
Description: This is a digitally signed message part
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail