You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michael Parker <pa...@pobox.com> on 2004/12/16 18:38:58 UTC
SpamAssassin 3.0.2 is released!
SpamAssassin 3.0.2 is released! 3.0.2 contains some important
bugfixes, and is recommended.
Highlights:
- Detect legitimate SMTP AUTH submission, to avoid false positives on
Dynablock-style rules
- Fix URIDNSBL plugin to honor uridnsbl_max_domains config option
- Various documentation and rule fixes
- Deal with 'rewrite_header Subject' markup when no Subject header
exists
- Fix 'make test' failure on Solaris
Pick it up at http://spamassassin.apache.org/
You can also find it on your favorite CPAN mirror, you may need to
wait a day or so for the release to propagate.
md5sum of archive files:
b373bc48c4f50b70cb784f40d88868bf Mail-SpamAssassin-3.0.2.tar.bz2
2a654d0819a730aab3fbbba83da62bc0 Mail-SpamAssassin-3.0.2.tar.gz
600ac98a22768321680df8a6c0bb1982 Mail-SpamAssassin-3.0.2.zip
sha1sum of archive files:
1e23f36a0820a6e9e7d9d43262607f3984db2724 Mail-SpamAssassin-3.0.2.tar.bz2
be69e72c7351df46de3eeed811219adf35b2964d Mail-SpamAssassin-3.0.2.tar.gz
56512e5ef1e7740c61d4e2870081931e42e46f41 Mail-SpamAssassin-3.0.2.zip
The release files also have a .asc accompanying them. The file serves
as an external GPG signature for the given release file. The signing
key is available via the wwwkeys.pgp.net key server, as well as
http://spamassassin.apache.org/released/GPG-SIGNING-KEY
The key information is:
pub 1024D/265FA05B 2003-06-09 SpamAssassin Signing Key
<re...@spamassassin.org>
Key fingerprint =3D 26C9 00A4 6DD4 0CD5 AD24 F6D7 DEE0 1987 265F A05B
SpamAssassin Developers
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.
missing RBLs
Posted by Theodore Heise <th...@heise.nu>.
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