At 16:20 2007-09-07 +0100, Pedro Santa wrote:
I marked the first filter to tag all mail that has more thant 3 * on
Spam Level by SpamAssassin, with the tag [SPAM 1]. I also tagged all
email from this account with [HELPDESK].
--> The problem it's that some Spam with more than 3 * on Spam Level
is not being tagged and therefore remaining in the INBOX! Why? <--
A VERBOSE LOGFILE might be useful in determining why. Near the top, set:
VERBOSE=ON
I'm gonna go out on a limb and say you'll likely find that all the messages
that don't get tagged have NO SUBJECT. As your rules are written, you're
extracting the contents of the Subject header - in doing so, you're also
expecting that the header be PRESENT (though it can be EMPTY). By moving
that header extraction OUT of the conditions, you eliminate it as a
required header.
:0 fh w
* ^X-Spam-Level: \*\*\*
* ^Subject:\/.*
| formail -I "Subject: [SPAM 1] $MATCH"
:0 fh w
* ^Subject:\/.*
| formail -I "Subject: [HELPDESK] $MATCH"
# extract the subject, separate from conditions
# note I prefix the assignment with a literal space - this is so that when I
# use the variable later, it comes with a space - and if it's UNSET, it won't
# add a meaningless space into the new subject you create.
:0
* ^Subject:\/.*
{
$OURSUBJ=" ${MATCH}"
}
# optional - you can omit this if you want.
# (though a present but BLANK Subject will match the above recipe)
:0E
{
$OURSUBJ=" (no original subject)"
}
:0
* ^X-Spam-Level: \*\*\*
{
SPAMLEVEL=" [SPAM 1]"
}
:0E fh w
| formail -I "Subject: [HELPDESK]${SPAMLEVEL}${OURSUBJ}"
This not only should fix your unflagged problem, but is a lot more
efficient - you're not getting the subject multiple times, and you're not
SETTING it multiple times.
You should also set a shell up at the top of your recipe file, since this
isn't being exectuted on behalf of a regular user (your mail account user
may have a non-existant or restritcted shell specified in the password db):
SHELL=/bin/sh
(or whatever is appropriate).
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
I don't use SA myself, but I've done a little bit of maintenance on it, and
IIRC, SA has config options for throttling itself. You may want to look
into that, especially where DNSBL lookups could cause 10 sequential
operations to take longer than 10 concurrent ones, because it's not all
about processor load.
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail