procmail
[Top] [All Lists]

RE: Filtering bounces for auto-wording recipes

2003-09-26 17:08:34
From: Justin Shore [mailto:listuser(_at_)numbnuts(_dot_)net]

On Fri, 26 Sep 2003, Dallman Ross wrote:

Bzzzt.  Wrong answer.  You are contaminating the razor lists.  For

How exactly am I contaminating the razor list?  Only spam is being
submitted after all (assuming the bounce filters are working).  The
domains I'm using for spamtraps have never had any legitimate usage
before.  There shouldn't ever be any legit mail coming into

Bart (I think it was Bart) gave one of my answers.  I actually
only follow the SpamAssassin-and-related stuff only peripherally,
since I find my own spam traps work better and less likely to
false-poz on me.  (And it's so much speedier doing all-procmail
stuff rather than running perl, even if it is a daemon).
So that's all by way of explanation in case this is wrong, but:
aren't the razor lists taking readings on headers and using them
to feed the database?  So isn't postmaster stuff going to screw
with that?


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

Sounds like you have a pretty slick system.  This is with you regular
email account though, right?

Yes; but I route 22 domains' mail through it.  And I get lots of
weird personal mail from different places, to lots of different
addresses -- much more so than the average email user.  So my recipes
have to be carefully thought through to avoid FPs.


At the very least, you ought, then, to be assigning weighted scores
of "spamishness".  I use a five-level system.  Five is the highest,


How does this apply at all?  If it arrives on a spamtrap that
has never been used by anyone for any legitimate reason then it's spam.

Yes, except for misaddressed mail and postmaster bounces, I suppose
that is true.  If you stated the first time that limitation to your
method, okay; but I read too fast and didn't see that.


 I can't
think of any reason to weight the scoring to determine a messages
spamishness since it's spam regardless (again assuming I can get the
bounces filtered out reliably).

I was speaking generally: that you need to look harder at mail that
you're less sure was spam, than at mail that you're very sure was
spam.  So segregate the piles, and look harder at the stuff that
*should* be looked harder at.  That's all I meant.


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

It's stylistically a bad idea to [explicitly state the H flag
even where it is the default . . . .]  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,


I don't see this as being a problem personally.  There won't
ever be a successor.  Just me since it's my own personal systems that

Okay, forget for a moment what I said about style.  What about
the problem of causing bugs in your code?  Did you know that there
is a bug in the current procmail, such that an explicated H in
the top line won't let you turn off H at all in later recipes?

http://mailman.rwth-aachen.de/pipermail/procmail/2002-February/008355.html


These are also the reasons why I do not place full paths to
called system binaries in my .procmailrc -- that's what the $PATH


I assume you're referring to the pyzor call.  I'm not sure
why I did that.

I was speaking generally, and not even referring to your code
specifically.  But if I gave you a guilty conscience, that's okay.  :)


Take care,
Dallman


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