At 01:20 2000-10-28 -0700, holtzm(_at_)primenet(_dot_)com wrote:
> Two separate examples, or one continuing log entry?
Like I said, two examples. Unrelated. Sorry if I didn't make this clear.
Well, let's try again then. How about you include the match *AND* the
delivery info from THAT MATCH. Including the match from one example, and
the delivery info from another will NOT help anyone to diagnose the problem.
> >procmail: Match on
[snip]
> > Folder: /var/spool/mail/holtzm
My mistake, as pointed out by Mr. Park, is that I didn't pay attention to
the log that this is obviously not the same mbox that you specify in your
script (I must quit responding to technical email first thing in the morning).
wasn't clear. The problem is that the spamtrap.rc filter evidently didn't
match on the message even though it didn't have my email address anywhere
in it.
According to the logfile, that "Match on ! ..." line says that a message
*WAS* matched. So your job is to locate the lines which should follow it
demonstrating what was done with the matched message.
I extract a number of message elements (sender, from, subject, and to) in
my main .procmailrc, so they're available to all rules as simple
variables. The first rule below extracts just the subject (if you already
have this extracted, then no need to do it again). The following, entered
inside the same file which your suspect spam rule is in, will place begin
and end delimiters containing reference to the subject line around the
associated log entries for the message:
:0
* ^Subject:[ ]*\/[^ ].*
{
SUBJECT=$MATCH
}
LOG="SPAMCHECK BEGIN: $SUBJECT
"
(put your rule here)
LOG="SPAMCHECK END: $SUBJECT
"
(in both cases, the linefeed is right after $SUBJECT, and the closing quote
is INTENTIONALLY on the following line).
You don't want these in permanently, but if you run a suspect message
through your filters, your log should have the begin/end lines on either
side of the logged events for the message WRT this recipe (though, due to
parallel message processing, if another message is being filtered by
procmail, additional log lines from unrelated messages may appear between
the lines, which is a given).
With the subject info in the log, you should then be able to open the
logfile and search it for the appropriately delimited block. Then post
that snippet.
> Uh, isn't this the message that was _filed_ as per the above logfile entry?
Yes, after the spamtrap.rc filter failed to ctch it.
Not according to the MATCH logfile entry. This is why the associated
logged delivery info from THAT MATCH is important to diagnosing the problem.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail