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...@issues.apache.org on 2011/01/17 08:34:05 UTC
[Bug 6533] New: Rule FSL_RU_URL hits valid mails
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
Summary: Rule FSL_RU_URL hits valid mails
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Rules
AssignedTo: dev@spamassassin.apache.org
ReportedBy: azamat.hackimov@gmail.com
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.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
Doc Schneider <ma...@maddoc.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |maddoc@maddoc.net
--- Comment #2 from Doc Schneider <ma...@maddoc.net> 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
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
Karsten Bräckelmann <gu...@rudersport.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #7 from Karsten Bräckelmann <gu...@rudersport.de> 2011-03-21 19:08:59 EDT ---
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.)
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
Doc Schneider <ma...@maddoc.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Doc Schneider <ma...@maddoc.net> 2011-01-17 10:36:01 UTC ---
Fixed the offending rule so narking this as fixed.
-Doc
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
Azamat Hackimov <az...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |azamat.hackimov@gmail.com
--- Comment #6 from Azamat Hackimov <az...@gmail.com> 2011-02-02 01:59:05 EST ---
Any progress there? Rule is still active.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
Warren Togami <wt...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
--- Comment #5 from Warren Togami <wt...@gmail.com> 2011-01-17 22:22:11 UTC ---
reopening
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Justin Mason <jm...@jmason.org>.
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
> What about this issue? How do we force a sa-update push? I'm guessing it
> is a matter of logging into zones and manually running a script?
regarding this -- I'm a little out of the loop and can't say for sure. That bug
seems to suggest that the script should work, but it's been a while since
I've looked into it.
--j.
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Doc Schneider <ma...@maddoc.net>.
I had my rule set for a score of 0.01 but due to the lack of valid
Russian ham it got the high score.
So I added the tflags nopublish to it.
I'm also +1 on adding that to the wiki.
-Doc
Kevin A. McGrail wrote:
> +1 here as well with the sandbox clarification. I'll add that to the wiki.
> Regards,
> KAM
>
> "Justin Mason" <jm...@jmason.org> wrote:
>
>> "tflags nopublish" gets my vote.
>>
>> --j.
>>
>> On Mon, Jan 17, 2011 at 10:02, Warren Togami Jr. <wt...@gmail.com>
>> wrote:
>>> On 01/16/2011 11:52 PM, Justin Mason wrote:
>>>> BTW, I am entirely in favour of changing other people's sandbox
>> rules,
>>>> if they are making it into production, haven't been touched in
>> several
>>>> months and are likely unmaintained. Â (It might be friendly to mail
>>>> them to notify that you're making the change, however, but that's up
>>>> to you, ymmv.)
>>>>
>>>> --j.
>>> In this case, do you feel nopublish or 73_sandbox_manual_scores.cf
>> would be
>>> better? Â During 2009 I had a similar prejudiced rule against .cn
>> URI's. Â I
>>> felt it was inappropriate to push it even as informational in
>> production so
>>> I made it nopublish.
>>>
>>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
>>> What about this issue? Â How do we force a sa-update push? Â I'm
>> guessing it
>>> is a matter of logging into zones and manually running a script?
>>>
>>> Warren
>>>
--
-Doc Schneider Lincoln, NE.
Penguins: Do it on the ice.
Cairns: Do it underground
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
+1 here as well with the sandbox clarification. I'll add that to the wiki.
Regards,
KAM
"Justin Mason" <jm...@jmason.org> wrote:
>"tflags nopublish" gets my vote.
>
>--j.
>
>On Mon, Jan 17, 2011 at 10:02, Warren Togami Jr. <wt...@gmail.com>
>wrote:
>> On 01/16/2011 11:52 PM, Justin Mason wrote:
>>>
>>> BTW, I am entirely in favour of changing other people's sandbox
>rules,
>>> if they are making it into production, haven't been touched in
>several
>>> months and are likely unmaintained. (It might be friendly to mail
>>> them to notify that you're making the change, however, but that's up
>>> to you, ymmv.)
>>>
>>> --j.
>>
>> In this case, do you feel nopublish or 73_sandbox_manual_scores.cf
>would be
>> better? During 2009 I had a similar prejudiced rule against .cn
>URI's. I
>> felt it was inappropriate to push it even as informational in
>production so
>> I made it nopublish.
>>
>> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
>> What about this issue? How do we force a sa-update push? I'm
>guessing it
>> is a matter of logging into zones and manually running a script?
>>
>> Warren
>>
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Justin Mason <jm...@jmason.org>.
"tflags nopublish" gets my vote.
--j.
On Mon, Jan 17, 2011 at 10:02, Warren Togami Jr. <wt...@gmail.com> wrote:
> On 01/16/2011 11:52 PM, Justin Mason wrote:
>>
>> BTW, I am entirely in favour of changing other people's sandbox rules,
>> if they are making it into production, haven't been touched in several
>> months and are likely unmaintained. (It might be friendly to mail
>> them to notify that you're making the change, however, but that's up
>> to you, ymmv.)
>>
>> --j.
>
> In this case, do you feel nopublish or 73_sandbox_manual_scores.cf would be
> better? During 2009 I had a similar prejudiced rule against .cn URI's. I
> felt it was inappropriate to push it even as informational in production so
> I made it nopublish.
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
> What about this issue? How do we force a sa-update push? I'm guessing it
> is a matter of logging into zones and manually running a script?
>
> Warren
>
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 01/16/2011 11:52 PM, Justin Mason wrote:
> BTW, I am entirely in favour of changing other people's sandbox rules,
> if they are making it into production, haven't been touched in several
> months and are likely unmaintained. (It might be friendly to mail
> them to notify that you're making the change, however, but that's up
> to you, ymmv.)
>
> --j.
In this case, do you feel nopublish or 73_sandbox_manual_scores.cf would
be better? During 2009 I had a similar prejudiced rule against .cn
URI's. I felt it was inappropriate to push it even as informational in
production so I made it nopublish.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6365
What about this issue? How do we force a sa-update push? I'm guessing
it is a matter of logging into zones and manually running a script?
Warren
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Justin Mason <jm...@jmason.org>.
BTW, I am entirely in favour of changing other people's sandbox rules,
if they are making it into production, haven't been touched in several
months and are likely unmaintained. (It might be friendly to mail
them to notify that you're making the change, however, but that's up
to you, ymmv.)
--j.
On Mon, Jan 17, 2011 at 09:20, <bu...@issues.apache.org> wrote:
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
>
> --- Comment #1 from Warren Togami <wt...@gmail.com> 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.
>
> --
> Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
--- Comment #1 from Warren Togami <wt...@gmail.com> 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.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 1/18/2011 7:13 PM, Warren Togami Jr. wrote:
> On 01/18/2011 01:51 PM, Karsten Bräckelmann wrote:
>>
>>> Although is manual tarball surgery really the answer here?
>>
>> It's a single bad rule. The obvious fix is, to score it zero.
>>
>> I don't see us talking about automatic re-scoring, which would be an
>> entirely different topic. The last sa-update tarball is 3 weeks old.
>> While it *would* have pushed the updated rule-set by now, it seems to be
>> too complex to be required, just to get rid of a bad rule that never
>> should have been published to begin with.
>>
>
> BTW, who other than JM and I have access to the servers and the GPG keys?
>
Maddoc and I have access to both zones and zones2 now. The keys is
another thing to fix. Will look into getting myself on that list.
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 01/18/2011 01:51 PM, Karsten Bräckelmann wrote:
>
>> Although is manual tarball surgery really the answer here?
>
> It's a single bad rule. The obvious fix is, to score it zero.
>
> I don't see us talking about automatic re-scoring, which would be an
> entirely different topic. The last sa-update tarball is 3 weeks old.
> While it *would* have pushed the updated rule-set by now, it seems to be
> too complex to be required, just to get rid of a bad rule that never
> should have been published to begin with.
>
BTW, who other than JM and I have access to the servers and the GPG keys?
Warren
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 01/19/2011 03:25 AM, Kevin A. McGrail wrote:
>> It's a single bad rule. The obvious fix is, to score it zero.
>>
>> I don't see us talking about automatic re-scoring, which would be an
>> entirely different topic. The last sa-update tarball is 3 weeks old.
>> While it *would* have pushed the updated rule-set by now, it seems to be
>> too complex to be required, just to get rid of a bad rule that never
>> should have been published to begin with.
> +1. A band-aid is the first course of action. Triage and surgery on the
> underlying problem is related but not a blocker for this ticket to be
> closed.
>
> Regards,
> KAM
>
I'm now in agreement here.
Warren
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> It's a single bad rule. The obvious fix is, to score it zero.
>
> I don't see us talking about automatic re-scoring, which would be an
> entirely different topic. The last sa-update tarball is 3 weeks old.
> While it *would* have pushed the updated rule-set by now, it seems to be
> too complex to be required, just to get rid of a bad rule that never
> should have been published to begin with.
+1. A band-aid is the first course of action. Triage and surgery on
the underlying problem is related but not a blocker for this ticket to
be closed.
Regards,
KAM
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2011-01-18 at 13:39 -1000, Warren Togami Jr. wrote:
> On 01/18/2011 01:35 PM, Karsten Bräckelmann wrote:
> >> In any case, I looked at update-rules-3.3 as JM suggested would work. I
> >> think I know how it works. But I dare not run it without clarification
> >> from JM (which server to run it upon, what user, what directory) because
> >> I don't want to screw up the production sa-update channel. I haven't
> >> heard back from JM.
> >
> > So the process needs to be documented better? In this case, we would
> > need instructions for tarball surgery, toning down a score, and manually
> > push the result.
>
> And GPG signing.
Right, good point.
> Although is manual tarball surgery really the answer here?
It's a single bad rule. The obvious fix is, to score it zero.
I don't see us talking about automatic re-scoring, which would be an
entirely different topic. The last sa-update tarball is 3 weeks old.
While it *would* have pushed the updated rule-set by now, it seems to be
too complex to be required, just to get rid of a bad rule that never
should have been published to begin with.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 01/18/2011 01:35 PM, Karsten Bräckelmann wrote:
>> In any case, I looked at update-rules-3.3 as JM suggested would work. I
>> think I know how it works. But I dare not run it without clarification
>> from JM (which server to run it upon, what user, what directory) because
>> I don't want to screw up the production sa-update channel. I haven't
>> heard back from JM.
>
> So the process needs to be documented better? In this case, we would
> need instructions for tarball surgery, toning down a score, and manually
> push the result.
And GPG signing.
Although is manual tarball surgery really the answer here?
Warren
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2011-01-18 at 12:47 -1000, Warren Togami Jr. wrote:
> On 01/18/2011 09:44 AM, Karsten Bräckelmann wrote:
> >> --- Comment #4 from Warren Togami<wt...@gmail.com> 2011-01-17 22:20:21 UTC ---
> >> This isn't fixed until it is pushed to the sa-update channel.
> >
> > I don't want to start an edit-war, so I keep the bug in the REOPENED
> > state. However, I *do* want to clarify that sentence as-is is wrong.
> >
> > Resolved FIXED means in code.
> >
> > The equivalent, a bug targeted for $release, is resolved once the code
> > is in the appropriate branch, and voting has been done if required. It
> > does not remain open until an actual release.
>
> Please pardon me, but I must respectfully disagree that we should
> consider this "FIXED" if it is fixed in code. I understand where you
> are coming from.
It appears you did not carefully read my full post. The general picture
changes in the paragraphs you omitted to quote.
The above is correct, and I stand to what I have written. Moreover, this
particular bug itself is resolved -- unless there's another bug blocking
it, like the broken ability to publish rule updates. My entire comment
was rather generic, and I believe applies to all bug-tracking systems
out there.
> While I personally am not effected by this issue (no
> Russian users), I fear such a status could be confusing and upsetting to
> the user who submitted this bug report and others effected by the issue
> who look at the bug report.
I am used to explain these facts and workflow to users. I don't think
the concept would be news to you, dude. :)
Lagging of a few days pushing the re-cut due to dev resources should not
keep the bug open.
> In any case, I looked at update-rules-3.3 as JM suggested would work. I
> think I know how it works. But I dare not run it without clarification
> from JM (which server to run it upon, what user, what directory) because
> I don't want to screw up the production sa-update channel. I haven't
> heard back from JM.
So the process needs to be documented better? In this case, we would
need instructions for tarball surgery, toning down a score, and manually
push the result.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 01/18/2011 09:44 AM, Karsten Bräckelmann wrote:
>> --- Comment #4 from Warren Togami<wt...@gmail.com> 2011-01-17 22:20:21 UTC ---
>> This isn't fixed until it is pushed to the sa-update channel.
>
> I don't want to start an edit-war, so I keep the bug in the REOPENED
> state. However, I *do* want to clarify that sentence as-is is wrong.
>
> Resolved FIXED means in code.
>
> The equivalent, a bug targeted for $release, is resolved once the code
> is in the appropriate branch, and voting has been done if required. It
> does not remain open until an actual release.
Please pardon me, but I must respectfully disagree that we should
consider this "FIXED" if it is fixed in code. I understand where you
are coming from. While I personally am not effected by this issue (no
Russian users), I fear such a status could be confusing and upsetting to
the user who submitted this bug report and others effected by the issue
who look at the bug report.
In any case, I looked at update-rules-3.3 as JM suggested would work. I
think I know how it works. But I dare not run it without clarification
from JM (which server to run it upon, what user, what directory) because
I don't want to screw up the production sa-update channel. I haven't
heard back from JM.
Warren
Re: [Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
> --- Comment #4 from Warren Togami <wt...@gmail.com> 2011-01-17 22:20:21 UTC ---
> This isn't fixed until it is pushed to the sa-update channel.
I don't want to start an edit-war, so I keep the bug in the REOPENED
state. However, I *do* want to clarify that sentence as-is is wrong.
Resolved FIXED means in code.
The equivalent, a bug targeted for $release, is resolved once the code
is in the appropriate branch, and voting has been done if required. It
does not remain open until an actual release.
Lack of the ability to immediately push an update out, or automatic,
periodic updates failing are unrelated bugs. They are not inherently
part of each and every bug concerning rules.
The exception to that rule are dependencies. If you believe a bug is
sufficiently severe to depend on it (the infra being in place, mind you,
again not the actual pushing), then please make the bug reflect that
fact. Raise the severity and/or priority accordingly, and make the bug
"depend on" the relevant bug that also needs to be fixed.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Bug 6533] Rule FSL_RU_URL hits valid mails
Posted by bu...@issues.apache.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
--- Comment #4 from Warren Togami <wt...@gmail.com> 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...
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.