procmail
[Top] [All Lists]

Re: Spammish?

2003-02-15 14:12:57
On Sat, 15 Feb 2003, Professional Software Engineering wrote:

In the recent past it has been suggested to me that I could allow messages
to "bubble" down

Trickle down.  Bubbles tend to go UP.

Heh!  Ok!

Lots of references to "free" might be spammish.  Or lots of $ (though on
some programming lists, this isn't a good criteria).

The only "body" recipe I have is for Nigerian Scam messages.  It's also
the only scoring recipe I have - and it works well; although I've had to
tweak it twice in the past month.

Messages with cleartext addressees that don't include you,

This is the only recipe I have with a "white" list.  (If not addressed to
somebody at one of the domains I administer it's spam - this allows quite
a bit of spam to flow through.  I'm looking for "webmaster@", "info@",
etc. which *could* be valid mail; and what I get is "John@" or "R@".  I
put this recipe nearly last and in hopes the other recipes will filter
out most of the spam.  This is one of my "problems".)

and it's not a list you subcribe to (and would presumably be filtering
for already), could be spammish.

My lists recipes are pretty solid.

Messages not from: your domain, but with the messageid containing your
domain.

One of my more "active" filters.

Messages with only one received header (your server puts one there, and any
user or mailing list should have one from their server receiving it from
them as well, or at least a record or it originating on their server.

Don't think I've ever seen a message with less than three Received:
headers.  (Again, I admit to limited experience.)

Messages passing through your backup mx (when you know that it is virtually
NEVER involved with email).

I don't even know what a "backup MX" is.  As far as that goes, I'm not
sure I have any idea what a primary MX is.

running a cumulative score (or even a tentative X-SPAM-SCORE: header with
reason codes) in a variable is a LOT less costly than invoking formail to
modify the message header over and over.

Ok.  Currently I use LOG to record the "rule" that identifies a message as
spam.  Looks something like:

      3 SPAM: ADV - Subject: begins with ADV:
      1 SPAM: FROMLIST - Return-Path=superdealnow.com
      1 SPAM: FROMVSDOM - from hotmail.com with non-matching message-id
      2 SPAM: MSGID - contains no domain (lacking @)
     18 SPAM: MSGID - message-id assigned by raq2.paxp.com
      2 SPAM: MSGID - pattern 01 - nnnnnnhnhhnn$hhhnnnnn$nnnnnnnn@
     16 SPAM: MSGID - pattern 04 - nnnnnnnnnn.nnn(n|nn|nnn)@


:0
* some spammish test
{
         XSPAMSCORE="${XSPAMSCORE} spamtest 23;"
}

Wouldn't the above need to contain the c flag in order to allow the
message to continue through the filters?

If I just passed the message down (using :0 c) and continued using the
logging, I would obtain much the same result I think.  It would tell me
which recipes were most "active."

But how do I tie this to the message so I can file the spam when it has
completed a trip through the filters (without using formail)?

In the six months (admittedly a short time) I've been using procmail, the
only false positives I've recieved have been the result of a poorly
written recipe - ie, my fault.

During that time, how much spam has sneaked past your filters?  It is those
spams which "spammish" cumulative scoring helps to eliminate from your inbox.

Very little, actually.  Of 1060+ spam messages received in the last two
weeks, 50 were not caught - that's about a 95.3% success rate.  The only
false positives I had (in this period) were two spam messages that managed
to be so verbose they wound up getting snagged by the Nigerian filter. :)

                                - fleet -


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

<Prev in Thread] Current Thread [Next in Thread>