At 16:19 2003-10-21 -0500, Chuck Campbell wrote:
I looked at the Generic listname identification recipe, and I was a bit
baffled by things there I did not understand at all.
There are a variety of mechanisms which lists use, and the one recipe
attempts to identify several at once. It also endeavours to eliminate
"owner-" type prefixes and the like.
:0:
* ^X-Mailing-List: \/[^(_at_)]+
{
LISTNAME=$MATCH
}
NO lockfile necessary there
:0
* ! LISTNAME ?? ^^linux-kernel^^
linux-kernel
Lockfile needed here
procmail: Extraneous locallockfile ignored
I'm not sure, but maybe I just need to match linux-kernel in htthe first
recipe, instead of the \/[^(_at_)]+ regexp?
That doesn't make it very generic, does it? That \/ bit (as per the
manpages) "captures" the matching text which follows it into the $MATCH
variable where it can subsequently be utilized. For instance, your second
recipe could be written as:
:0:
* ! LISTNAME ?? ^^linux-kernel^^
$LISTNAME
(note lockfile flag). If you end up having several lists you know get
matched by the listname extraction recipe, you can handle them all in one
recipe:
:0:
* ! LISTNAME ?? ^^(linux-kernel|procmail|some-other-list)^^
$LISTNAME
Note how the action line remains constant, specifying the delivery mailbox
name to be the same as the listname component.
I believe I also mentioned it in one of my earlier discussions on the
topic, but since LISTNAME is only set in my rules if the message appears to
be a list message, I can use that to my advantage when scanning for spam,
by giving more allowance to lists because of topical content, etc.
---
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