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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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/
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
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
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
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
20 matches
Mail list logo
