You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jesse Norell <je...@kci.net> on 2014/09/10 18:59:51 UTC

MSPIKE in older SA ?

Is there any reason you should not use MSPIKE in versions older than
3.4.0?

Eg. on debian box with 3.3.2, I have 20_mailspike.cf; I commented the
version check out, tested that spamassassin --lint was happy, recompiled
rules and I now have MSPIKE rules hitting.  Am I missing something?  Or
is that just there to try to persuade people towards upgrading versions?

Thanks,

-- 
Jesse Norell
Kentec Communications, Inc.
970-522-8107  -  www.kci.net


Re: MSPIKE in older SA ?

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/10/2014 1:36 PM, Jesse Norell wrote:
> Would you consider changing the version check in official 
> 20_mailspike.cf to allow 3.3.2 to use those by default?
Jesse,

For me, I am neutral on the matter as my energies are focused on 3.4.1 
to release on 9/30.

But this will need 3 explicit +1's from committers/PMC members because 
there is clear debate from prior that would have to be overridden.

I will say, I don't know how long sa-update will work for 3.3.2. 
Eventually, we have to move on and not support old releases though right 
now the status quo of trying our best is ok.

Regards,
KAM




Re: MSPIKE in older SA ?

Posted by Jesse Norell <je...@kci.net>.
On Wed, 2014-09-10 at 13:10 -0400, Kevin A. McGrail wrote:
> On 9/10/2014 12:59 PM, Jesse Norell wrote:
> > Is there any reason you should not use MSPIKE in versions older than
> > 3.4.0?
> >
> > Eg. on debian box with 3.3.2, I have 20_mailspike.cf; I commented the
> > version check out, tested that spamassassin --lint was happy, recompiled
> > rules and I now have MSPIKE rules hitting.  Am I missing something?  Or
> > is that just there to try to persuade people towards upgrading versions?
> 
> When Mailspike was evaluated, the project did not like the concept of 
> adding RBLs except during larger releases.
> 
> However, I am not aware of a technical reason it will not work well with 
> 3.3.2.

Would you consider changing the version check in official
20_mailspike.cf to allow 3.3.2 to use those by default?


> There was no concern about pushing people to new versions though the 
> project did clarify both our release goals and how long we will support 
> an older release at http://wiki.apache.org/spamassassin/ReleaseGoals
> 
> This means as of August 11th, 2014 3.3.2 is effectively unsupported.

Pretty, please?  :)

Thanks,
Jesse



> Regards,
> KAM


-- 
Jesse Norell
Kentec Communications, Inc.
970-522-8107  -  www.kci.net


Re: MSPIKE in older SA ?

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 9/10/2014 12:59 PM, Jesse Norell wrote:
> Is there any reason you should not use MSPIKE in versions older than
> 3.4.0?
>
> Eg. on debian box with 3.3.2, I have 20_mailspike.cf; I commented the
> version check out, tested that spamassassin --lint was happy, recompiled
> rules and I now have MSPIKE rules hitting.  Am I missing something?  Or
> is that just there to try to persuade people towards upgrading versions?

When Mailspike was evaluated, the project did not like the concept of 
adding RBLs except during larger releases.

However, I am not aware of a technical reason it will not work well with 
3.3.2.

There was no concern about pushing people to new versions though the 
project did clarify both our release goals and how long we will support 
an older release at http://wiki.apache.org/spamassassin/ReleaseGoals

This means as of August 11th, 2014 3.3.2 is effectively unsupported.

Regards,
KAM

Re: MSPIKE in older SA ?

Posted by Benny Pedersen <me...@junc.eu>.
On 10. sep. 2014 19.58.18 "Kevin A. McGrail" <KM...@PCCC.com> wrote:

> I will say, I don't know how long sa-update will work for 3.3.2.
> Eventually, we have to move on and not support old releases though right
> now the status quo of trying our best is ok.

3.3.2 is still latest stable in gentoo, i have unofficial 3.4.1 in my overlay
3.4.0 is in my overlay, but still miss fixing dependics for redis