You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2010/03/14 02:14:11 UTC

[Bug 6374] New: adding xs.surbl.org into the 128th bit of multi.surbl.org

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6374

           Summary: adding xs.surbl.org into the 128th bit of
                    multi.surbl.org
           Product: Spamassassin
           Version: 3.3.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Rules
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: Mark.Martinec@ijs.si


Date: Fri, 12 Mar 2010 13:17:20 -0800    
From: Jeff Chan <je...@surbl.org>        
To: dev@spamassassin.apache.org          
Subject: xs.surbl.org                    

Hi Guys,
Would there be time for us to add xs.surbl.org into the 128th bit
of multi and get it into 3.3.1?  We would add much more data into
XS than currently is there.                                      

Cheers,
Jeff C.

============
Date: Fri, 12 Mar 2010 16:26:20 -0500
From: "Kevin A. McGrail" <KM...@PCCC.com>
CC: dev@spamassassin.apache.org             

Jeff,
As far as I know, all that really requires would be adding a rule and a 
masscheck to confirm the scoring:                                       

urirhssub       URIBL_XS_SURBL  multi.surbl.org.        A   128
body            URIBL_XS_SURBL  eval:check_uridnsbl('URIBL_XS_SURBL')
describe        URIBL_XS_SURBL  Contains an URL listed in the XS SURBL 
blocklist                                                              
tflags          URIBL_XS_SURBL  net                                    
#reuse          URIBL_XS_SURBL                                         

I've been testing with xs with a score of 2.0 since october of 2009 and 
I have no problem supporting this for consideration for the next        
release.  Here's the exact rule I've been testing:                      

urirhsbl  URIBL_XS_SURBL   xs.surbl.org.    A
body      URIBL_XS_SURBL   eval:check_uridnsbl('URIBL_XS_SURBL')
describe  URIBL_XS_SURBL   Has URI in XS - Testing              
tflags    URIBL_XS_SURBL   net                                  

score     URIBL_XS_SURBL   2.0

============
Date: Fri, 12 Mar 2010 16:29:48 -0500
From: "Kevin A. McGrail" <KM...@PCCC.com>
CC: dev@spamassassin.apache.org             

Following up my previous test, this rule does not require consideration 
for a specific release as it's a rule only and would work with 3.3.0,   
for example.  So all it needs to do is be approved as a rule added to   
sa-update for 3.3.X.                                                    

I think it could also be added for 3.2.X if we are still maintaining 
those rules as well.                                                 

This is the key point of separating the rules from the code.  If no code 
is needed, there is no need to wait for a release to add a good and      
valuable rule.                                                           

============
Date: Fri, 12 Mar 2010 19:51:13 -0500
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
To: dev@spamassassin.apache.org                     

Well, maybe not quite.  As recently mentioned we need to be careful
about how we go about releasing new network rules.  If a rule causes a
new lookup to be done (including if, like in this case, other existing
lookups shared by this rule are/could be disabled) we need to have a way
to notify users of the rule being added.  I suggested only adding new   
net rules in new code releases and ensuring they don't appear in old    
version updates by using "if version" lines.                            

============
Date: Sat, 13 Mar 2010 07:58:46 -0500
From: "Kevin A. McGrail" <KM...@PCCC.com>
CC: dev@spamassassin.apache.org             

Agree on being careful but not sure I agree that net rules only get 
released in new code.  Net rules are a big part of an effective     
anti-spam system but I see your point.                              

However, in light of your position, I believe I am right that this is a 
"simple" matter of testing a new net rule for 3.3.X branch from my      
original response?                                                      

============
Date: Sat, 13 Mar 2010 05:00:00 -0800
From: Jeff Chan <je...@surbl.org>    
To: dev@spamassassin.apache.org      

Thanks Daryl,
This brings up a couple questions:

1. How often are the scores for existing rules re-calculated?  If
we shuffled some of data for the existing SURBL lists internally,
they'd presumably need to be rescored.  Does that only happen at 
release time?                                                    

2. If we did want to add XS, when would 3.3.1 be likely to get
frozen?  (Partially depends on question 1.)                   

============
Date: Sat, 13 Mar 2010 18:20:27 -0500
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
To: dev@spamassassin.apache.org                     

So, just release some code, whenever.  Theo and I released 3.1 versions
every month for a while.  Somebody just needs the tuits to do it.  We  
have to have a way to give people heads up about new net rules.        
Releasing net rules without a heads up is unfair to both the users and 
DNSBL operators.  Imagine releasing a new net rule to 100 sites that   
process 50 million messages a day.  That could be un-good for an       
unsuspecting DNSBL operator.  Releasing a new net rule with a new      
version allows us to give users a heads up and DNSBL operators time to 
slowly ramp up query volume capacity.                                  

> However, in light of your position, I believe I am right that this is a
> "simple" matter of testing a new net rule for 3.3.X branch from my     
> original response?                                                     

Yeah, I'd just use whatever rules get generated by the weekly score gen
for net rules.                                                         

Do note that if the rule has been committed it had better have "if
version" lines around it.  Otherwise it's probably going to get released
in an update in about 4 hours.

============
Date: Sat, 13 Mar 2010 18:29:29 -0500
From: "Daryl C. W. O'Shea" <sp...@dostech.ca>
To: dev@spamassassin.apache.org

To date we've only done score generation for all rules for major
releases (3.0.0, 3.1.0, 3.2.0, 3.3.0).

Any major shuffling would affect how things should be scored... and
would affect people running not-the-latest-version no matter if we did a
new score generation exercise or not.

> 2. If we did want to add XS, when would 3.3.1 be likely to get
> frozen?  (Partially depends on question 1.)

Stable releases are frozen when they're ready for release.  It's a quick
process... somebody decides they want to do a release (hopefully with
others' agreement), they propose a release tarball, wait three days, and
release it.

If you want it in a 3.3 version it's not a big deal for us to release
3.3.2 a couple of weeks after 3.3.1.  There's no need to rush it into 3.3.1.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.