|
Re: Why this filter didn't work.....
2002-02-20 16:01:15
At 15:46 2002-02-20 -0600, SMORRIS(_at_)UP(_dot_)COM did say:
>:0 B
>* 9876543210^0 to opt out
>* 9876543210^0 visosite
>* 9876543210^0 softwareforyou
>* 9876543210^0 as seen on national tv
>spam
>If you're going to match multiple things in the body, any of which flag it
>as spam, combining them into one recipe would streamline your
>processing. Before asking "what are all those numbers for" please read
>'man procmailsc'.
I read through man procmailsc (which I assume stands for scoring). I hope I
am not the only one who hasn't a clue what they are talking about in there.
I did not do well in Calculus in college.
That has what do do with this? No differential equations here, just simple
alegbraic exponentiation. It's even a button on your cheap pocket
calculator: x^y (where there isn't an ^ symbol, but the y is small and
raised up as a superscript).
Nor do I understand them as you present them in the example you provided.
The "really big number" forces the comparisons to stop as soon as one of
the conditions matches. If it was a small number instead of being really
big, it'd simply add to a score value, rather than tripping the score rule
right then and there.
The number after the caret (^) is an exponent - if zero, the "really big
number" (procmail calls it the weight, but in math, it's called the 'base')
is simply added to the score, and procmail doesn't attempt to match this
indvidual condition line again. If the exponent is nonzero (and it CAN be
negative, as can the weight itself), procmail continues to look for matches
(useful say, if you want to add a score up for lots of exclamations or
large numbers, indicators of attachments, whatever), and adds the first
number raised to the exponent for each match that it finds until it is done
matching.
Perhaps you should rummage through the FAQ pages (at
<http://www.procmail.org>), as I'm sure scoring basics should be covered
someplace there.
In simple terms, as presented above, you have ONE rule which effectively
OR's each condition line, stopping as soon as it has a match, whereas
regular multiple condition procmail rules require ALL conditions to match,
and stop when there is a failure to match.
By all means, if you don't understand what I offered, don't use it -- you
really DO NOT want to implement things you don't understand, since later
on, you'll be staring at them wondering why they don't work, or you'll need
to be modifying them and wondering how. The scoring recipe was offered as
a way to combine multiple recipes which all individually resulted in
delivering to the same place - it's entirely valid to continue to run them
as a bunch of separate recipes. In time however, as you accumulate scores
of such recipes, you'll want to streamline things, and scoring can help you
do that. Scoring can also accomlish some complex things you can't
otherwise do without it (or would simply be too painful to try to do
otherwise).
You should check out my disclaimer of course. There, you'll find a link to
some documentation I've scrawled up demonstrating a sandbox configuration
which is useful for properly testing rules before putting them into live use.
So the way I had it there would make it match on any occurrence of "
@sexyfun.net" in the From line, but with the ^ it makes it start looking at
the beginning of the line (I assume).....
As you had it, it would match a SUBJECT containing "so how do I block
messages From: ahah(_at_)sexyfun(_dot_)net ?"), as an example.
help.) There is a lady named "Nancy" (her last name escapes me at this
moment) who also has a good example page.
You're speaking of the Procmail QuickStart, maintained by Nancy McGough,
who is a member of this forum.
Rather notably, Ms. McGough's Procmail Quickstart is linked along with the
several other FAQs at procmail.org.
(hmm, and the old best.com mirror is still linked there too - someone aught
to change that.)
>First thing is that you shouldn't simply be dumping things to /dev/null
>unless you're ABSOLUTELY POSITIVE of what you're doing. If you have ANY
>concerns, that should be the first thing you change. It seems weird that
>you'd filing _some_ things to a spam mailbox, and others to /dev/null.
When I had them all directed to a spam mailbox, I was getting close to 100
MB of spam per day into the box.
If you actually get THAT much spam every day which is spam, you're either
being mailbombed by someone you crossed, or your email is seriously spewed
across the internet. Perhaps you should consider setting up a new email
account and carefully guarding that address?
If it's YOUR server, then perhaps now would be a good time to consider
utilizing some RBLs in your MTA configuration (which means you won't even
RECEIVE a number of those spams because the SMTP session will be dropped as
soon as the sender's server is deemed to be a polluter - you'd receive no
spam body).
My customers understand that there is a chance something that is not spam
may be trashed, but none of them have complained, and many have expressed
gratitude over not receiving all that crap mail. (Why did the "spam" box
show up in var/spool/mqueue?... I assume there is a variable I didn't set
correctly somewhere).
Yes, $MAILDIR
I believe you neglected to mention that the filters you were talking about
were in /etc/procmailrc, rather than within your own account. Such details
ARE very significant.
---
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
|
|