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 2005/04/29 05:22:22 UTC
SpamAssassin 3.0.3 Released
SpamAssassin 3.0.3 is released! SpamAssassin 3.0.3 contains some
important bug fixes and is recommended for use over previous
versions.
SpamAssassin is a mail filter which uses advanced statistical and
heuristic tests to identify spam (also known as unsolicited bulk email).
Highlights of the release
-------------------------
- Fixed possible memory bloat from large AutoWhitelist db files
- Fixed where user defined rules scores became ignored
- Updated parsing code for several Received: header formats
- Increased some BAYES_* scores for the network+bayes score set
- Document set_tag for Plugin API and added get_tag
- Additional bug fixes.
Downloading
-----------
You can pick up the release here: 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:
c9028e72958909285e43feb806d948dc Mail-SpamAssassin-3.0.3.tar.bz2
ca96f23cd1eb7d663ab55db98ef8090c Mail-SpamAssassin-3.0.3.tar.gz
d7292ec75eb61e0fa2ceb6aa5b20fed9 Mail-SpamAssassin-3.0.3.zip
sha1sum of archive files:
324763dd7b344b68ad9ab73fd68b8f779c801aab Mail-SpamAssassin-3.0.3.tar.bz2
e31407b68bf362dfe53814c0af867e8134c9808b Mail-SpamAssassin-3.0.3.tar.gz
c1aa1583eebc0771ee053b8a484a42fc22b8630c Mail-SpamAssassin-3.0.3.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
Note: GnuPG 1.4.0, and possibly 1.3.x versions, seem to have problems
verifying certain signature files, including the type as used for
SpamAssassin releases. If you are running an affected version, please
verify the code using both MD5 and SHA1 sum values instead.
The SpamAssassin Developers
Re: SpamAssassin 3.0.3 Released
Posted by Theo Van Dinter <fe...@kluge.net>.
On Fri, Apr 29, 2005 at 03:10:24PM +0200, Arvinn Løkkebakken wrote:
> Is there a list somewhere that lists up these fixes?
See the Changes file.
--
Randomly Generated Tagline:
A body in motion tends to stay in motion until he's done.
Re: SpamAssassin 3.0.3 Released
Posted by Arvinn Løkkebakken <ar...@whitebird.no>.
Michael Parker wrote:
>SpamAssassin 3.0.3 is released! SpamAssassin 3.0.3 contains some
>important bug fixes and is recommended for use over previous
>versions.
>
>SpamAssassin is a mail filter which uses advanced statistical and
>heuristic tests to identify spam (also known as unsolicited bulk email).
>
>Highlights of the release
>-------------------------
>
> - Fixed possible memory bloat from large AutoWhitelist db files
>
> - Fixed where user defined rules scores became ignored
>
> - Updated parsing code for several Received: header formats
>
> - Increased some BAYES_* scores for the network+bayes score set
>
> - Document set_tag for Plugin API and added get_tag
>
> - Additional bug fixes.
>
>
Is there a list somewhere that lists up these fixes?
Arvinn
Re: SpamAssassin 3.0.3 Released
Posted by Sidney Markowitz <si...@sidney.com>.
Daniel Quinlan wrote:
> Move the new SPF record to a new place and leave the old one in the old
> place. SPF should allow that.
It's all fixed now. The new SPF record was already in a new place. The
problem was that the old place is the live record for spamassassin.org. It
had been changed in a way that broke the old test. We fixed the test in
trunk by setting up a new spf record that is not on a domain used for real
email and changing the test to refer to it. Which left the old test broken.
I just changed the old spf record to perform correctly specifically for the
sender ip in this test without changing its behavior for any other sender ip.
While I was in there I changed the test spf record to allow the more
expanded test in trunk to be set up to start working. I'll commit new test
data files in trunk soon.
-- sidney
Re: SpamAssassin 3.0.3 Released
Posted by Daniel Quinlan <qu...@pathname.com>.
Sidney Markowitz <si...@sidney.com> writes:
> Now I remember what happened. We weren't using something like aol.com we
> were using spamassassin.org, our real spf record. We changed it to do more
> of the right thing and broke the test that counted on its old value.
>
> I'll look into it more to see if there is a way to make it the test work the
> way it is without breaking the mail.
Move the new SPF record to a new place and leave the old one in the old
place. SPF should allow that.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: SpamAssassin 3.0.3 Released
Posted by Sidney Markowitz <si...@sidney.com>.
Now I remember what happened. We weren't using something like aol.com we
were using spamassassin.org, our real spf record. We changed it to do more
of the right thing and broke the test that counted on its old value.
I'll look into it more to see if there is a way to make it the test work the
way it is without breaking the mail.
-- sidney
Re: SpamAssassin 3.0.3 Released
Posted by Sidney Markowitz <si...@sidney.com>.
Sidney Markowitz wrote:
> The correct fix for 3.0 branch, assuming that spf.t there is still testing a
> DNS record over which we have no control
Hmm, I looked. It doesn't. I'm downloading 3.0 branch now to see what is wrong.
-- sidney
Re: SpamAssassin 3.0.3 Released
Posted by Sidney Markowitz <si...@sidney.com>.
Robert Menschel wrote:
> everything looks good except:
>
> t/spf.......................ok 2/4
> Not found: helo_fail = SPF_HELO_FAIL
I don't know the details regarding the version of the test in the 3.0 branch
right now, but the history is this:
spf.t used some known domain record (like aol.com) to test spf. The domain
changed their spf record and the test stopped working, not due to any bug in
the code but the test data changed out from under us. We created a subdomain
of spamassassin.org to allow us to have such tests without being at the
mercy of such changes to live public records and changed spf.t in trunk to
use it.
Since then 3.1 has broken spf.t by adding a result of HELO_NEUTRAL. I
changed the trunk version of spf.t in anticipation of updating our DNS entry
to allow it to work, but spf.t in trunk currently fails.
The correct fix for 3.0 branch, assuming that spf.t there is still testing a
DNS record over which we have no control, is to tell people to ignore the
failure, thereby breaking CPAN install (sigh). Or if this means we will have
a 3.0.4 after all, change spf.t to the previous version of spf.t in trunk
before I made the recent change to it, which will work because 3.0 has no
HELO_NEUTRAL. Then I will make sure that it continues to work after I update
our test spf records for the expanded spf.t tests in trunk.
-- sidney
Re: SpamAssassin 3.0.3 Released
Posted by Robert Menschel <Ro...@Menschel.net>.
MP> SpamAssassin 3.0.3 is released! SpamAssassin 3.0.3 contains some
MP> important bug fixes and is recommended for use over previous
MP> versions.
Downloaded. the .zip version to my Cygwin $HOME directory. Unzipped.
> cd ~/Mail-SpamAssassin-3.0.3
> perl Makefile.PL
> make
> make test
everything looks good except:
t/spf.......................ok 2/4
Not found: helo_fail = SPF_HELO_FAIL
# Failed test 4 in t/SATest.pm at line 530
t/spf.......................FAILED test 4
Failed 1/4 tests, 75.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/spf.t 4 1 25.00% 4
5 tests skipped.
Failed 1/68 test scripts, 98.53% okay. 1/1507 subtests failed, 99.93% okay.
make: *** [test_dynamic] Error 14
Following "make install",
> $ spamassassin --version
> SpamAssassin version 3.0.3
> running on Perl version 5.8.5
> $ cpan
> cpan> i Mail::SPF::Query
> CPAN: Storable loaded ok
> Going to read /home/Bob/.cpan/Metadata
> Database was generated on Thu, 28 Apr 2005 19:57:17 GMT
> Strange distribution name [Mail::SPF::Query]
> Module id = Mail::SPF::Query
> DESCRIPTION Query Sender Permitted From status in DNS
> CPAN_USERID FREESIDE (Meng Weng Wong <me...@pobox.com>)
> CPAN_VERSION 1.997
> CPAN_FILE F/FR/FREESIDE/Mail-SPF-Query-1.997.tar.gz
> DSLI_STATUS RmpO (released,mailing-list,perl,object-oriented)
> MANPAGE Mail::SPF::Query - query Sender Policy Framework for an IP,email,helo
> INST_FILE /usr/lib/perl5/site_perl/5.8.5/Mail/SPF/Query.pm
> INST_VERSION 1.997
> cpan> i Net::DNS
> CPAN: Storable loaded ok
> Going to read /home/Bob/.cpan/Metadata
> Database was generated on Thu, 28 Apr 2005 19:57:17 GMT
> Strange distribution name [Net::DNS]
> Module id = Net::DNS
> DESCRIPTION Interface to the DNS resolver
> CPAN_USERID OLAF (Olaf Kolkman <ol...@net-dns.org>)
> CPAN_VERSION 0.49
> CPAN_FILE O/OL/OLAF/Net-DNS-0.49.tar.gz
> DSLI_STATUS RmhO (released,mailing-list,hybrid,object-oriented)
> MANPAGE Net::DNS - Perl interface to the DNS resolver
> INST_FILE /usr/lib/perl5/site_perl/5.8.5/Net/DNS.pm
> INST_VERSION 0.48
Any idea why this one SPF test would be failing, and/or what other
information I can collect to see whether it's worth a bugzilla report?
Bob Menschel
Re: SpamAssassin 3.0.3 Released
Posted by Michael Parker <pa...@pobox.com>.
On Thu, Apr 28, 2005 at 10:05:37PM -0700, Justin Mason wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Michael Parker writes:
> > Subject: SpamAssassin 3.0.3 Released
> > From: Michael Parker <pa...@pobox.com>
> > To: announce@spamassassin.apache.org, users@spamassassin.apache.org,
> > dev@spamassassin.apache.org
> > Date: Thu, 28 Apr 2005 22:22:22 -0500 (20:22 PDT)
> ^^^^^^^^
>
> check it out! was that deliberate? ;)
>
Total coincidence, and it was a zoo around here tonight, so it's
really just dumb luck.
Michael