At 15:37 2004-02-11 +1100, Marvin Pierce wrote:
Spamassassin is using a lot of processing time due to the number of
procmail recipes I have. So, I'm trying to simplify recipes.
Will this extraction recipe for my rc.subscriptions put mail in the
correct box as named?
No, since you don't use $MATCH within the delivery action (and if you were,
you should use the locking flag).
Personally, I'm not terribly keen on using an address for a filename - it
isn't especially intuitive, and it's awkward to type, plus it's a longer
string when software (such as pine) displays a screen with mailbox
names. Your reliance upon ^TO_ also requires that the messages have the
list in cleartext (which is SHOULD usually be, but there's no guarantee).
You should review the generic list identification filter that's previously
been discussed on this list. I've published a copy of what I use at:
<http://www.professional.org/procmail/listname_id.rc>
(I just took a few moments and applied an optimization to that a short
while ago)
Using that, you could likely ID all of your standard lists like so:
INCLUDERC=listname_id.rc
:0:
* ! LISTNAME ?? ^^^^
mailinglist/$LISTNAME
I'm aware of one GLARING exception to the listname_id filter: the
webdesign-L list (@webdesign-l.com) -- the brainiacs who set it up used
"list" as a listname and "digest" for the digest name. Swift.
Any lists which are not properly identified can be handled in a simple
supplementary rule (say, between the INCLUDERC and the delivery
recipe). For example, the above mentioned webdesign lists:
:0
* LISTNAME ?? ^^(list|digest|)^^
{
:0
* ^Sender: owner-(list|digest)@webdesign-l\.com
{
LISTNAME=webdesign-l
}
# other corrective conditions - use (E)lse flag for this and all
# which follow.
:0E
* ^TO_block1list(_at_)sfgate\(_dot_)com
{
# california rolling blackout power alerts
# not a discussion list - outbound only, and unconventional.
LISTNAME=POWERALERT
}
# etc.
}
The exceptions however should be few and far between - basically, they're
pseudo-lists which fail to follow accepted standards.
BTW, I note there's still no ackowledgement of your previous query. Have
you _STILL_ not received news about your v* problem? If this comment
baffles you, you REALLY need to visit the searchable list archives linked
from the procmail homepage and browse this months' posts.
---
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