Professional Software Engineering wrote:
Sanity check: I just want to check that a tweak that appears necessary
shouldn't have any adverse effects.
My problem: A spam got through yesterday, which I would have THOUGHT would
have been caught by the above rule, but on closer evaluation:
From: doa58(_at_)aol(_dot_)com (TF)
Message-Id:
<199810131740WAA55015(_at_)aol(_dot_)com(_dot_)shortweb(_dot_)com>
The domain portion STARTS with aol.com, rather than ends with it. GAAK!
I've got to update the rules - I expect this was done just this way in
order to foil basic checks similar to mine.
I should be able to just change the messageid rule to include a closing
bracket, but does anyone see a problem with doing this?
* ! ^Message-[Ii][Dd]:.*aol\.com\>
(I realize that the escapes probably aren't necessary, but I just tend to
do things that way)
One of various spam detection filters I have is as follows:
:0
* ^From:(_dot_)*(_at_)aol\(_dot_)com
* ! ^Message-[Ii][Dd]:.*aol\.com
{
LOG="SPAM: forged AOL$TWITVER"
:0:
|gzip -9fc>>$MAILDIR/twits.gz
}
What this does is says that if the From contains an aol domain,
the Message-ID had better as well, otherwise it is forged (I
have yet to get a piece of mail junked by this rule that ISN'T
spam). I have several others for various national ISPs as well,
I do them all at once like so. Note the use of the MATCH var,
which allows me to add to the list with minimal overhead...
SERVICE="(aol|\
compuserve|\
earthlink|\
freeyellow|\
juno|\
hotmail|\
netcom|\
rocketmail|\
wowmail|\
yahoo)"
:0fh
*$ 2^0 ^From:(_dot_)*(_at_)+\/$SERVICE\.
*$ -1^0 ^Received: from.*$MATCH
*$ -1^0 ^Message-Id:(_dot_)*(_at_)$MATCH
| formail -A "X-Reject: Forged From: header slandering $MATCH"
and on some, I also do inverse checking: if the message-id is
the domain, the FROM better be as well.
Don't forget to check for message ID's from *YOUR* domain,
for messages which originate externally. The following catches
a lot of RFMS stuff where the sending program doesn't insert a
Message-Id:, and my ISP's (Interlog) server puts one in. It
also caught a lot of "From: MAILER_DAEMON@<my isp>", a stunt
often pulled by the golfballs bozos, who figured people wouldn't
dare filter out stuff from MAILER_DAEMON.
# Note; put in the name of the hosting ISP, not your vitual
# domain name
MYISP="interlog\.(com|net)
# Invoke count if either From: or Message-Id: is your ISP.
# Count the total number of "Received: from" headers and
# subtract the count of headers for the message bouncing
#around between primary/secondary/gateway machines at your
# ISP. If this is *REALLY* an internal message, the counts
# should be equal, and difference = zero. If there are any
# external headers, difference is positive and message is
# "dealt with".
:0fh
*$ ^(From|Message-Id):.*$MYISP
* 1^1 ^Received:.from
*$ -1^1 ^Received:.from.*.$MYISP.*.by.*.$MYISP
*$ -1^0 ^Received:.from.*localhost.*.by.*.$MYISP
| formail -A "X-Reject: From:/Message-Id: is local, but message is
external"
--
Walter Dnes <waltdnes(_at_)interlog(_dot_)com> procmail spamfilter
http://www.interlog.com/~waltdnes/spamdunk/spamdunk.htm
Why a fiscal conservative opposes Toronto 2008 OWE-lympics
http://www.interlog.com/~waltdnes/owe-lympics/owe-lympics.htm