At 02:47 PM 12/29/2005, Professional Software Engineering wrote:
At 13:08 2005-12-29 -0500, Evan Cooch wrote:
[snip]
My .procmailrc file is *very* simple, and looks like
PMDIR=$HOME/.pmdir
LOGFILE=$PMDIR/log
you can add:
VERBOSE=ON
which would increase the detail in the log. ALways a good idea when trying
to sort things out, but perhaps not something you want to leave in there
long term (though your ruleset is quite short, so the logfile won't get as
insane as it will for some of us).
Thanks - I'll try that.
:0
* ^Subject:.*###
/dev/null
FTR, /dev/null is an unsafe destination to use until you're absolutely
positive everything is working as it should - you should write it to a junk
mailbox instead. You can't recover something from /dev/null - it's gone.
Oh, I know. But when you get as much email per day as I do (250-300
messages), a junk mailbox fills up very quickly. I spent about 6
months testing the frequency of false negatives for ### >= 3, and the
percentage was extremely small (<<0.05%). I can live with that.
Blank linkes BETWEEN recipes is a good idea too, as it increases the
readability of the file substantially.
Yup - I actually have the blanks in the .procmailrc file - I deleted
them to make the posted note shorter. My mistake.
:0fw
* < 256000
| spamassassin
:0:
* ^X-Spam-Status: Yes
$HOME/mail/spam
So, uhm, your own spamassassin config, which you have control over, merits
being stored in a mailbox, but the stuff flagged by who knows what
conditions by your ISP, is tossed to /dev/null ? I'd expect if anything,
it'd be the other way around - a higher trust in your own tuning than that
of arbitrary rules from your ISP.
As above - after a lot of testing, I know that the stuff with >= ###
as flagged by my ISP (a major University) is spam (99.95% of the
time). So, I just kill it. But, there is still stuff that gets
through, that I then want to 'filter'.
Now, the problem I'm having is that when the mail is received by our
mailhost, it is automatically flagged with a variable number of #
marks, which give an indication of the likelihood of the mail being
spam. The more # marks, the greater the likelihood. What I'm
trying to do with
yuck. They're modifying the subject? So basically, you're on a discussion
list, and some message gets flagged as looking kind of like spam, but it
isn't and you (or any of their other users) reply, thus altering the
subject of your reply? Somebody should hit your system admin upside the
head with a 2x4. Just about every mail client out there can filter on
virtually anything in the message, and the ones that can't are used by
people who obviously don't make much use of email.
I'll guess you don't work at a major university - 100,000 + accounts,
95% of whom are used by people who have no concept of filtering, or
spamassasin, or anything. They rely on our mail guys to flag things
for them. Further, its waaaay more efficient to kill spam at our edge
routers than at the client side. When our University was polled as to
whether or not they wanted our mail guys to handle the initial
flagging and killing, the response was an overwhelming "yes".
Now, what I don't understand is why, fairly often, an email with >= 3
### will not get killed, but does end up in the $HOME/mail/spam folder?
Enable verbose and see if the message has ### when it enters (of if there's
some other reason it fails to match), or if it's something your own
spamassassin config is adding after the fact.
Add:
* Subject:\/.*$
in the first recipe before the other condition, and then the MATCH
construct will log the content of the subject (in addition to the verbose
logging saying the condition matched or not). This \/ syntax extracts what
follows as a $MATCH variable - we're not interested in the variable so much
as seeing the content of that header right up top.
Great - thanks for the suggestions!
____________________________________________________________
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