procmail
[Top] [All Lists]

Prioritizing matching of "best" header

2004-09-10 23:38:05
While working on my mailing list sorting rules, I wanted to grab a header that would uniquely identify each list on a consistent basis. I want to extract a unique string, based on a match of the "best" header . I started with this scoring rule, mistakenly thinking the order of my recipe lines was significant:

:0
* 9876543210^0 ^Delivered-To: mailing list \/.*
* 9876543210^0 ^List-Id: +\/.*
* 9876543210^0 ^List-Unsubscribe: \/.*@
* 9876543210^0 ^(X-)?Sender: \/.*
* 1^0 ^From: +\/.*
{ [...]

In experimenting and re-reading man procmailsc, it's (now) clear that the FIRST matching header causes the rest to be skipped. The problem is that different messages from the same group may have several headers that match, in unpredictable order, so the same list may yield different identifying strings in $MATCH.

Not a problem. My first instinct was to set up several "ELSE" recipes, like so:

--- cut here --- cut here ---
:0
* ^Delivered-To: mailing list \/.*
{
   LISTNAME=$MATCH
}

:0 E
* ^List-Id: +\/.*
{
   LISTNAME=$MATCH
}

[...]
:0:
[do something based on $LISTNAME]
--- cut here --- cut here ---

in descending order of the preferred "most authoritative" (IMHO) header to select.

This just seems a bit cumbersome. I found that a single, nested rule would work:

--- cut here --- cut here ---
:0
* !^\/Delivered-To: mailing list .*
{
       :0
       * !^\/List-Id: .*
       {
               :0
               * !^\/List-Unsubscribe: .*
               {
                       :0
                       * !^\/(X-)?Sender: .*
                       {
                              :0
                               * ^\/From: .*
                               {
                                    LOG="No better header, so we use From:"
                               }
                       }
               }
       }
}
LISTNAME=$MATCH
LOG="Matched $LISTNAME"
--- cut here --- cut here ---

While it works, I'm wondering if using $MATCH to capture a NON-MATCHED string like this is reliable. I like the fact that the latter is a single (nested) rule, which to me makes the flow easier to follow. After lurking on this list, it's also clear some folks "get" procmail much better than I, so I'm very open to cleaner alterantives.

(These are test fragments: I know they're hideous and inconsistent!)

Any feedback appreciated.

- Bob




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