Re: Problems after upgrade to 3.1.4
On Thu, 27 Jul 2006, Daryl C. W. O'Shea wrote: Steven Stern wrote: These occur with spamassassin -D --lint. RDJ is up to date, as is sa-update. [6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency 'DCC_CHECK' ...etc It's just info. Some of your rules have undefined dependencies or are disabled via a zero score. That's fairly obvious from the warning message. I think both OPs point is that a 3.1.3 - 3.1.4 (i.e. minor version bugfix) upgrade shouldn't suddenly make a bunch of previously-working rules simply disappear... Does the upgrade do something like change the default local rules path, such that the dependency rules can no longer be found? Etc. -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The first time I saw a bagpipe, I thought the player was torturing an octopus. I was amazed they could scream so loudly. -- cat_herder_5263 on Y! SCOX ---
Re: Problems after upgrade to 3.1.4
John D. Hardin wrote: On Thu, 27 Jul 2006, Daryl C. W. O'Shea wrote: Steven Stern wrote: These occur with spamassassin -D --lint. RDJ is up to date, as is sa-update. [6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency 'DCC_CHECK' ...etc It's just info. Some of your rules have undefined dependencies or are disabled via a zero score. That's fairly obvious from the warning message. I thought so too, but a lot of people have asked. I think both OPs point is that a 3.1.3 - 3.1.4 (i.e. minor version bugfix) upgrade shouldn't suddenly make a bunch of previously-working rules simply disappear... Who said the rules previously worked. Who said they don't work now? Does the upgrade do something like change the default local rules path, such that the dependency rules can no longer be found? Etc. Like I said, it's *just* info. It's always been that way -- the rules have always had undefined or disabled dependencies. We just let you know now -- see bug 4347. Daryl
Re: Problems after upgrade to 3.1.4
On Thu, Jul 27, 2006 at 11:21:54AM -0700, John D. Hardin wrote: I think both OPs point is that a 3.1.3 - 3.1.4 (i.e. minor version bugfix) upgrade shouldn't suddenly make a bunch of previously-working rules simply disappear... This wouldn't make rules disappear. It's informational output, but not a lint error. You can follow the discussion in http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4347 if you want. :) Does the upgrade do something like change the default local rules path, such that the dependency rules can no longer be found? Etc. No, the rules would likely have had these issues for a while (I can't really comment on non-official rules), but with 3.1.4 there's now info output showing that there's a problem. (before, people would have had to manually figure out that meta dependencies have issues) -- Randomly Generated Tagline: The random quantum fluctuations of my brain are historical accidents that happen to have decided that the concepts of dynamic scoping and lexical scoping are orthogonal and should remain that way. - Larry Wall pgpefYDYI2xvo.pgp Description: PGP signature
Re: Problems after upgrade to 3.1.4
Hi! It's just info. Some of your rules have undefined dependencies or are disabled via a zero score. That's fairly obvious from the warning message. I think both OPs point is that a 3.1.3 - 3.1.4 (i.e. minor version bugfix) upgrade shouldn't suddenly make a bunch of previously-working rules simply disappear... Does the upgrade do something like change the default local rules path, such that the dependency rules can no longer be found? Etc. It warns you that some of your rules have missing elements. Go look at those rules and get it fixed at theirs sources ;) Bye, Raymond.
Re: Problems after upgrade to 3.1.4
On Thu, 27 Jul 2006, Theo Van Dinter wrote: Does the upgrade do something like change the default local rules path, such that the dependency rules can no longer be found? Etc. No, the rules would likely have had these issues for a while (I can't really comment on non-official rules), but with 3.1.4 there's now info output showing that there's a problem. Ah! Okay, I was making the assumption that the rules in question *were* all working before the upgrade. My mistake (and an easy one to make, too)... -- John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The first time I saw a bagpipe, I thought the player was torturing an octopus. I was amazed they could scream so loudly. -- cat_herder_5263 on Y! SCOX ---
RE: Problems after upgrade to 3.1.4
Does the upgrade do something like change the default local rules path, such that the dependency rules can no longer be found? Etc. No, the rules would likely have had these issues for a while (I can't really comment on non-official rules), but with 3.1.4 there's now info output showing that there's a problem. Ah! Okay, I was making the assumption that the rules in question *were* all working before the upgrade. My mistake (and an easy one to make, too)... I figure the SARE guys will be working on their rules to fix them soon... Bret
Re: Problems after upgrade to 3.1.4
Dear Groupmembers, I am trying to upgrade using perl butit still shows Mail::SpamAssassin isuptodate. Let me know whether the version 3.1.4 is released for perl installation. regards
Re: Problems after upgrade to 3.1.4
On Fri, Jul 28, 2006 at 12:52:42AM +0530, sokka wrote: I am trying to upgrade using perl butit still shows Mail::SpamAssassin isuptodate. Let me know whether the version 3.1.4 is released for perl installation. It's not quite clear what you're asking. I think you're asking if 3.1.4 is available via CPAN yet. The answer to that is yes, though it may not be out at all the mirrors yet. (http://cpan.org/modules/by-module/Mail/Mail-SpamAssassin-3.1.4.tar.gz) -- Randomly Generated Tagline: Living your life is a task so difficult, it has never been attempted before. pgpY5OnC8tjJz.pgp Description: PGP signature
Re: Problems after upgrade to 3.1.4
On Fri, 28 Jul 2006, sokka wrote: I am trying to upgrade using perl butit still shows Mail::SpamAssassin isuptodate. Let me know whether the version 3.1.4 is released for perl installation. If you're using a CPAN shell, you may need to give the command reload index for it to grab the latest index of what's available from CPAN and thereby see that 3.1.4 is available. Try this: perl -MCPAN -e shell cpan reload index # it should load latest stuff from CPAN cpan m /Mail::SpamAssassin/ # verify that CPAN has 3.1.4 - Logan
Re: Problems after upgrade to 3.1.4
From: Daryl C. W. O'Shea [EMAIL PROTECTED]
Steven Stern wrote:
These occur with spamassassin -D --lint. RDJ is up to date, as is
sa-update.
[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
'MIME_QP_LONG_LINE' with a zero score
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_XMAIL_SUSP2'
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_HEAD_XAUTH_WARN'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_MKSHRT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_GT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_TINY'
[6837] info: rules: meta test SARE_OBFU_CIALIS has undefined dependency
'SARE_OBFU_CIALIS2'
[6837] info: rules: meta test FP_MIXED_PORN3 has undefined dependency
'FP_PENETRATION'
It's just info. Some of your rules have undefined dependencies or are
disabled via a zero score.
If the rule is part of a meta a zero score on the rule should not
matter. It should still be evaluated because ultimately it has an
indirect score via the meta rule.
I like to see the sub-rules of a meta rule hitting for tracking. So
I always issue a 0.001 score or something like that which will not
affect results materially.
{^_^}
RE: Problems after upgrade to 3.1.4
These occur with spamassassin -D --lint. RDJ is up to date, as is sa-update. [6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency 'DCC_CHECK' [6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency 'MIME_QP_LONG_LINE' with a zero score [6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined dependency 'SARE_XMAIL_SUSP2' [6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined dependency 'SARE_HEAD_XAUTH_WARN' [6837] info: rules: meta test SARE_RD_SAFE has undefined dependency 'SARE_RD_SAFE_MKSHRT' [6837] info: rules: meta test SARE_RD_SAFE has undefined dependency 'SARE_RD_SAFE_GT' [6837] info: rules: meta test SARE_RD_SAFE has undefined dependency 'SARE_RD_SAFE_TINY' [6837] info: rules: meta test SARE_OBFU_CIALIS has undefined dependency 'SARE_OBFU_CIALIS2' [6837] info: rules: meta test FP_MIXED_PORN3 has undefined dependency 'FP_PENETRATION' It's just info. Some of your rules have undefined dependencies or are disabled via a zero score. If the rule is part of a meta a zero score on the rule should not matter. It should still be evaluated because ultimately it has an indirect score via the meta rule. I like to see the sub-rules of a meta rule hitting for tracking. So I always issue a 0.001 score or something like that which will not affect results materially. So what we're saying here is that if you create a META rule on a disabled (scored 0) rule, the META rule doesn't work? Didn't work before either? Or still works but generates an info debug message? Guess I should go dig out the rest of this converation and go read the bug discussion... Having to score every component of a META rule seems like a bad thing... My MTA integration only allows for 4K of headers to add and I'm already exceeding it fairly often. Adding more insignificant rules to the list will just make it that much worse... I guess it's time to write my own integration code... Ugh. Bret
Re: Problems after upgrade to 3.1.4
Bret Miller wrote: So what we're saying here is that if you create a META rule on a disabled (scored 0) rule, the META rule doesn't work? Disabled means disabled. Disabled rules are never run. Quoting the relevant score config info from M:SA:Conf POD: score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ] Setting a ruleâs score to 0 will disable that rule from running. Note that test names which begin with â__â are indirect rules used to compose meta-match rules and can also act as prerequisites to other rules. They are not scored or listed in the âtests hitâ reports, but assigning a score of 0 to an indirect rule will disable it from running. Didn't work before either? There has been *zero* functionality change. Or still works but generates an info debug message? Guess I should go dig out the rest of this converation and go read the bug discussion... Having to score every component of a META rule seems like a bad thing... My MTA integration only allows for 4K of headers to add and I'm already exceeding it fairly often. Adding more insignificant rules to the list will just make it that much worse... If you disable a rule it doesn't run. Period. When your eval is run it'll use a false result in place of a disabled rule. Thus is the rule is a required part of the meta (it's ANDed) then the meta will never fire. If it's an optional part of the meta (it's ORed) then the meta will fire if it goes on to evaluate true. Daryl
Re: Problems after upgrade to 3.1.4
On Thu, Jul 27, 2006 at 02:48:06PM -0700, Bret Miller wrote: So what we're saying here is that if you create a META rule on a disabled (scored 0) rule, the META rule doesn't work? Didn't work before either? It may have worked somewhat, but probably not as intended. It really depends on the meta rule. Or still works but generates an info debug message? Guess I should go dig out the rest of this converation and go read the bug discussion... Don't confuse the meta rule is executed with the meta rule works as expected. If the meta rule has a non-zero score, it's executed no matter what the dependencies are doing. However, the rule will like not work correctly if subrules are disabled. In 3.1.4, conditions where a meta rule's dependencies have an issue will cause an info message to be generated. Having to score every component of a META rule seems like a bad thing... You don't, but if a subrule/dependency is disabled, then ... well, it's disabled. My MTA integration only allows for 4K of headers to add and I'm already exceeding it fairly often. Adding more insignificant rules to the list will just make it that much worse... I'm not sure what this has to do with anything. -- Randomly Generated Tagline: In case you're wondering why I mentioned 'My Fair Lady' and then sung part of a song from 'West Side Story' ... it's because I'm stupid. - Pat Sajak pgpMewFZ6o925.pgp Description: PGP signature
Re: Problems after upgrade to 3.1.4
From: Daryl C. W. O'Shea [EMAIL PROTECTED]
Bret Miller wrote:
So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work?
Disabled means disabled. Disabled rules are never run.
Quoting the relevant score config info from M:SA:Conf POD:
score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]
Setting a ruleâs score to 0 will disable that rule from running.
Note that test names which begin with â__â are indirect rules used to compose
meta-match rules and can also act as prerequisites to
other rules. They are not scored or listed in the âtests hitâ reports, but
assigning a score of 0 to an indirect rule will disable
it from running.
Didn't work before either?
There has been *zero* functionality change.
Or still works but generates an info debug message? Guess I
should go dig out the rest of this converation and go read the bug
discussion...
Having to score every component of a META rule seems like a bad thing...
My MTA integration only allows for 4K of headers to add and I'm already
exceeding it fairly often. Adding more insignificant rules to the list
will just make it that much worse...
If you disable a rule it doesn't run. Period. When your eval is run it'll use a false
result in place of a disabled rule. Thus is the rule is a required part of the meta
(it's ANDed) then the meta will never fire. If it's an optional part of the meta (it's
ORed) then the meta will fire if it goes on to evaluate true.
That is a bad thing. And it also seems to be different from the original
version of SA I started with which supported META. (I started back with
2.20 something.) The wording back then suggested you could write a META
rule with components scored zero so that they would not report but the
META would still work. That behavior is depended upon for some of the
SARE rule sets, it appears.
Could it be possible to enhance SpamAssassin with an artificial score,
META. Internally that would be interpreted as something like 0.0001
so that the rule would fire. Then make a second change so that any rule
with a score equal to or under META, 0.0001, does not print out in the
reports individually?
If so I can (grit my teeth and) file a bugzilla request for the change.
This should be a minimal change that would create the desired and user
expected behavior.
{^_^}
Re: Problems after upgrade to 3.1.4
From: Theo Van Dinter [EMAIL PROTECTED]
Don't confuse the meta rule is executed with the meta rule works
as expected.
Sorry, the bad conclusion was already made and depended upon for
proper operation without cluttering the header streams or the report
fields. So the question becomes, What is the smallest change that
can be made to SpamAssassin to effect this expected behavior? I
believe the proposal I just made in the message I sent to the group
just before this one should meet that criterion. Even the documentation
change to clarify the issue will be mininal.
My MTA integration only allows for 4K of headers to add and I'm already
exceeding it fairly often. Adding more insignificant rules to the list
will just make it that much worse...
I'm not sure what this has to do with anything.
If the scores are printed out in header fields the scores field can very
quickly exceed the 4k size limit. This is not a good thing.
{^_^}
Re: Problems after upgrade to 3.1.4
jdow wrote: The wording back then suggested you could write a META rule with components scored zero so that they would not report but the META would still work. If I read the runes a-right, that's still how META rules work. Create a rule like this: body __CONDITION_1 /something/ ...and don't assign it a score at all. It'll execute, the META rules which rely on it will process the result, no problem. HOWEVER, if you assign that rule a score of 0, as in: score __CONDITION_1 0 ...then the rule will be disabled, will not be processed, and any meta rule that relies on it will (a) throw this warning and (b) assume a value of false for that condition. -- Kelson Vibber SpeedGate Communications www.speed.net
Re: Problems after upgrade to 3.1.4
On Thu, Jul 27, 2006 at 03:53:08PM -0700, jdow wrote: If the scores are printed out in header fields the scores field can very quickly exceed the 4k size limit. This is not a good thing. Meta subrules (those that start with __) aren't displayed as part of the standard rules hits. -- Randomly Generated Tagline: Fry: What's with the eye? pgpmV44ptkVgK.pgp Description: PGP signature
Re: Problems after upgrade to 3.1.4
On Thu, Jul 27, 2006 at 03:48:29PM -0700, jdow wrote: If you disable a rule it doesn't run. Period. When your eval is run it'll use a false result in place of a disabled rule. Thus is the rule is a required part of the meta (it's ANDed) then the meta will never fire. If it's an optional part of the meta (it's ORed) then the meta will fire if it goes on to evaluate true. That is a bad thing. And it also seems to be different from the original Not really. version of SA I started with which supported META. (I started back with 2.20 something.) The wording back then suggested you could write a META rule with components scored zero so that they would not report but the META would still work. That behavior is depended upon for some of the SARE rule sets, it appears. meta rules came out in 2.40, and those docs clearly state: If you want to define a meta-rule, but do not want its individual sub-rules to count towards the final score unless the entire meta-rule matches, give the sub-rules names that start with '__' (two underscores). SpamAssassin will ignore these for scoring. That hasn't changed. I'm not sure why everyone is going crazy about this. Absolutely nothing has changed wrt how meta rules work. The only change is that now it's easier to find out when there are problems with the meta rules. -- Randomly Generated Tagline: Eighty percent of married men cheat in America. The rest cheat in Europe. - Jackie Mason pgpFJpbQgCpaO.pgp Description: PGP signature
Re: Problems after upgrade to 3.1.4
On Thu, Jul 27, 2006 at 06:20:57PM -0700, jdow wrote: Even that is not clear. The way I interpret that NOW is that the __METARULE needs a score of some sort or it will not ever contribute to a META rule except via a default score that is independent of the Yes, a subrule (__) needs a score to run, and therefore contribute to the meta rule. Like every other rule, subrules have a default score of 1. PLUS the META rules in which it is used provide scores to the final results. Nope. It's really simple: For a rule to be executed, it needs a non-zero score. Subrules (those starting with __) *never* add to the message score. If you set a subrule's score to 0, it won't be executed. This, by the way, is in the documentation: Setting a rule’s score to 0 will disable that rule from running. If no score is given for a test by the end of the configuration, a default score is assigned: a score of 1.0 is used for all tests, except those who names begin with ’T_’ (this is used to indicate a rule in testing) which receive 0.01. Note that test names which begin with ’__’ are indirect rules used to compose meta-match rules and can also act as prerequisites to other rules. They are not scored or listed in the ’tests hit’ reports, but assigning a score of 0 to an indirect rule will disable it from running. Is that right? I had read that to indicate that __METARULE would only contribute a value to the META rules that use it and not ever to the final result. Or does __METARULE need to have a score line with a non-zero value to run? Yes, basically. However, all rules (ignoring test rules (starts with T_)) get a score of 1 by default, so you don't need to specifically set a score for __METARULE. In the end, as long as __METARULE doesn't have a score of zero, it runs. -- Randomly Generated Tagline: 'Don't NOT follow the directions' seems unnecessary to state. - Roger B.A. Klorese pgpsxHl2juAXo.pgp Description: PGP signature
Re: Problems after upgrade to 3.1.4
From: Theo Van Dinter [EMAIL PROTECTED]
Yes, basically. However, all rules (ignoring test rules (starts with T_)) get a
score of 1 by default, so you don't need to specifically set a score for
__METARULE. In the end, as long as __METARULE doesn't have a score of zero,
it runs.
So far that clarifies things well enough the SARE folks should have a
clear idea what to edit.
And for testing it could be _METARULE and once testing is complete
the lead _ could make it into __METARULE.
One more thing - will __METARULE appear in the hit various hit reports
such as the maillog and the header or wrapper score reports? The header
version of the score reports is where it can cause potential problems
with header size exceeding some systems' limits. It might also cause a
problem with maillog entries. I don't know if there is a maximum size
for a maillog line or not. For the wrapper report it probably doesn't
much matter whether it shows or not, showing might be marginally
better.
{^_^}
