IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5
All:

As of today, the configuration option WHITELIST_TO has been renamed
WELCOMELIST_TO with an alias for backwards compatibility. 

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
USER_IN_WELCOMELIST_TO to assist those running older versions of
SpamAssassin get stock rulesets.

If you have custom scoring or any custom rules building on
USER_IN_WHITELIST_TO, please accept our apologies and change the
references to USER_IN_WELCOMELIST_TO.

In order to remove racially charged configuration options, whitelist
will become welcomelist and blacklist will become blocklist.  More
changes will be coming for this with these small changes in the stock
ruleset.
Apologies for the disruption and thanks to those who are reporting
issues as we work through the changes.

Regards,
KAM

--

Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5

> are you guys crazy doing that to *existing* stable installs and what
> does that mean for setups with "warn: rules: error: unknown eval
> 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO"

I've heard back from testers using 3.3.1 to 3.4.2 that the issue is
resolved re: the eval or unknown rule for descriptions.

The issue this morning is dealing with local rescoring or local rules
that use rules that are being renamed in stock ruleset.  Do you have any
local rescoring or local rules built on *WHITELIST* or *BLACKLIST*?  If
not, the issue should be minor. 

Regards,

KAM


--

Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5

> i got the warning at the daily 12:30 AM lint today as well and as said
> that started long *after that* thread

If you are running ruleset 1880040 and you are running spamassassin
--lint and getting an error, please post the error and the version of SA
you are using.


> frankly where i start to puke is "WHITELIST_TO" and
> "USER_IN_WHITELIST_TO" are renamed, it obviously affects users running
> *stable releases* and you guys are not capable to rename every
> appareance of BLACKLIST and WHITELIST at the same time

It's a balance of trying to support some of the older installs and the
new changes.  We'll dial it in and appreciate the feedback on getting
the changes to work.  Really immune to any complaints about the overall
changes though. They are coming and complaining about it is a waste of
your time.


> meta          CUST_SHORTCIRCUIT1  (ALL_TRUSTED || USER_IN_ALL_SPAM_TO ||
> USER_IN_WHITELIST || USER_IN_SPF_WHITELIST || USER_IN_DKIM_WHITELIST)
> score USER_IN_DKIM_WHITELIST -100.0
> score USER_IN_SPF_WHITELIST -100.0

On your local version, if you add a score USER_IN_DKIM_WELCOMLIST -100.0
which does not exist yet, you should get just a warning.  If so,
changing that one meta and those two scores preemptively will prepare
you for the change. 

e.g. meta CUST_SHORTCIRCUIT1 (ALL_TRUSTED || USER_IN_ALL_SPAM_TO ||
USER_IN_WELCOMELIST || USER_IN_WHITELIST || ...

I think you said you were on fedora 3.4.4, so please let me know.

Regards,

KAM


--
Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5
In reply to this post by Kevin A. McGrail-5
We only publish one set of rules so you will see that become welcome instead of white.  If you are using a modern day 3.4.3 or greater, you can likely prepare for the changes now by adding both to meta rules.  Can you show an example of your dependency?

On Sun, Jul 19, 2020, 13:06 Thom van der Boon <[hidden email]> wrote:
Dear Kevin,

Could you please clearify what versions are affected in these changes?

My own rules rely heavily on whitelist_from_spf

Met vriendelijke groet, Best regards,


Thom van der Boon
E-Mail: [hidden email]



Van: "Kevin A. McGrail" <[hidden email]>
Aan: "SA Mailing list" <[hidden email]>, "SpamAssassin Devel List" <[hidden email]>
Verzonden: Zondag 19 juli 2020 18:09:36
Onderwerp: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

All:

As of today, the configuration option WHITELIST_TO has been renamed
WELCOMELIST_TO with an alias for backwards compatibility. 

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
USER_IN_WELCOMELIST_TO to assist those running older versions of
SpamAssassin get stock rulesets.

If you have custom scoring or any custom rules building on
USER_IN_WHITELIST_TO, please accept our apologies and change the
references to USER_IN_WELCOMELIST_TO.

In order to remove racially charged configuration options, whitelist
will become welcomelist and blacklist will become blocklist.  More
changes will be coming for this with these small changes in the stock
ruleset.
Apologies for the disruption and thanks to those who are reporting
issues as we work through the changes.

Regards,
KAM

--

Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

John Hardin
In reply to this post by Kevin A. McGrail-5
On Sun, 19 Jul 2020, Kevin A. McGrail wrote:

> Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
> USER_IN_WELCOMELIST_TO to assist those running older versions of
> SpamAssassin get stock rulesets.
>
> If you have custom scoring or any custom rules building on
> USER_IN_WHITELIST_TO, please accept our apologies and change the
> references to USER_IN_WELCOMELIST_TO.

The non-can_welcome_block branch should not be renaming the rule. Doing
that breaks existing production installs.

The rule name changes should not be exposed until the 4.0 release when the
internal code changes hit mainstream (i.e. the can_welcome_block branch
starts being used) and the needed rule name changes in local
customizations can be covered in the UPGRADE document.


--
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  [hidden email]    FALaholic #11174     pgpk -a [hidden email]
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Back in 1969 the technology to fake a Moon landing didn't exist,
   but the technology to actually land there did.
   Today, it is the opposite.                               -- unknown
-----------------------------------------------------------------------
  Tomorrow: the 51st anniversary of Apollo 11 landing on the Moon
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5
On 7/19/2020 7:39 PM, John Hardin wrote:
>
> The non-can_welcome_block branch should not be renaming the rule.
> Doing that breaks existing production installs.

I agree is causing unexpected local rules and local rule scoring issues
trying to get pre-3.4.3 releases to work.

What do you think of this change along with removing the score from
50_scores.cf?  I think it will work back to 3.3.x:

if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)
  #bz7826 renames whitelist to welcomelist
  header USER_IN_WELCOMELIST_TO         eval:check_to_in_welcomelist()
  describe USER_IN_WELCOMELIST_TO       User is listed in 'welcomelist_to'
  tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
  score USER_IN_WELCOMELIST_TO          -6.0
else
  header USER_IN_WELCOMELIST_TO         eval:check_to_in_whitelist()
  describe USER_IN_WELCOMELIST_TO       User is listed in 'welcomelist_to'
  tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
  score USER_IN_WELCOMELIST_TO          -0.01

  meta USER_IN_WHITELIST_TO             (USER_IN_WELCOMELIST_TO)
  describe USER_IN_WHITELIST_TO         DEPRECATED: See
USER_IN_WELCOMELIST_TO
  tflags USER_IN_WHITELIST_TO           userconf nice noautolearn
  score USER_IN_WHITELIST_TO            -6.0
endif

Regards,

KAM

--
Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

John Hardin
On Sun, 19 Jul 2020, Kevin A. McGrail wrote:

> On 7/19/2020 7:39 PM, John Hardin wrote:
>>
>> The non-can_welcome_block branch should not be renaming the rule.
>> Doing that breaks existing production installs.
>
> I agree is causing unexpected local rules and local rule scoring issues
> trying to get pre-3.4.3 releases to work.
>
> What do you think of this change along with removing the score from
> 50_scores.cf?  I think it will work back to 3.3.x:
>
> if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)
>   #bz7826 renames whitelist to welcomelist
>   header USER_IN_WELCOMELIST_TO         eval:check_to_in_welcomelist()
>   describe USER_IN_WELCOMELIST_TO       User is listed in 'welcomelist_to'
>   tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
>   score USER_IN_WELCOMELIST_TO          -6.0
> else
>   header USER_IN_WELCOMELIST_TO         eval:check_to_in_whitelist()
>   describe USER_IN_WELCOMELIST_TO       User is listed in 'welcomelist_to'
>   tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
>   score USER_IN_WELCOMELIST_TO          -0.01
>
>   meta USER_IN_WHITELIST_TO             (USER_IN_WELCOMELIST_TO)
>   describe USER_IN_WHITELIST_TO         DEPRECATED: See USER_IN_WELCOMELIST_TO
>   tflags USER_IN_WHITELIST_TO           userconf nice noautolearn
>   score USER_IN_WHITELIST_TO            -6.0
> endif

That seems a better approach to me. +1


I was mulling the utility of a new config directive in 4.0 to address
backwards compatibility of rule names:

    alias  RULENAME  RULENAME_2

...which would recognize any config-file directives for RULENAME and apply
them as if they'd been written for RULENAME_2.

This would discard any existing definition of RULENAME_2 (e.g. header
RULENAME_2 ...), and a definition of RULENAME_2 subsequent to that alias
would be ignored and a lint warning emitted.

That would allow the 4.0 release to be backwards-compatible thusly:

if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)
  #bz7826 renames whitelist to welcomelist
  header USER_IN_WELCOMELIST_TO         eval:check_to_in_welcomelist()
  describe USER_IN_WELCOMELIST_TO       User is listed in 'welcomelist_to'
  tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
  score USER_IN_WELCOMELIST_TO          -6.0
   alias USER_IN_WHITELIST_TO            USER_IN_WELCOMELIST_TO
else
  header USER_IN_WELCOMELIST_TO         eval:check_to_in_whitelist()
  describe USER_IN_WELCOMELIST_TO       User is listed in 'welcomelist_to'
  tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
  score USER_IN_WELCOMELIST_TO          -0.01

  meta USER_IN_WHITELIST_TO             (USER_IN_WELCOMELIST_TO)
  describe USER_IN_WHITELIST_TO         DEPRECATED: See USER_IN_WELCOMELIST_TO
  tflags USER_IN_WHITELIST_TO           userconf nice noautolearn
  score USER_IN_WHITELIST_TO            -6.0
endif

There is the use case of post-SA message processing looking for specific
rule name hits - I can see custom post-SA message processing looking for a
hit on "USER_IN_WHITELIST_TO" et al. To avoid breaking that we could add a
"report" option to the alias command:

   alias  RULENAME  RULENAME_2 report

...which would include RULENAME in the rules hit list if RULENAME_2 hits.
However, that would expose RULENAME to user visibility and if the goal
here is to shield sensitive users from seeing "WHITELIST" or "BLACKLIST"
then we have conflicting goals. The report option probably shouldn't be in
the base rules as a default, unless we get information that such a utility
is in wide use.

The alias would be removed from the rule definition when the backwards
compatibility period expires in 4.1+, and we could document in 4.0 UPGRADE
that *IF* a given local post-SA processing utility is looking for these
rule names in the rules hit list then either that utility needs to be
modified to look for the new rule names or the following needs to be put
into the local SA config:

   alias USER_IN_WHITELIST_TO USER_IN_WELCOMELIST_TO report

...(etc.) to set the "report" option on the alias to feed the external
utility until it gets modified to recognize the new rule names.

--
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  [hidden email]    FALaholic #11174     pgpk -a [hidden email]
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   What the hell is an "Aluminum Falcon"??        -- Emperor Palpatine
-----------------------------------------------------------------------
  Tomorrow: the 51st anniversary of Apollo 11 landing on the Moon
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5

On 7/19/2020 9:29 PM, John Hardin wrote:

>
>>
>> What do you think of this change along with removing the score from
>> 50_scores.cf?  I think it will work back to 3.3.x:
>>
>> if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)
>>   #bz7826 renames whitelist to welcomelist
>>   header USER_IN_WELCOMELIST_TO         eval:check_to_in_welcomelist()
>>   describe USER_IN_WELCOMELIST_TO       User is listed in
>> 'welcomelist_to'
>>   tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
>>   score USER_IN_WELCOMELIST_TO          -6.0
>> else
>>   header USER_IN_WELCOMELIST_TO         eval:check_to_in_whitelist()
>>   describe USER_IN_WELCOMELIST_TO       User is listed in
>> 'welcomelist_to'
>>   tflags USER_IN_WELCOMELIST_TO         userconf nice noautolearn
>>   score USER_IN_WELCOMELIST_TO          -0.01
>>
>>   meta USER_IN_WHITELIST_TO             (USER_IN_WELCOMELIST_TO)
>>   describe USER_IN_WHITELIST_TO         DEPRECATED: See
>> USER_IN_WELCOMELIST_TO
>>   tflags USER_IN_WHITELIST_TO           userconf nice noautolearn
>>   score USER_IN_WHITELIST_TO            -6.0
>> endif
>
>
> That seems a better approach to me. +1

svn commit -m 'More Tweaking to USER_IN_WELCOMELIST_TO' 60_whitelist.cf
50_scores.cf
Sending        50_scores.cf
Sending        60_whitelist.cf
Transmitting file data ..
Committed revision 1880056.

>
> I was mulling the utility of a new config directive in 4.0 to address
> backwards compatibility of rule names:
>    alias  RULENAME  RULENAME_2
>
> ...which would recognize any config-file directives for RULENAME and
> apply them as if they'd been written for RULENAME_2.
>
> This would discard any existing definition of RULENAME_2 (e.g. header
> RULENAME_2 ...), and a definition of RULENAME_2 subsequent to that
> alias would be ignored and a lint warning emitted.

That would work well, yes.  How big a lift for that alias idea do you
think? 


> There is the use case of post-SA message processing looking for
> specific rule name hits - I can see custom post-SA message processing
> looking for a hit on "USER_IN_WHITELIST_TO" et al. To avoid breaking
> that we could add a "report" option to the alias command:
>
>   alias  RULENAME  RULENAME_2 report
this seems over complicated.  Do you know of anyone doing this use case
that wouldn't just add a meta rule and be done?

--
Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

John Hardin
On Sun, 19 Jul 2020, Kevin A. McGrail wrote:

> On 7/19/2020 9:29 PM, John Hardin wrote:
>
>> I was mulling the utility of a new config directive in 4.0 to address
>> backwards compatibility of rule names:
>>    alias  RULENAME  RULENAME_2
>>
>> ...which would recognize any config-file directives for RULENAME and
>> apply them as if they'd been written for RULENAME_2.
>>
>> This would discard any existing definition of RULENAME_2 (e.g. header
>> RULENAME_2 ...), and a definition of RULENAME_2 subsequent to that
>> alias would be ignored and a lint warning emitted.
>
> That would work well, yes.  How big a lift for that alias idea do you
> think? 
Unknown at this time. I don't *think* it would be too complicated. It
shouldn't affect the bulk of SA, just the config file parsing.

>> There is the use case of post-SA message processing looking for
>> specific rule name hits - I can see custom post-SA message processing
>> looking for a hit on "USER_IN_WHITELIST_TO" et al. To avoid breaking
>> that we could add a "report" option to the alias command:
>>
>>   alias  RULENAME  RULENAME_2 report
>
> this seems over complicated.  Do you know of anyone doing this use case
> that wouldn't just add a meta rule and be done?

Problem is, that's a rule definition and it wouldn't peacefully coexist
with the "alias" directive as I have it envisioned. Perhaps we allow "meta
RULENAME" to remove "alias RULENAME" while retaining the lint warning for
other rule types.


--
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  [hidden email]    FALaholic #11174     pgpk -a [hidden email]
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Back in 1969 the technology to fake a Moon landing didn't exist,
   but the technology to actually land there did.
   Today, it is the opposite.                               -- unknown
-----------------------------------------------------------------------
  Tomorrow: the 51st anniversary of Apollo 11 landing on the Moon
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5
On 7/19/2020 10:03 PM, John Hardin wrote:
> Problem is, that's a rule definition and it wouldn't peacefully
> coexist with the "alias" directive as I have it envisioned. Perhaps we
> allow "meta RULENAME" to remove "alias RULENAME" while retaining the
> lint warning for other rule types.
Ahh yes, good point.  Do we know of anyone with this parsing report
template type of use case? 

--
Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Luis E. Muñoz
On 19 Jul 2020, at 19:17, Kevin A. McGrail wrote:

> Ahh yes, good point.  Do we know of anyone with this parsing report
> template type of use case? 

I know of at least two use cases where the report template is parsed
post-sa. I don't know if the specific rules in contention are involved
in said use cases, but this type of feature seems useful.

Best regards

-lem
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Kevin A. McGrail-5
OK, can you ask for specifics on their use case because if the post-sa
work is not involving these rules or trivial to update, it might be best
to follow KISS.


On 7/19/2020 10:39 PM, Luis E. Muñoz wrote:

> On 19 Jul 2020, at 19:17, Kevin A. McGrail wrote:
>
>> Ahh yes, good point.  Do we know of anyone with this parsing report
>> template type of use case? 
>
> I know of at least two use cases where the report template is parsed
> post-sa. I don't know if the specific rules in contention are involved
> in said use cases, but this type of feature seems useful.
>
> Best regards
>
> -lem

--
Kevin A. McGrail
[hidden email]

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Luis E. Muñoz
On 19 Jul 2020, at 19:41, Kevin A. McGrail wrote:

> OK, can you ask for specifics on their use case because if the post-sa
> work is not involving these rules or trivial to update, it might be best
> to follow KISS.

I sent email after replying. Will update on list if/when I hear back.

Best regards

-lem
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

Reindl Harald
In reply to this post by Kevin A. McGrail-5


Am 19.07.20 um 18:58 schrieb Reindl Harald:

> Am 19.07.20 um 18:47 schrieb Kevin A. McGrail:
>>
>>> i got the warning at the daily 12:30 AM lint today as well and as said
>>> that started long *after that* thread
>>
>> If you are running ruleset 1880040 and you are running spamassassin
>> --lint and getting an error, please post the error and the version of SA
>> you are using.
>
> only god knows why i have 1879934 instead 1880040 and you first should
> get your homework done which means a proper QA and a way at least push
> fixes caused by non-working QA in a timely manner

wow - today 1880040 arrived - it was a long way

Jul 20 12:30:03.365 [188803] warn: rules: error: unknown eval
'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO

20-Jul-2020 11:06:00: SpamAssassin: Update processed successfully

[root@mail-gw:/var/lib/spamassassin/3.004004]$ head
updates_spamassassin_org.cf
# UPDATE version 1880040

-------------------

yeah, instances which are intended *only* for bayes and have anything
else disabled to just check if the corpus still get properly scored bail out

and that's why you guys have no cue what useless changes may trigger in
the reality of all the setups out there, most not subscirbed to any
maling-list

meta USER_IN_WELCOMELIST_TO 0

-------------------

[root@mail-gw:~]$ su -c "/usr/bin/spamassassin
--siteconfigpath=/etc/mail/spamassassin-debug --lint" - sa-milt
Jul 20 12:33:50.391 [189250] warn: rules: error: unknown eval
'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO

[root@mail-gw:~]$ su -c "/usr/bin/spamassassin
--siteconfigpath=/etc/mail/spamassassin-debug --lint" - sa-milt
Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

matthias
In reply to this post by Kevin A. McGrail-5
Hello,

On Sun, 19 Jul 2020, Kevin A. McGrail wrote:

>
> > i got the warning at the daily 12:30 AM lint today as well and as said
> > that started long *after that* thread
>
> If you are running ruleset 1880040 and you are running spamassassin
> --lint and getting an error, please post the error and the version of SA
> you are using.

I still get the following warning/error message:

Jul 20 16:48:07.671 [5757] warn: rules: error: unknown eval 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO

the ruleset is 1880040 and I am using Spamassassin version 3.4.2 (latest
version in Debian Jessie). The custom rules don't contain any whitelist
rules. Is it supposed to work with this version without warning or error
messages?

Best regards,
Matthias

Reply | Threaded
Open this post in threaded view
|

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

John Hardin
In reply to this post by Kevin A. McGrail-5
On Sun, 19 Jul 2020, Kevin A. McGrail wrote:

> Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
> USER_IN_WELCOMELIST_TO to assist those running older versions of
> SpamAssassin get stock rulesets.
>
> If you have custom scoring or any custom rules building on
> USER_IN_WHITELIST_TO, please accept our apologies and change the
> references to USER_IN_WELCOMELIST_TO.

These are the rulenames from the base rules that are (potentially) subject
to renaming:

      HEADER_HOST_IN_BLACKLIST
      HEADER_HOST_IN_WHITELIST
      RCVD_IN_SEMBLACK
      SUBJECT_IN_BLACKLIST
      SUBJECT_IN_WHITELIST
      URI_HOST_IN_BLACKLIST
      URI_HOST_IN_WHITELIST
      URIBL_BLACK
      USER_IN_BLACKLIST
      USER_IN_BLACKLIST_TO
      USER_IN_DEF_WHITELIST
      USER_IN_DKIM_WHITELIST
      USER_IN_SPF_WHITELIST
      USER_IN_WHITELIST
      USER_IN_WHITELIST_TO

(Some of these rules are historical and are currently disabled; they are
included for completeness.)

It would be helpful if we could be informed whether anyone has post-SA
processing that looks for these rulenames in the SA hit results, e.g. for
making message delivery decisions.

Thank you.

--
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  [hidden email]    FALaholic #11174     pgpk -a [hidden email]
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Back in 1969 the technology to fake a Moon landing didn't exist,
   but the technology to actually land there did.
   Today, it is the opposite.                               -- unknown
-----------------------------------------------------------------------
  Today: the 51st anniversary of Apollo 11 landing on the Moon