Aren't these not supposed to be published via sa-update?
meta T_DKIM_INVALID __DKIM_EXISTS !DKIM_VALID
mimeheaderT_DOS_ZIP_HARDCOREContent-Type =~
/^application\/zip;\sname=hardcore\.zip$/
body T_EMRCP/\bExcess Maximum Return Capital Profit\b/i
meta
Are they being used in a meta rule that auto promotes them?
On 11/21/2011 11:02 AM, dar...@chaosreigns.com wrote:
Aren't these not supposed to be published via sa-update?
meta T_DKIM_INVALID __DKIM_EXISTS !DKIM_VALID
mimeheaderT_DOS_ZIP_HARDCOREContent-Type =~
On 11/21, Kevin A. McGrail wrote:
Are they being used in a meta rule that auto promotes them?
Doesn't look like it. T_DKIM_INVALID, T_DOS_ZIP_HARDCORE,
T_FILL_THIS_FORM_SHORT, T_FORGED_TBIRD_IMG_SIZE, T_FRM_SILVER_GOLD,
T_FRT_ADULT2 are not used in any meta rule.
--
Speed is a metaphor for
are not used in any meta rule.
no T_* rules are in last 10_force_active.cf nor in 72_scores.cf so I
assume we're lacking an sa-update
On 11/21, Axb wrote:
Doesn't look like it. T_DKIM_INVALID, T_DOS_ZIP_HARDCORE,
T_FILL_THIS_FORM_SHORT, T_FORGED_TBIRD_IMG_SIZE, T_FRM_SILVER_GOLD,
T_FRT_ADULT2 are not used in any meta rule.
no T_* rules are in last 10_force_active.cf nor in 72_scores.cf so I
assume we're lacking an sa
72_active.cf is leaking lots of T_ rules
most if not all seem to come from /rulesrc/sandbox(felicity/70_other.cf
considering that T_ is supposed to be testing and shouldn't be published:
1- do we need to add a nopublish to these?
or
2- do we need to remove the confusing T_ in the rule name
On 2011-11-07 11:31, Axb wrote:
72_active.cf is leaking lots of T_ rules
most if not all seem to come from /rulesrc/sandbox(felicity/70_other.cf
considering that T_ is supposed to be testing and shouldn't be published:
1- do we need to add a nopublish to these?
or
2- do we need to remove
On Mon, 7 Nov 2011, Axb wrote:
Can't figure out why they they get published with a T_* in 72_active.cf when
the original rules don't have them.
Would someone pls clue me in?
A manually-named T_ rule is for testing.
The T_ added by masscheck-rescore means not performing well enough to
On 11/7/2011 8:44 AM, John Hardin wrote:
On Mon, 7 Nov 2011, Axb wrote:
Can't figure out why they they get published with a T_* in
72_active.cf when the original rules don't have them.
Would someone pls clue me in?
A manually-named T_ rule is for testing.
The T_ added by masscheck-rescore
On 2011-11-07 15:52, Kevin A. McGrail wrote:
On 11/7/2011 8:44 AM, John Hardin wrote:
On Mon, 7 Nov 2011, Axb wrote:
Can't figure out why they they get published with a T_* in
72_active.cf when the original rules don't have them.
Would someone pls clue me in?
A manually-named T_ rule is for
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6015
Kevin A. McGrail kmcgr...@pccc.com changed:
What|Removed |Added
Status|NEW |RESOLVED
After last SA update I'm still seeing a large bunch of T_ rules in
72_active.cf
Would sandbox owners please do the tag magic to prevent this? or make
them active if good enough.
We dont' really need stuff like:
meta T_SURBL_MULTI2 ((URIBL_JP_SURBL + URIBL_SC_SURBL + URIBL_AB_SURBL
published T_ prefix rules and 16 other rules that depend on
T_ rules.
The trunk is pretty much the same story, though with one fewer meta:
% svn info
Path: .
URL: https://svn.apache.org/repos/asf/spamassassin/trunk
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310
We have 211 published T_ prefix rules and 16 other rules that depend on
T_ rules.
Where T_ rules should be published or run is something in this bug
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6527
I think they are development only as you can see in my comment #2. I
support
I was assuming that rules named T_* would be in testing mode and would
not be plublished in daily snapshots.
After installing a snapshot I see stuff like
,T_RCVD_IN_SEMBLACK,T_SURBL_MULTI1,T_SURBL_MULTI2,T_URIBL_BLACK_OVERLAP,T_URIBL_SEM,T_URIBL_SEM_RED,
scoring.
Is this a bork?
Snapshots on
IIRC, T_* rules should *not* be published.
I see a bunch in 72_scores.cf which are pretty pointless as they all
have score of 0.0 and all they do is clutter up reports, use CPU and memory.
Is there a good reason to have these in sa-update or can we loose them?
If we can loose, how?
Thanks
I think those may be there due to being dependencies of real rules
-- but with scores of 0.0 that seems pointless. Investigation would
be useful
On Wed, Feb 16, 2011 at 14:06, Yet Another Ninja axb.li...@gmail.com wrote:
IIRC, T_* rules should *not* be published.
I see a bunch
make them vanish :-)
On Wed, Feb 16, 2011 at 14:06, Yet Another Ninjaaxb.li...@gmail.com wrote:
IIRC, T_* rules should *not* be published.
I see a bunch in 72_scores.cf which are pretty pointless as they all have
score of 0.0 and all they do is clutter up reports, use CPU and memory
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6015
Karsten Bräckelmann guent...@rudersport.de changed:
What|Removed |Added
Group|security|
On 06/03/2010 6:47 AM, Yet Another Ninja wrote:
I'm seeing T_* rules in SA 3.3's active list.
T_SURBL_MULTI1,T_SURBL_MULTI2,T_SURBL_MULTI3,T_URIBL_BLACK_OVERLAP, etc
shouldn't these be excluded from publishing?
The script just auto-promos anything that is a net test. I just found
out
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6015
Justin Mason j...@jmason.org changed:
What|Removed |Added
Group|security|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6015
Justin Mason j...@jmason.org changed:
What|Removed |Added
Priority|P1 |P2
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6015
Justin Mason j...@jmason.org changed:
What|Removed |Added
Priority|P5 |P1
--
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6015
Summary: 3.2.x updates contain replace_rules lines for T_ rules
Product: Spamassassin
Version: 3.2.5
Platform: Other
OS/Version: All
Status: NEW
Severity
24 matches
Mail list logo
