You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Theodore Heise <th...@heise.nu> on 2005/02/12 16:01:45 UTC
missing RBLs
Hi all,
I'm very puzzled by the attached spam that appeared in my inbox
last night. I'm running Slackware 9.1, with SpamAssassin-3.0.0,
sendmail-8.12.10, and procmail-3.15.2. I run spamassassin (not
spamd), and invoke it from procmail. I use pine4.58 as my client.
This all runs on a PIII box with 1GB of ram.
When the spam in question arrived, several rules did not appear to
fire; specifically the two RBLs RCVD_IN_BL_SPAMCOP_NET and
RCVD_IN_XBL, as well as URIBL_OB_SURBL. However, when I save the
message and run it through spamassassin -t, the additional rules
fire just fine. The respective hits are listed below. As it
happens, I've also been calling SA in debug mode and have attached
that output also. What am I doing wrong?
Also, on further inspection of the problem spam, I notice there is
no Received: header that indicates receipt by my mail server (the IP
is 12.210.217.184). I realize this isn't a SA issue, but if this is
where my problem lies perhaps some kind soul could help me
understand what I've missed. The lines from my sendmail log are
also included below.
Thanks for any help,
Ted
--
Theodore (Ted) Heise <th...@heise.nu> Bloomington, IN, USA
As received:
-----------
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50,RCVD_IN_SBL,
URIBL_SBL autolearn=no version=3.0.0
Result of spamassassin -t
-------------------------
Content analysis details: (8.6 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.5781]
1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see <http://www.spamcop.net/bl.shtml?220.175.203.188>]
3.1 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
[220.175.203.188 listed in sbl-xbl.spamhaus.org]
0.1 RCVD_IN_SBL RBL: Received via a relay in Spamhaus SBL
[220.175.203.188 listed in sbl-xbl.spamhaus.org]
1.0 URIBL_SBL Contains an URL listed in the SBL blocklist
[URIs: popuptales.com]
3.2 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist
[URIs: popuptales.com]
maillog entries:
---------------
Feb 11 21:02:11 linus sm-mta[10674]: j1C21xw5010674: from=<ke...@freereed.net>, size=1291, class=0, nrcpts=2, msgid=<78...@freereed.net>, proto=SMTP, daemon=MTA, relay=[220.175.203.188]
Feb 11 21:02:20 linus sm-mta[10675]: j1C21xw5010674: to=<ka...@heise.nu>, delay=00:00:18, xdelay=00:00:09, mailer=local, pri=61443, dsn=2.0.0, stat=Sent
Feb 11 21:02:26 linus sm-mta[10675]: j1C21xw5010674: to=<th...@heise.nu>, delay=00:00:24, xdelay=00:00:06, mailer=local, pri=61443, dsn=2.0.0, stat=Sent
Re: missing RBLs
Posted by Theodore Heise <th...@heise.nu>.
On Sat, 12 Feb 2005, Matt Kettler wrote:
> At 11:13 AM 2/12/2005, Theodore Heise wrote:
> > > The XBL however, has the "notfirsthop" restriction. It won't match
> > > any messages that have no trusted relays. Based on the debug
> > > output, there were no trusted relays, thus XBL would not have
> > > matched for this reason.
> >
> >I think I follow this for why it didn't match on initial processing,
> >but I still don't understand why it matched the message *after* I
> >saved it and ran it through spamassassin -t.
>
> Were there any extra Received: headers added after you received it?
There's only one Received: header in the whole message, and it
doesn't even show receipt by my mail server--I still don't
understand this part.
All the headers are below. The very first header (the From) seems
to be what the XBL is hitting. Perhaps this header is added by
procmail just before delivery and after SA scans the message?
Ted
>From kelsee@freereed.net Fri Feb 11 21:02:20 2005
Return-Path: <ke...@freereed.net>
Received: from freereed.net ([220.175.203.188])
by linus.heise.nu (8.12.10/8.12.10) with SMTP id j1C21xw5010674;
Fri, 11 Feb 2005 21:02:02 -0500
Message-ID: <78...@freereed.net>
Date: Sat, 12 Feb 2005 11:14:52 +1200
Reply-To: "humberto akins" <ke...@freereed.net>
From: "humberto akins" <ke...@freereed.net>
User-Agent: Windows Eudora Pro Version 2.2 (32)
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Efrain Worth" <ka...@heise.nu>
Subject: For quality ink products at bargain prices, visit us
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on linus.heise.nu
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50,RCVD_IN_SBL,
URIBL_SBL autolearn=no version=3.0.0
Status: R
X-Status:
X-Keywords:
Re: missing RBLs
Posted by Matt Kettler <mk...@comcast.net>.
At 11:13 AM 2/12/2005, Theodore Heise wrote:
> > The XBL however, has the "notfirsthop" restriction. It won't match
> > any messages that have no trusted relays. Based on the debug
> > output, there were no trusted relays, thus XBL would not have
> > matched for this reason.
>
>I think I follow this for why it didn't match on initial processing,
>but I still don't understand why it matched the message *after* I
>saved it and ran it through spamassassin -t.
Were there any extra Received: headers added after you received it?
Re: missing RBLs
Posted by Theodore Heise <th...@heise.nu>.
On Sat, 12 Feb 2005, Matt Kettler wrote:
> At 10:01 AM 2/12/2005, Theodore Heise wrote:
> >When the spam in question arrived, several rules did not appear to
> >fire; specifically the two RBLs RCVD_IN_BL_SPAMCOP_NET and
> >RCVD_IN_XBL, as well as URIBL_OB_SURBL.
>
> Well, The URIBL and Spamcop changes are almost certainly due to
> time difference. Those two update *VERY* fast.
>
> In particular, the URIBL is actually a body rule, so header
> changes will not affect it. I'm confident time is the difference
> here. I bet if you run it again later you'll match more of the
> surbl URIBLs too.
Hi Matt,
Thanks for the response! Your explanation makes sense, and I really
appreciate it.
> The XBL however, has the "notfirsthop" restriction. It won't match
> any messages that have no trusted relays. Based on the debug
> output, there were no trusted relays, thus XBL would not have
> matched for this reason.
I think I follow this for why it didn't match on initial processing,
but I still don't understand why it matched the message *after* I
saved it and ran it through spamassassin -t.
Ted
Re: missing RBLs
Posted by Matt Kettler <mk...@comcast.net>.
At 10:01 AM 2/12/2005, Theodore Heise wrote:
>When the spam in question arrived, several rules did not appear to
>fire; specifically the two RBLs RCVD_IN_BL_SPAMCOP_NET and
>RCVD_IN_XBL, as well as URIBL_OB_SURBL.
Well, The URIBL and Spamcop changes are almost certainly due to time
difference. Those two update *VERY* fast.
In particular, the URIBL is actually a body rule, so header changes will
not affect it. I'm confident time is the difference here. I bet if you run
it again later you'll match more of the surbl URIBLs too.
The XBL however, has the "notfirsthop" restriction. It won't match any
messages that have no trusted relays. Based on the debug output, there were
no trusted relays, thus XBL would not have matched for this reason.
Spamcop is header based, but doesn't have the notfirsthop restriction, so
it won't be hindered in this way. However, spamcop is an automated RBL, and
as soon as enough reports come in, a site gets listed. A time difference of
even 15 minutes is a huge difference in terms of spamcop.