You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Per Jessen <pe...@computer.org> on 2005/01/06 09:54:32 UTC

maintaining the 2.6 branch (was: [2.64] FORGED_MUA_OUTLOOK buggy)

Ron Johnson wrote:

>> Per Jessen wrote:
>> >  Show of hands,
>> > who's still on 2.64 with no exact plans to upgrade?

Alright, so far I've seen 4-5, maybe 6 people saying they intend to stick to
2.64 for the foreseeable future.  Is that really all? 
I'm quite willing myself to put an effort in in maintaining 2.64, and I'll
probably be doing it on a personal level anyway, but to work to produce actual
releases for others, I think a bit more of an interest is needed. 



-- 
Per Jessen, Zurich
Let your spam stop here -- http://www.spamchek.ch



Re: maintaining the 2.6 branch

Posted by Martin Hepworth <ma...@solid-state-logic.com>.
and me..no had time to upgrade thus far and 2.64 does a very nice job..


--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300


John Hardin wrote:
> On Thu, 2005-01-06 at 00:54, Per Jessen wrote:
> 
>>Ron Johnson wrote:
>>
>>
>>>>Per Jessen wrote:
>>>>
>>>>> Show of hands,
>>>>>who's still on 2.64 with no exact plans to upgrade?
>>
>>Alright, so far I've seen 4-5, maybe 6 people saying they intend to stick to
>>2.64 for the foreseeable future.  Is that really all? 
> 
> 
> <aol>
> Me too.
> </aol>
> 
>

**********************************************************************

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.

**********************************************************************


RE: maintaining the 2.6 branch (was: [2.64] FORGED_MUA_OUTLOOKbuggy)

Posted by "Michele Neylon :: Blacknight Solutions" <mi...@blacknightsolutions.com>.
Although we have upgraded on most of our systems I am not too enthused with
the idea of touching our main gateway. It works, so I don't want to break
it.

Michele

Mr Michele Neylon
Blacknight Internet Solutions Ltd
Hosting, co-location & domains
http://www.blacknight.ie/
Tel. +353 59 9137101
http://www.blacknight.ie/specialoffers.html

 


-- 
Email scanned by Blacknight for viruses and dangerous content.
Visit http://www.blacknight.ie for more information


Re: maintaining the 2.6 branch (was: [2.64] FORGED_MUA_OUTLOOK buggy)

Posted by John Hardin <jo...@aproposretail.com>.
On Thu, 2005-01-06 at 00:54, Per Jessen wrote:
> Ron Johnson wrote:
> 
> >> Per Jessen wrote:
> >> >  Show of hands,
> >> > who's still on 2.64 with no exact plans to upgrade?
> 
> Alright, so far I've seen 4-5, maybe 6 people saying they intend to stick to
> 2.64 for the foreseeable future.  Is that really all? 

<aol>
Me too.
</aol>

--
John Hardin
Development and Technology group (Seattle)
CRS Retail Systems, Inc.
3400 188th Street SW, Suite 185
Lynnwood, WA 98037
voice: (425) 672-1304
  fax: (425) 672-0192
email: jhardin@crsretail.com
  web: http://www.crsretail.com
-----------------------------------------------------------------------
 If you smash a computer to bits with a mallet, that appears to count
 as encryption in the state of Nevada.
                                               - CRYPTO-GRAM 12/2001
-----------------------------------------------------------------------


Re: maintaining the 2.6 branch

Posted by Matt Kettler <mk...@evi-inc.com>.
At 06:42 AM 1/10/2005, Martin Hepworth wrote:
>I've been doing some testing ove the last couple of days with 3.02 and 
>found it's scores are way lower on all test emails than 2.64. (anywhere 
>upto 33% lower in limited tests).
>
>I've managed to get most of my 2.64 rules etc over (along with bayes), but 
>I'm nervous about switching given the amount of spam 2.64 IS catching vs 
>3.02 MIGHT miss.
>
>Alot of the defaults rules have reduced scores (esp when running bayes+net 
>combination) and I don't want to give my users the spam.
>
>I've seen several other people that complain/note this issue as well so it 
>seems I'm not alone on this.
>
>I shall be sticking to 2.64 for the forsee-able future as 3.02 gives me no 
>advantage and quite a high likelihood of more spam dropping through the system!

Question on this test:

Did you use SA 2.64 stock, or with add-ons? Most importantly, did you use 
the SpamCopURI plugin with 2.64.

One thing to keep in mind is that by adding rules, particularly SpamCopURI, 
to 2.64 without adjusting any other scores, you've effectively increased 
the average score of a spam message by a great deal.

This is what happens whenever you add spam rules that haven't been run 
through the GA and/or perceptron.

You get a higher average score, lower FN rate, higher FP rate. It's the way 
of the universe unless the added rules have a true 0% FP rate. I know of 
very few rules with a true 0FP rate. Clearly little or nothing from 
SpamAssassin's standard rules, SARE, or any other add-on source would get 0 
FP's in a 100K ham/100k spam email test unless it matched no spam either.

SA generally tunes it's scores in a VERY conservative manner, with the 
assumption that FPs are 100 times worse than FNs. The default SpamCopURI 
scores clearly don't reflect this mentality, as the default scores are much 
more likely to cause 1 FP than 100 FNs.

The default scores for Mail::SpamCopURI were set up using the SARE general 
guideline of looking at the S/O of the rule and scoring it. Unfortunately, 
this doesn't take into account overlap.

If SC fires, WS nearly ALWAYS fires too. On my system, less than 5% of 
SPAMCOP_URI_RBL matches did not also match WS_URI_RBL.

Less than 10% of SC matches did not also match OB.

But when you combine the two, Less than 0.65% of SPAMCOP_URI_RBL hits 
matched neither WS nor OB.

The combined score of spamcop with either of the other two rules under 
Mail::SpamCopURI is 5.1, This effectively makes the spamcop URI list 
implicitly trusted for 99.35% of it's hits. The spamcop URI list has an 
impressively low FP rate, but it's not zero.


Be careful when comparing SA versions that you're comparing apples to 
apples. Don't compare SA 3.0.2 to an unbalanced version of 2.64 which has 
an unrealistically high score bias, and FP rate, compared to the stock system.











Re: maintaining the 2.6 branch

Posted by Per Jessen <pe...@computer.org>.
Martin Hepworth wrote:

> Another reason....
[snip]
> I shall be sticking to 2.64 for the forsee-able future as 3.02 gives me
> no advantage and quite a high likelihood of more spam dropping through
> the system!

Not specific to Martins reply, but thanks to all the responses regarding continued use of
SA2.64.  I'd like to be able to offer to take on 2.64 maintenance (with the help of others),
but I would simply be biting over too much.  For the moment anyway.  

One thing that occurred to me just now - some of the problems we've discussed, like the
FORGED_MUA_OUTLOOK, are purely to do with the rulesets/-definitions.  Has any thought been
given to producing separate "packages" for SA code and SA rules?  For 2.6 or 3.0?  Along the
lines of what ClamAV does perhaps.


/Per Jessen, Zürich

-- 
http://www.spamchek.com/freetrial - sign up for your free 30-day trial now!
http://www.spamchek.de/freetrial - jetzt für 30 Tage ausprobieren - kostenlos und unverbindlich!
http://www.spamchek.dk/freetrial - 30 dages gratis prøvetid - helt uden forpligtelser!


Re: maintaining the 2.6 branch

Posted by Martin Hepworth <ma...@solid-state-logic.com>.
Another reason....

I've been doing some testing ove the last couple of days with 3.02 and 
found it's scores are way lower on all test emails than 2.64. (anywhere 
upto 33% lower in limited tests).

I've managed to get most of my 2.64 rules etc over (along with bayes), 
but I'm nervous about switching given the amount of spam 2.64 IS 
catching vs 3.02 MIGHT miss.

Alot of the defaults rules have reduced scores (esp when running 
bayes+net combination) and I don't want to give my users the spam.

I've seen several other people that complain/note this issue as well so 
it seems I'm not alone on this.

I shall be sticking to 2.64 for the forsee-able future as 3.02 gives me 
no advantage and quite a high likelihood of more spam dropping through 
the system!

--
Martin Hepworth
Snr Systems Administrator
Solid State Logic
Tel: +44 (0)1865 842300


Per Jessen wrote:
> Ron Johnson wrote:
> 
> 
>>>Per Jessen wrote:
>>>
>>>> Show of hands,
>>>>who's still on 2.64 with no exact plans to upgrade?
> 
> 
> Alright, so far I've seen 4-5, maybe 6 people saying they intend to stick to
> 2.64 for the foreseeable future.  Is that really all? 
> I'm quite willing myself to put an effort in in maintaining 2.64, and I'll
> probably be doing it on a personal level anyway, but to work to produce actual
> releases for others, I think a bit more of an interest is needed. 
> 
> 
> 

**********************************************************************

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote confirms that this email message has been swept
for the presence of computer viruses and is believed to be clean.

**********************************************************************


Re: maintaining the 2.6 branch (was: [2.64] FORGED_MUA_OUTLOOK buggy)

Posted by Ragnar Paulson <ra...@wanware.com>.
We have a half dozen or so customers where we have installed 2.6x and run it for all our inhouse e-mail. Does a wonderful job with a minumum amount of care and feeding, just move missed spam into a special folder for nightly bayesian retraining and we're catching over 95% of SPAM.

Our goal is to spend less time per day on the care and feeding of the spam filter then we would on deleting the spam manually. :)  That means the time and effort required to re-integrate spamassassin into our mail servers, with whatever ancillary changes become requisite, and testing/qa time, ... all that time must occur infrequently.

Ragnar Paulson
The Software Group Limited

----- Original Message ----- 
From: "Per Jessen" <pe...@computer.org>
To: <us...@spamassassin.apache.org>
Sent: Thursday, January 06, 2005 3:54 AM
Subject: maintaining the 2.6 branch (was: [2.64] FORGED_MUA_OUTLOOK buggy)


> Ron Johnson wrote:
> 
> >> Per Jessen wrote:
> >> >  Show of hands,
> >> > who's still on 2.64 with no exact plans to upgrade?
> 
> Alright, so far I've seen 4-5, maybe 6 people saying they intend to stick to
> 2.64 for the foreseeable future.  Is that really all? 
> I'm quite willing myself to put an effort in in maintaining 2.64, and I'll
> probably be doing it on a personal level anyway, but to work to produce actual
> releases for others, I think a bit more of an interest is needed. 
> 
> 
> 
> -- 
> Per Jessen, Zurich
> Let your spam stop here -- http://www.spamchek.ch
> 
> 

RE: maintaining the 2.6 branch (was: [2.64] FORGED_MUA_OUTLOOK buggy)

Posted by Ray Anderson <rs...@rb-com.com>.
> Alright, so far I've seen 4-5, maybe 6 people saying they 
> intend to stick to
> 2.64 for the foreseeable future.  Is that really all? 
> I'm quite willing myself to put an effort in in maintaining 
> 2.64, and I'll
> probably be doing it on a personal level anyway, but to work 
> to produce actual
> releases for others, I think a bit more of an interest is needed. 

I am also required to stay with the 2.6 branch for the forseable future, if there's anything I can do to help I'd be happy to.

-=Ray
------------------------------------------------
Ray Anderson
System Development Manager
916.788.2444 (Office)
916.798.9439 (Mobile)
PRIDE Industries
rsa@prideindustries.com
http://www.prideindustries.com
------------------------------------------------
The winner (of an air battle) may have been determined by the amount of time, energy, thought and training an individual has
previously accomplished in an effort to increase his ability as a fighter pilot.
Commander Randy "Duke" Cunningham, USN, 5 Victories, Vietnam Conflict