Hello, all, with so much volume on the list, I thought it would be
helpful to touch on a number of topics in one email.
Regards,
KAM
*> if you are running 3.X not trunk*
The rule renaming and scoring and description issues shoule be resolved
as soon as the automated system publishes the rules. You'll see
USER_IN_WHITELIST_TO with a description that it's deprecated and to see
USER_IN_WELCOMELIST_TO. However, your scoring and any meta rules built
on it will continue to work. We'll extrapolate this to other rules for
BLACKLIST and WHITELIST.
As we approach 4.0's release, we'll look at feedback for that version.
*> should i use sed or search and replace things?*
I would recommend against that right now. We have only changed ONE rule
so far on purpose. With 4.0's upgrade file, we will include guidance on
search and replaces as well as SQL queries for user preferences.
*> Re: Turning off and on backwards compatibility *
This idea isn't really needed. The issue we are working through is the
changes needed to support both current releases like 3.4.4 (soon to be
3.4.5), upcoming releases like 4.0.0 AND some people still using things
as old as 3.3.X.
We are working through with one function (whitelist_to) how best to do that.
The issue is not that we can't do it. We know how to code but rather
how to do new releases AND rulesets that are over a decade old. Even
3.4.2 has issues with sa-update that have been fixed since. People have
asked us to try and keep 3.4.2 working hence the recent work on rules.
*> Backwards compatibility is confusing for those not familiar with the
product.*
We have code such as the upcoming 4.0.0 SA release. We also have rules
which are a different release. We are working on backwards
compatibility for rules for existing releases as well as code changes
with 4.0.
*> what about whitelist_from_spf *@belastingdienst.nl*
That isn't a rule, that's a configuration option. Configuration options
for the new welcomelist_from_spf will include the alias to the previous
entry and will work at least until 4.1.0 is released.
*> Why is XYZ rule not fixed quicker?*
Rule changes take a long time, sometimes days, to go through a QA system
to publish them. We are looking at feedback from users of all different
versions and distros to try and select the best way forward. This is
why we have changed only one rule USER_IN_WELCOMELIST_TO and we are
working through that as a model for the rest of the changes.
*> Why not fix the rule renaming as part of ruleqa/masscheck?*
Rule QA / Masscheck is complicated. The less it's touched, the better.
*> Why is this breaking of rules not really a big deal?*
Unless there are other changes queued, not getting a rule update is ok.
Your existing rules will remain and the issue is benign but annoying.
*> Why make the change?*
I believe it's the right thing to do and you are going to see more of
the ecosystem changing to. I will not preempt the news but you are
going to see this change pretty broadly.
*> If you are Running 3.4.4*
sa-update should work and not error out. You should not receive any
warnings. There should be a meta rule for the new name in the next ruleset.
please let us know if you get any warnings from sa-update and
spamassassin --lint?
*> If you are running 3.4.2*
sa-update should work and not error out. You might get warnings. There
should be a meta rule for the new name in the next ruleset.
please let us know if you get any warnings from a ruleset AFTER 1880040
from sa-update and spamassassin --lint.
*> What about rules like URIBL_BLACK?*
That is a 3rd party rule. We will discuss with the URIBL team about
their plans but if renamed, we would mimic the meta rules with a
duplicated DEPRECATED rule such as we are doing for
USER_IN_WELCOMELIST_TO right now.
helpful to touch on a number of topics in one email.
Regards,
KAM
*> if you are running 3.X not trunk*
The rule renaming and scoring and description issues shoule be resolved
as soon as the automated system publishes the rules. You'll see
USER_IN_WHITELIST_TO with a description that it's deprecated and to see
USER_IN_WELCOMELIST_TO. However, your scoring and any meta rules built
on it will continue to work. We'll extrapolate this to other rules for
BLACKLIST and WHITELIST.
As we approach 4.0's release, we'll look at feedback for that version.
*> should i use sed or search and replace things?*
I would recommend against that right now. We have only changed ONE rule
so far on purpose. With 4.0's upgrade file, we will include guidance on
search and replaces as well as SQL queries for user preferences.
*> Re: Turning off and on backwards compatibility *
This idea isn't really needed. The issue we are working through is the
changes needed to support both current releases like 3.4.4 (soon to be
3.4.5), upcoming releases like 4.0.0 AND some people still using things
as old as 3.3.X.
We are working through with one function (whitelist_to) how best to do that.
The issue is not that we can't do it. We know how to code but rather
how to do new releases AND rulesets that are over a decade old. Even
3.4.2 has issues with sa-update that have been fixed since. People have
asked us to try and keep 3.4.2 working hence the recent work on rules.
*> Backwards compatibility is confusing for those not familiar with the
product.*
We have code such as the upcoming 4.0.0 SA release. We also have rules
which are a different release. We are working on backwards
compatibility for rules for existing releases as well as code changes
with 4.0.
*> what about whitelist_from_spf *@belastingdienst.nl*
That isn't a rule, that's a configuration option. Configuration options
for the new welcomelist_from_spf will include the alias to the previous
entry and will work at least until 4.1.0 is released.
*> Why is XYZ rule not fixed quicker?*
Rule changes take a long time, sometimes days, to go through a QA system
to publish them. We are looking at feedback from users of all different
versions and distros to try and select the best way forward. This is
why we have changed only one rule USER_IN_WELCOMELIST_TO and we are
working through that as a model for the rest of the changes.
*> Why not fix the rule renaming as part of ruleqa/masscheck?*
Rule QA / Masscheck is complicated. The less it's touched, the better.
*> Why is this breaking of rules not really a big deal?*
Unless there are other changes queued, not getting a rule update is ok.
Your existing rules will remain and the issue is benign but annoying.
*> Why make the change?*
I believe it's the right thing to do and you are going to see more of
the ecosystem changing to. I will not preempt the news but you are
going to see this change pretty broadly.
*> If you are Running 3.4.4*
sa-update should work and not error out. You should not receive any
warnings. There should be a meta rule for the new name in the next ruleset.
please let us know if you get any warnings from sa-update and
spamassassin --lint?
*> If you are running 3.4.2*
sa-update should work and not error out. You might get warnings. There
should be a meta rule for the new name in the next ruleset.
please let us know if you get any warnings from a ruleset AFTER 1880040
from sa-update and spamassassin --lint.
*> What about rules like URIBL_BLACK?*
That is a 3rd party rule. We will discuss with the URIBL team about
their plans but if renamed, we would mimic the meta rules with a
duplicated DEPRECATED rule such as we are doing for
USER_IN_WELCOMELIST_TO right now.