Bug 6533 - Rule FSL_RU_URL hits valid mails
Summary: Rule FSL_RU_URL hits valid mails
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: PC Linux
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-17 02:34 UTC by Azamat Hackimov
Modified: 2011-03-21 19:08 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Azamat Hackimov 2011-01-17 02:34:03 UTC 
Currently FSL_RU_URL gives score 3.499 2.271 3.499 2.271, it's too high for generic top-level domain. .ru domain is not only spam botnet. Please get lower score for this rule or remove it. Thank you.
Comment 1 Warren Togami 2011-01-17 04:20:01 UTC 
This is indeed a serious issue.

svn commit: r1025769 - /spamassassin/trunk/rulesrc/sandbox/maddoc/99_fsl_testing.cf

This was added to trunk in on October 20th, 2010

I guess this confirms that we do indeed have auto-promotion of rules from trunk to the 3.3.x sa-update channel.  It seems this point isn't clear to committers and thus mistakes are being made.  I sincerely hope the PMC can generally clarify the current processes so easy to understand procedures can be written down.

Mistakes
========
If I understand this situation correctly, here are a few of the mistakes...

1) Lack of clear understanding by committers of how rules are auto-promoted.

2) Lack of clear understanding by committers that the scores written in sandbox files are IGNORED by the scoring mechanism.  This is obviously a "prejudiced" rule that works great for many users but is wrong for others.  Indeed maddoc knew this, thus he committed a score of 0.01 to the sandbox with the intent of making it informational only.

3) Lack of clear understanding by committers that such "prejudiced" rules should never be committed to the sandbox without "tflags nopublish".

4) Our nightly masscheck corpora is apparently devoid of Russian ham, which would have caused this rule to fail auto-promotion.


Questions for PMC
=================
1) I have been asked to not make changes to other people's sandboxes.  But should I avoid doing so if the change is obviously correct like in this instance?

2) Do we have a mechanism to force a sa-update push?  Bug #6365 seems to indicate that we don't yet.
Comment 2 Doc Schneider 2011-01-17 10:31:10 UTC 
svn commit -m "fixed fsl rule"
Sending        maddoc/99_fsl_testing.cf
Transmitting file data .
Committed revision 1059952.

-Doc
Comment 3 Doc Schneider 2011-01-17 10:36:01 UTC 
Fixed the offending rule so narking this as fixed.

-Doc
Comment 4 Warren Togami 2011-01-17 22:20:21 UTC 
This isn't fixed until it is pushed to the sa-update channel.

/me looking at the code...
Comment 5 Warren Togami 2011-01-17 22:22:11 UTC 
reopening
Comment 6 Azamat Hackimov 2011-02-02 01:59:05 UTC 
Any progress there? Rule is still active.
Comment 7 Karsten Bräckelmann 2011-03-21 19:08:59 UTC 
Closing RESOLVED FIXED again. Published by now as a rule update.

(And just for the record: Resolved means in SVN, a bug does not stay in an open state until a release actually has been cut. Delayed automatic rule update generation is an unrelated issue.)