I am using the defauls, which turn out to be min-spares=1 and
max-spares=2.
I think that I will change that. In any case, at least here, the only
change
seems to be that the message is more verbose and scarier.
I'm also OK with the release BUT I would like to know WHY the messages are
more
On Monday 25 January 2010 15:40:06 Kevin A. McGrail wrote:
I'm also OK with the release BUT I would like to know WHY the messages are
more verbose and scarier. There is some underlying cause for these
messages.
The message now includes the exit status of a finished child process.
Previously
Jan 22 13:10:01 talonjr spamd[8959]: spamd: handled cleanup of child pid
[8972] due to SIGCHLD: INTERRUPTED, signal 2 (0002)
Are these just more informative? Since a quick look of 3.2.5 shows the same
info() line, I'm worried that this isn't good. I had 0 of these before with
3.2.5 and
On 24/01/2010 1:23 PM, Thomas Schulz wrote:
Jan 22 13:10:01 talonjr spamd[8959]: spamd: handled cleanup of child pid
[8972] due to SIGCHLD: INTERRUPTED, signal 2 (0002)
Are these just more informative? Since a quick look of 3.2.5 shows the same
info() line, I'm worried that this isn't
I think in both Tom and Kevin's cases this is caused by their min-spares
and max-spares settings. Tom didn't show his settings, but Kevin's got
min-spares=5 and max-spares=6. That means that if two children finish
their work while another is being spawned, that new child is going to be
+1 to this cut. Running it in production, it survived a DDoS mail flood
earlier today and it passes all tests.
I'm happy to report that two test servers passed make test without issue.
And one was using long_tests and net_tests set to y. A third is in
progress now
I also installed this
On Friday 22 January 2010 19:28:28 Kevin A. McGrail wrote:
Since moving the server to 3.3.0, I'm seeing these in the logs that were
not there before:
Jan 22 13:10:01 talonjr spamd[8959]: spamd: handled cleanup of child pid
[8972] due to SIGCHLD: INTERRUPTED, signal 2 (0002)
Are these just
On 01/22/2010 01:28 PM, Kevin A. McGrail wrote:
Jan 22 13:10:01 talonjr spamd[8959]: spamd: handled cleanup of child pid
[8972] due to SIGCHLD: INTERRUPTED, signal 2 (0002)
Are these just more informative? Since a quick look of 3.2.5 shows the
same info() line, I'm worried that this isn't good.
This is different between 3.2 and 3.3, maybe it explains the symptoms:
$$Mail::SpamAssassin::Logger::LOG_SA{INHIBIT_LOGGING_IN_SIGCHLD_HANDLER}) {
Don't know why this changed and which is right.
Probably unrelated and false lead. The new one seems to be correct.
So ... no idea.
Mark
FWIW I've had these for months seemingly without any ill effect.
3.3.0 changed:
unless
($Mail::SpamAssassin::Logger::LOG_SA{INHIBIT_LOGGING_IN_SIGCHLD_HANDLER}) {
from
unless
($$Mail::SpamAssassin::Logger::LOG_SA{INHIBIT_LOGGING_IN_SIGCHLD_HANDLER}) {
That doesn't seem to be the cause.
On Friday January 22 2010 20:38:38 Kevin A. McGrail wrote:
/usr/local/bin/spamd -d --min-spare=5 --min-children=5
--max-conn-per-child=1000 --max-children=40 -q -x -u spamd
--allowed-ips=127.0.0.1,removed -i removed -r /var/run/spamd.pid
Are these just more informative? Since a quick look
Hi Kevin,
- Kevin A. McGrail kmcgr...@pccc.com wrote:
I was speaking solely on JM's comment that this could affect
anubis'
network. I'd rather not release a DDoS if the intent was to only
test
those rules and somehow it sneaks into a new release that might get
wide
support from
-3.3.0.zip
6f642382d7870c2cb542f50b22a0adb250165c6f
Mail-SpamAssassin-rules-3.3.0.r900610.tgz
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
please vote!
--
--j.
On 01/21/2010 06:36 AM, João Gouveia wrote:
Currently the impact would most likely be like a shot in the foot. We simply do
not yet have the necessary infrastructure in place to handle the expected
traffic.
This will change (hopefully soon), but for now it would be best not to publish
the
8e425d21593140ee3a6ae0cb7a30d515b6227c95 Mail-SpamAssassin-3.3.0.zip
6f642382d7870c2cb542f50b22a0adb250165c6f
Mail-SpamAssassin-rules-3.3.0.r900610.tgz
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
please vote!
--
--j.
On Thursday 21 January 2010 13:30:58 Justin Mason wrote:
here's the new recut.
http://people.apache.org/~jm/devel/ :
Good!
please vote!
+1
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
A small mistake in release notes regarding sa-update:
r901724 Minor tweaks
On 01/21/2010 07:30 AM, Justin Mason wrote:
sha1sum of archive files:
5e639ccf5773e3a1781285ea104f05394b5ea1b0 Mail-SpamAssassin-3.3.0.tar.bz2
http://people.apache.org/~jm/devel/Mail-SpamAssassin-3.3.0.tar.bz2
209a97102e2c0568f6ae8151e5a55cd949317b69 Mail-SpamAssassin-3.3.0.tar.bz2
Did
-SpamAssassin-3.3.0.zip
6f642382d7870c2cb542f50b22a0adb250165c6f
Mail-SpamAssassin-rules-3.3.0.r900610.tgz
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
please vote!
--
--j.
--
--j.
http://people.apache.org/~jm/devel/Mail-SpamAssassin-rules-3.3.0.r901671.tgz
Is this the new rules?
Yes.
sha1 http://people.apache.org/~jm/devel/Mail-SpamAssassin-3.3.0.tar.bz2
209a97102e2c0568f6ae8151e5a55cd949317b69 Mail-SpamAssassin-3.3.0.tar.bz2
Yes.
Wrong checksums in the posting
6f642382d7870c2cb542f50b22a0adb250165c6f
Mail-SpamAssassin-rules-3.3.0.r900610.tgz
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
please vote!
For the announcement mind if I send it out? I can avoid wrapping of the
long line.
Warren
8e425d21593140ee3a6ae0cb7a30d515b6227c95 Mail-SpamAssassin-3.3.0.zip
6f642382d7870c2cb542f50b22a0adb250165c6f
Mail-SpamAssassin-rules-3.3.0.r900610.tgz
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
please vote!
For the announcement mind if I send it out? I can
598eebc4791dc7c7b958d87f9a33ecaef12edd09 Mail-SpamAssassin-3.3.0.tar.gz
8e425d21593140ee3a6ae0cb7a30d515b6227c95 Mail-SpamAssassin-3.3.0.zip
6f642382d7870c2cb542f50b22a0adb250165c6f
Mail-SpamAssassin-rules-3.3.0.r900610.tgz
announcement mail: http://people.apache.org/~jm/devel/PROPOSED-3.3.0.txt
please vote
On 01/21/2010 11:16 AM, Justin Mason wrote:
argh! sorry, sent out the wrong sums, as Warren spotted. The correct sums are:
md5sum of archive files:
15af629a95108bf245ab600d78ae754b Mail-SpamAssassin-3.3.0.tar.bz2
38078b07396c0ab92b46386bc70ef086 Mail-SpamAssassin-3.3.0.tar.gz
proposed release announcement mail is there, too. We need 3 +1 votes
and no -1's over the next 72 hours to bless this as an official
release.
Here is my +1 for both the code and the rules.
One caveat with the rules is Bug 6295, which should be
fixed with the next sa-update. Whether this is
On Wed, Jan 20, 2010 at 11:29, Mark Martinec mark.martinec...@ijs.si wrote:
proposed release announcement mail is there, too. We need 3 +1 votes
and no -1's over the next 72 hours to bless this as an official
release.
Here is my +1 for both the code and the rules.
One caveat with the
##{ FH_BAD_OEV1441
@@ -3219,2 +3214,6 @@
header __RATWARE_BOUND_B ALL =~
/boundary==_NextPart_000__([0-9a-f]{8})\..{10,400}^Message-Id:
\1\$[0-9a-f]{8}\$/msi #
+header __RCVD_IN_ANBREP eval:check_rbl('anubisrep-lastexternal',
'c.anubisnetworks.com.')
+tflags
it should be pretty harmless in terms of effects on users, but will
increase the anubisnetworks.com
query load, which they may not appreciate.
I don't think it needs to block 3.3.0, though.
Good catch. I never would have caught that already. But I think we
should definitely
But the __* rules have a score of 0 and are not used unless
invoked from some meta rule, which is not the case here
(am I right?). There is no big deal, as far as I can tell.
I was speaking solely on JM's comment that this could affect anubis'
network. I'd rather not release a DDoS if the
On Wednesday 20 January 2010 15:30:31 Kevin A. McGrail wrote:
But the __* rules have a score of 0 and are not used unless
invoked from some meta rule, which is not the case here
(am I right?). There is no big deal, as far as I can tell.
I was speaking solely on JM's comment that this
On Wed, Jan 20, 2010 at 14:27, Mark Martinec mark.martinec...@ijs.si wrote:
it should be pretty harmless in terms of effects on users, but will
increase the anubisnetworks.com
query load, which they may not appreciate.
I don't think it needs to block 3.3.0, though.
Good catch. I never
On Wednesday 20 January 2010 15:42:10 Justin Mason wrote:
I'm not certain, but I believe the __* rules _will_ be run, whether
they're called from a meta rule or not, unless explicitly disabled
using score __FOO 0. they don't provide a score, but they are still
run.
You are right, confirmed.
So, does recutting the rules tarball stall the publishing
by another three days? As the announcement says, rules are
no longer part of the distribution.
Great Though! Do we have a procedure on the release of new rules?
Regards,
KAM
On Wed, Jan 20, 2010 at 14:59, Mark Martinec mark.martinec...@ijs.si wrote:
On Wednesday 20 January 2010 15:42:10 Justin Mason wrote:
I'm not certain, but I believe the __* rules _will_ be run, whether
they're called from a meta rule or not, unless explicitly disabled
using score __FOO 0.
can someone open a bug about this issue?
ignore, just spotted it. ;)
--
--j.
On 01/20/2010 06:29 AM, Mark Martinec wrote:
Another thing I noticed, comparing the resulting rules
from network sa-update to rules installed from a tarball
is the inclusion of two 'nopublish' rules in the tarball.
As these are both meta rules, this should not be a blocker.
How did these
On 01/20/2010 09:42 AM, Justin Mason wrote:
On Wed, Jan 20, 2010 at 14:27, Mark Martinecmark.martinec...@ijs.si wrote:
it should be pretty harmless in terms of effects on users, but will
increase the anubisnetworks.com
query load, which they may not appreciate.
I don't think it needs to block
in the proposed 3.3.0 release rules tarball (and therefore
the proposed 3.3.0 channel).
Regards,
KAM
went out to the sa-update
channel. It's in the proposed 3.3.0 release rules tarball (and therefore
the proposed 3.3.0 channel).
Regards,
KAM
Recut happening today? That should give us a good amount of non-weekend
days to validate the new cut and the release will be closer to the
Tuesday press
should be
a blocker for 3.3.0.
However, I don't know for sure that it ever went out to the sa-update
channel. It's in the proposed 3.3.0 release rules tarball (and therefore
the proposed 3.3.0 channel).
Regards,
KAM
Recut happening today? That should give us a good amount of non-weekend
On Tue, Jan 19, 2010 at 03:43, Sidney Markowitz sid...@sidney.com wrote:
Daryl C. W. O'Shea wrote, On 19/01/10 3:41 PM:
Skimming...
On 18/01/2010 9:10 PM, Sidney Markowitz wrote:
There is a new signing key for the 3.3.0 release and which will be used
for sa-update rules starting now.
We're
On Tue, Jan 19, 2010 at 02:10, Sidney Markowitz sid...@sidney.com wrote:
Justin Mason wrote, On 19/01/10 12:55 PM:
proposed release announcement mail is there, too. We need 3 +1 votes
and no -1's over the next 72 hours to bless this as an official
release.
I have an issue with the proposed
Please try out the tarballs at:
http://people.apache.org/~jm/devel/
md5sum of archive files:
58a439f930b49b0a3747c6caa738acc6 Mail-SpamAssassin-3.3.0.tar.bz2
a24302ff6a3c410b5c6b84041877c914 Mail-SpamAssassin-3.3.0.tar.gz
ed99edd70819579bcc722411e1da49a1 Mail-SpamAssassin-3.3.0.zip
On 01/18/2010 07:33 PM, Mark Martinec wrote:
On Tuesday January 19 2010 00:55:40 Justin Mason wrote:
Please try out the tarballs at:
http://people.apache.org/~jm/devel/
Looks good at first sight. More testing tomorrow.
Mark
Justin Mason wrote, On 19/01/10 12:55 PM:
proposed release announcement mail is there, too. We need 3 +1 votes
and no -1's over the next 72 hours to bless this as an official
release.
I have an issue with the proposed release announcement. Not enough for a
hard -1 vote, but we can change it
Skimming...
On 18/01/2010 9:10 PM, Sidney Markowitz wrote:
There is a new signing key for the 3.3.0 release and which will be used
for sa-update rules starting now.
We're still going to use the old key for updates for 3.2, if we do them,
right? Forcing a key change for 3.2 would be bad, IMO.
Daryl C. W. O'Shea wrote, On 19/01/10 3:41 PM:
Skimming...
On 18/01/2010 9:10 PM, Sidney Markowitz wrote:
There is a new signing key for the 3.3.0 release and which will be used
for sa-update rules starting now.
We're still going to use the old key for updates for 3.2, if we do them,
a10bdad497b9a4d336fc617aa495299f75dc3716 Mail-SpamAssassin-3.3.0-rc3.zip
ecdc6bf631586b099f3222117bc2e79789dd9fa8
Mail-SpamAssassin-rules-3.3.0-rc3.r899655.tgz
proposed release announcement is there too:
http://people.apache.org/~jm/devel/PROPOSED-3.3.0-rc3.txt
please vote. cheers ;)
--
--j.
On Friday 15 January 2010 16:29:42 Justin Mason wrote:
PROPOSED 3.3.0-rc
Downloads are available from:
please vote. cheers ;)
If there is an intention to add 'use bytes' into Message.pm,
then it would be better to do it in rc3, and not at the
time of a final release.
Mark
On Jan 15, 2010, at 9:38 AM, Mark Martinec wrote:
On Friday 15 January 2010 16:29:42 Justin Mason wrote:
PROPOSED 3.3.0-rc
Downloads are available from:
please vote. cheers ;)
If there is an intention to add 'use bytes' into Message.pm,
then it would be better to do it in rc3
Mail-SpamAssassin-3.3.0-rc3.tar.gz
a10bdad497b9a4d336fc617aa495299f75dc3716 Mail-SpamAssassin-3.3.0-rc3.zip
ecdc6bf631586b099f3222117bc2e79789dd9fa8
Mail-SpamAssassin-rules-3.3.0-rc3.r899655.tgz
proposed release announcement is there too:
http://people.apache.org/~jm/devel/PROPOSED-3.3.0-rc3
On 01/15/2010 11:13 AM, Warren Togami wrote:
-1
Even though my rc3 was unofficial, it is entirely uncool from packager
perspective to reuse names. Names are meaningless and cheap. This should
have been named rc4.
Furthermore I am unconvinced that we should change the use bytes thing
at this
On 01/15/2010 11:25 AM, Warren Togami wrote:
Could someone provide a sample message that takes an obscene amount of
time?
Warren
Furthermore, what is releasing an official rc3 at this point going to
gain us, especially if it will take 3 days to become an official release?
Warren
To be 100%
or reopen a past bug?
Regards,
KAM
- Original Message -
From: Justin Mason j...@jmason.org
To: SpamAssassin Dev dev@spamassassin.apache.org
Sent: Friday, January 15, 2010 10:29 AM
Subject: PROPOSED 3.3.0-rc3
Downloads are available from:
http://people.apache.org/~jm/devel/
md5sum
: PROPOSED 3.3.0-rc3
Downloads are available from:
http://people.apache.org/~jm/devel/
md5sum of archive files:
015d42846c819ce3aa286650bb54b53e Mail-SpamAssassin-3.3.0-rc3.tar.bz2
be83248ba40ed12a20bc1f8aab8cfa7f Mail-SpamAssassin-3.3.0-rc3.tar.gz
a35927c52d9554f0305af584097314c2
On 01/15/2010 12:08 PM, Justin Mason wrote:
We've had miscommunication. I was the under the impression you were
going to call your tarballs rc3-unofficial to differentiate them
from the real rc3; this didn't match what you were thinking,
clearly. We should have had a better agreement in
On 01/15/2010 11:38 AM, Kevin A. McGrail wrote:
t/timeout.ok 15/33# Failed test 16 in
t/timeout.t at line 99
t/timeout.FAILED test 16
Failed 1/33 tests, 96.97% okay
I saw something like this while cutting rc1. The test failed once, but
I
On Friday 15 January 2010 17:38:38 Kevin A. McGrail wrote:
I tried simply a make test on the rc3 and failed on timeout.t and
sa_compile.t with long tests and net tests.
sa_compile is:
t/sa_compile..ok 1/5Can't exec re2c: No such file or
directory at
6.36
On Fri, Jan 15, 2010 at 17:15, Warren Togami wtog...@redhat.com wrote:
On 01/15/2010 11:38 AM, Kevin A. McGrail wrote:
t/timeout.ok 15/33# Failed test 16 in
t/timeout.t at line 99
t/timeout.FAILED test 16
Failed 1/33 tests, 96.97% okay
Warren Togami wrote:
On 01/15/2010 11:38 AM, Kevin A. McGrail wrote:
t/timeout.ok 15/33# Failed test 16 in
t/timeout.t at line 99 t/timeout.FAILED test
16 Failed 1/33 tests, 96.97% okay
I saw something like this while cutting rc1. The test
It can fail on a heavily loaded machine, as it is a
real-time test. Before opening a bug, try it again.
Sorry, wrong quote,
I was referring to the:
t/timeout.ok 15/33
# Failed test 16 in t/timeout.t at
line 99
Mark
Mark, what version of MakeMaker is needed to satisfy those concerns you
had about my cuts?
Warren
On 01/15/2010 12:20 PM, Justin Mason wrote:
6.36
On Fri, Jan 15, 2010 at 17:15, Warren Togamiwtog...@redhat.com wrote:
On 01/15/2010 11:38 AM, Kevin A. McGrail wrote:
On Friday 15 January 2010 18:20:58 Randal, Phil wrote:
I had the same problem on a test CentOS 5.4 VM with with Warren's
3.3.0 rc3 yesterday.
Also on the same test #16?
Is this a virtual machine? I don't have much confidence
in real-time timing on virtual machines.
Mark
code. :-(
regards,
KAM
- Original Message -
From: Mark Martinec mark.martinec...@ijs.si
To: dev@spamassassin.apache.org
Sent: Friday, January 15, 2010 12:22 PM
Subject: Re: PROPOSED 3.3.0-rc3
It can fail on a heavily loaded machine, as it is a
real-time test. Before opening a bug, try
Looks ok, except again for the missing 'license: apache',
'recommends:' and 'resources:' sections in META.yml
due to using an older ExtUtils::MakeMaker (6.42 vs. 6.55).
Mark, what version of MakeMaker is needed to satisfy those concerns you
had about my cuts?
Seems the
Looks ok, except again for the missing 'license: apache',
'recommends:' and 'resources:' sections in META.yml
due to using an older ExtUtils::MakeMaker (6.42 vs. 6.55).
Mark, what version of MakeMaker is needed to satisfy those concerns you
had about my cuts?
Seems the
Michael Parker wrote:
If there is an intention to add 'use bytes' into Message.pm,
then it would be better to do it in rc3, and not at the
time of a final release.
We really need a freqdiff with the use bytes change on as many
messages as possible before I think its safe to go with the
On Friday, January 15, 2010, Mark Martinec mark.martinec...@ijs.si wrote:
Looks ok, except again for the missing 'license: apache',
'recommends:' and 'resources:' sections in META.yml
due to using an older ExtUtils::MakeMaker (6.42 vs. 6.55).
Mark, what version of MakeMaker is needed to
On Friday, January 15, 2010, Warren Togami wtog...@redhat.com wrote:
On 01/15/2010 11:13 AM, Warren Togami wrote:
-1
Even though my rc3 was unofficial, it is entirely uncool from packager
perspective to reuse names. Names are meaningless and cheap. This should
have been named rc4.
On Jan 15, 2010, at 2:12 PM, Mark Martinec wrote:
Michael Parker wrote:
If there is an intention to add 'use bytes' into Message.pm,
then it would be better to do it in rc3, and not at the
time of a final release.
We really need a freqdiff with the use bytes change on as many
messages as
On 01/15/2010 04:03 PM, Michael Parker wrote:
BTW, I've seen this slowdown in some of the stuff I've been working on.
I would be very happy if it was resolved for 3.3.0.
+1 for getting use bytes changes into 3.3.0.
Michael
Are we certain this change is safe?
Are the results of regex
@spamassassin.apache.org
Subj:Re: PROPOSED 3.3.0-rc3
On Friday, January 15, 2010, Warren Togami wtog...@redhat.com wrote:
On 01/15/2010 11:13 AM, Warren Togami wrote:
-1
Even though my rc3 was unofficial, it is entirely uncool from packager
perspective to reuse names. Names are meaningless and cheap
Can we make use bytes a .pre configurable option?
--- Original Message ---
From:Warren Togami wtog...@redhat.com
Sent:Fri 1/15/10 4:17 pm
To:Michael Parker park...@pobox.com
Cc:Mark Martinec mark.martinec...@ijs.si, dev@spamassassin.apache.org
Subj:Re: PROPOSED 3.3.0-rc3
On 01/15/2010 04:03 PM
concensus now might be
better done starting sunday or monday.
--- Original Message ---
From:Justin Mason j...@jmason.org
Sent:Fri 1/15/10 3:45 pm
To:Warren Togami wtog...@redhat.com
Cc:Justin Mason j...@jmason.org,SpamAssassin Dev
dev@spamassassin.apache.org
Subj:Re: PROPOSED 3.3.0-rc3
.
--- Original Message ---
From:Justin Mason j...@jmason.org
Sent:Fri 1/15/10 3:45 pm
To:Warren Togami wtog...@redhat.com
Cc:Justin Mason j...@jmason.org,SpamAssassin Dev dev@spamassassin.apache.org
Subj:Re: PROPOSED 3.3.0-rc3
On Friday, January 15, 2010, Warren Togami wtog...@redhat.com
wrote:
On 01/15
On Sat, Aug 8, 2009 at 01:14, Mark Martinecmark.martinec...@ijs.si wrote:
t/whitelist_from.t fails because there is no 60_whitelist.cf in
the rules directory (or subsequently in the log/test_rules_copy/).
Same for t/spf.t, it is missing a 25_spf.cf and 60_whitelist_spf.cf
files in rules.
On Sunday 09 August 2009 15:33:00 Justin Mason wrote:
Updated t/data/01_test_rules.cf in trunk, r802274.
does it fix the bug?
I believe it does, according to my tests.
if so, why?
It adds the missing rules:
header USER_IN_DEF_WHITELIST eval:check_from_in_default_whitelist()
header
On 08/07/2009 03:45 PM, Warren Togami wrote:
I might be missing something obvious, but what is the solution to this?
I don't see it in INSTALL.
Warren
I can't run sa-update without --install during the RPM package build.
The package builders are firewalled away from the network for security
channel: updates.spamassassin.org: --install file
Mail-SpamAssassin-rules-3.3.0-alpha2.tgz does not contain
a 3-digit version number!
It appears that I want to run this after make install. Should I be
renaming the tarball for now? What is the official way to use sa-update
--install?
Hi all! here's the announce mail and tarballs for this alpha. please vote!
--
To: users, dev, announce
Subject: ANNOUNCE: Apache SpamAssassin 3.3.0-alpha2 available
Apache SpamAssassin
Justin Mason writes:
Hi all! here's the announce mail and tarballs for this alpha.
please vote!
Apache SpamAssassin 3.3.0-alpha2 is now available for testing.
+1
Looks good, runs fine here.
Perhaps a note on how to install rules would be in order,
it always costs me a couple of minutes to
On Fri, Aug 7, 2009 at 15:56, Mark Martinecmark.martinec...@ijs.si wrote:
Justin Mason writes:
Hi all! here's the announce mail and tarballs for this alpha.
please vote!
Apache SpamAssassin 3.3.0-alpha2 is now available for testing.
+1
Looks good, runs fine here.
Perhaps a note on how
To: dev@spamassassin.apache.org
Sent: Friday, August 07, 2009 10:56 AM
Subject: Re: [vote] proposed 3.3.0-alpha2 release
Justin Mason writes:
Hi all! here's the announce mail and tarballs for this alpha.
please vote!
Apache SpamAssassin 3.3.0-alpha2 is now available for testing.
+1
Looks good
I'm unfortunately not sure on a +1. Still failing on SPF and whitelist
tests.
The Razor failures, you can ignore. Those are known issues.
Failed TestStat Wstat Total Fail Failed List of Failed
---
Good catch. So how to install the rules for the tests but not overwrite the
main system installation?
Regards,
KAM
- Original Message -
From: Mark Martinec mark.martinec...@ijs.si
To: dev@spamassassin.apache.org
Sent: Friday, August 07, 2009 12:44 PM
Subject: Re: [vote] proposed
On Fri, Aug 7, 2009 at 17:44, Mark Martinecmark.martinec...@ijs.si wrote:
I'm unfortunately not sure on a +1. Still failing on SPF and whitelist
tests.
The Razor failures, you can ignore. Those are known issues.
Failed Test Stat Wstat Total Fail Failed List of Failed
On 08/07/2009 11:00 AM, Justin Mason wrote:
On Fri, Aug 7, 2009 at 15:56, Mark Martinecmark.martinec...@ijs.si wrote:
Justin Mason writes:
Hi all! here's the announce mail and tarballs for this alpha.
please vote!
Apache SpamAssassin 3.3.0-alpha2 is now available for testing.
+1
Looks
Subject: [vote] proposed 3.3.0-alpha2 release
Hi all! here's the announce mail and tarballs for this alpha. please
vote!
--
To: users, dev, announce
Subject: ANNOUNCE: Apache SpamAssassin 3.3.0
On 08/07/2009 01:30 PM, Warren Togami wrote:
that's in the INSTALL doc, right? but sure, it should probably be a
paragraph in the announce mail because it'll catch everyone up.
actually, IMO most people should probably just run sa-update without
--install if possible...
--j.
I might be
On 08/07/2009 02:55 PM, Randal, Phil wrote:
On my test box,
Make install
Fails to install v330.pre (it's not even mentioned in the
config__install section of the Makefile).
Cheers,
Phil
Makefile.PL contains...
conf__install:
-$(MKPATH) $(B_CONFDIR)
$(PERL) -MFile::Copy -e
t/whitelist_from.t fails because there is no 60_whitelist.cf in
the rules directory (or subsequently in the log/test_rules_copy/).
Same for t/spf.t, it is missing a 25_spf.cf and 60_whitelist_spf.cf
files in rules.
Justin Mason wrote:
those rules are all duplicated (more or less) in
ok, that's 4 +1's -- Mark, go ahead and mention those tarballs if you like!
(I'll leave them on /~jm/devel/ ).
Thank you guys, and to Justin especially!
My presentation on Amavis went well, many people attended,
and I spent a couple of minutes on SpamAssassin 3.3,
after making an official
BTW, don't forget. If you make install this, you need to either run
sa-update immediately, or download the rules .tgz and sa-update
--install it, as 3.3.0 doesn't come with any rules bundled by
default.
Anyone planning to give another +1 so Mark can talk about it tomorrow? ;)
--j.
On Wed, Jul
On 7/2/2009 11:40 AM, Justin Mason wrote:
BTW, don't forget. If you make install this, you need to either run
sa-update immediately, or download the rules .tgz and sa-update
--install it, as 3.3.0 doesn't come with any rules bundled by
default.
Anyone planning to give another +1 so Mark can
On Thu, 02 Jul 2009 00:13:52 +0200, Kevin A. McGrail kmcgr...@pccc.com
wrote:
I'm running long tests and net tests and getting a lot of failures in
the DKIM area. I'm running 0.28.
Is this a known issue? Should I upgrade DKIM and try again which would
like make me suggest a higher
,
},
Regards,
KAM
- Original Message -
From: Justin Mason j...@jmason.org
To: dev@spamassassin.apache.org
Sent: Thursday, July 02, 2009 5:40 AM
Subject: Re: [vote] proposed 3.3.0-alpha1 release
BTW, don't forget. If you make install this, you need to either run
sa-update immediately
And/or edit the Mail::SpamAssassin::Util::DependencyInfo as well.
- Original Message -
From: Kevin A. McGrail kmcgr...@pccc.com
To: Justin Mason j...@jmason.org; dev@spamassassin.apache.org
Sent: Thursday, July 02, 2009 8:57 AM
Subject: Re: [vote] proposed 3.3.0-alpha1 release
I'll
...ok
Regards,
KAM
- Original Message -
From: Mark Martinec mark.martinec...@ijs.si
To: dev@spamassassin.apache.org
Sent: Thursday, July 02, 2009 6:53 AM
Subject: Re: [vote] proposed 3.3.0-alpha1 release
On Thu, 02 Jul 2009 00:13:52 +0200, Kevin A. McGrail kmcgr...@pccc.com
wrote:
I'm
AM
Subject: Re: [vote] proposed 3.3.0-alpha1 release
BTW, don't forget. If you make install this, you need to either run
sa-update immediately, or download the rules .tgz and sa-update
--install it, as 3.3.0 doesn't come with any rules bundled by
default.
Anyone planning to give another
ok, that's 4 +1's -- Mark, go ahead and mention those tarballs if you like!
(I'll leave them on /~jm/devel/ ).
--j.
On Thu, Jul 2, 2009 at 10:49, Yet Another Ninjasa-l...@alexb.ch wrote:
On 7/2/2009 11:40 AM, Justin Mason wrote:
BTW, don't forget. If you make install this, you need to either
Hi guys -- I've cut tarballs for the alpha. Here goes! Please give me a few
votes for a public release of these (my vote: +1 of course). Here's the
proposed announcement...
To: users, dev, announce
Subject: ANNOUNCE: Apache SpamAssassin 3.3.0-alpha1 available
Apache SpamAssassin 3.3.0-alpha1
1 - 100 of 102 matches
Mail list logo
