procmail
[Top] [All Lists]

Re: Filtering bounces for auto-wording recipes

2003-09-26 04:40:57
On Thu, Sep 25, 2003 at 09:37:29PM -0500, Justin Shore wrote:

On Thu, 25 Sep 2003, Professional Software Engineering wrote:

.. and a good reason to consider _NOT_ automating reporting
mechanisms, since when they break, they're become a big problem,
often setting yourself up to be ignored.

Unfortunately there's no other feasible way to run a network of
spamtraps that fields thousands of pieces of spam per day.  I don't
have the time to check each piece of mail before approving it
unfortunately.  I'm not paid for my contribution.  I'm just trying to
find a good solution.  If I can address this problem then I think I
just might have it licked.

Bzzzt.  Wrong answer.  You are contaminating the razor lists.  For
myself, I pride myself on the low false-positive rate of my private
spamtrap recipes.  Nevertheless, a stubborn 1% continue to get in
there.[1]  Before I send off to razor, I "mutt -f" the file, type
"o" and then "f" to sort by From: field, then scan down the names
quickly.  I can do several hundred in about forty seconds.  I
hit the ">" key to page-down.

[1] False negatives are almost none.  Long-term rate is well under
one in a thousand.


At the very least, you ought, then, to be assigning weighted scores
of "spamishness".  I use a five-level system.  Five is the highest,
and gets shunted to my inbox with almost minimal further testing.
The stuff that ends up in my spam folder is mostly in the bottom
two (or below one, which is as sure a bet as I can make).  Sometimes
a three slips in there.  Then I see what I can do to revise my
heuristic!  Anyway, MAILER-DAEMON stuff should never get into a
pile that automatically gets reported.  Even if you (your algorithms)
think it's forged, put it somewhere separate, as Sean says.  I use
a file called "purgatory" for stuff that tickles only one of my
spam snaggers or has a $TRUST (my system) score of four or five.
A few emails a day hit purgatory, and I look at them manually.

FTR, 'H' is a default flag, so you don't need to specify it.  See
'man procmailrc'

It's just a place holder to make sure I don't forget.  Sort of a keep
my sanity measure.


It's stylistically a bad idea to do that.  Six months, or six years,
from now, when you are or your successor is looking at the code, you
or he will wonder why you stressed that.  Since it's the default,
yet it was placed in the recipe explicitly, the programmer must want
to call something to our attention.  What could that be?  Code
reader now spends the next half-hour trying to figure out what he
doesn't grasp at first glance about that recipe, that would make the
coder wish to call something to our attention with such explicitness.

These are also the reasons why I do not place full paths to
called system binaries in my .procmailrc -- that's what the $PATH
variable was compiled in for!  If I ever *do* have an explicit
path stated, it tells me (or the person reading along) that the
path to that binary is not standard, and deserves special attention.

Anyway, back to your coders' notes to yourself: that is what
comment fields are for, my friend!  E.g.,

        :0  # remember, H is default for conditions; hb for actions


The sed stuff that was originally posted raises my uh-oh flag.
If you are replacing $SUBJECT using sed in auto-replies, shell
meta-chars in the Subject: can really screw you up.  Here is
part of a thread I was participating in from three years ago
on this list that recalls some of the issues:

http://www.xray.mpe.mpg.de/mailing-lists/procmail/2000-04/threads.html#00139

-- 
dman

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail