Mailing List Archive

> 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
KMcGrail@Apache.org

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

> 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
KMcGrail@Apache.org

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

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: thom@vdb.nl



Van: "Kevin A. McGrail" <kmcgrail@apache.org>
Aan: "SA Mailing list" <users@spamassassin.apache.org>, "SpamAssassin Devel List" <dev@spamassassin.apache.org>
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
KMcGrail@Apache.org

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

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 <thom@vdb.nl> 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: thom@vdb.nl
>
>
> ------------------------------
> *Van: *"Kevin A. McGrail" <kmcgrail@apache.org>
> *Aan: *"SA Mailing list" <users@spamassassin.apache.org>, "SpamAssassin
> Devel List" <dev@spamassassin.apache.org>
> *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
> KMcGrail@Apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>

On Sunday 19 July 2020 at 19:56:34, Kevin A. McGrail wrote:

> We only publish one set of rules so you will see that become welcome
> instead of white.

My feeling on this is that such a breaking change requires a fairly lengthy
backward-compatible transition period (with appropriate warning messages for
those still using the old terminology, but not such that it no longer works),
rather than just switching over suddenly from "old" to "new" with no "dual
use" interim period.

In other words, support both "black" and "block", and "white" and "welcome",
for at least 3 months, I suggest.


Antony.

--
What do you call a dinosaur with only one eye? A Doyouthinkesaurus.

Please reply to the list;
please *don't* CC me.

> In other words, support both "black" and "block", and "white" and
> "welcome",
> for at least 3 months, I suggest.

The bug report that introduced this change claimed 100% backward
compatability for at least one year, later changed to until 4.0 came out,
whenever that will be.

Of course it doesn't actually work that way, as you have observed. But that
is just your problem, not SA's, as you can determine from this thread.


Loren

On Sun, 19 Jul 2020, Loren Wilton wrote:

>> In other words, support both "black" and "block", and "white" and
>> "welcome", for at least 3 months, I suggest.
>
> The bug report that introduced this change claimed 100% backward
> compatability for at least one year, later changed to until 4.0 came out,
> whenever that will be.

You're misreading that. Backwards compatibility in the code will be
maintained for at least one year after the 4.0 release, when the code
changes take effect, and would not be removed until 4.1 is released if
it has not been released by that point (which is unlikely - 4.0 and 4.1
released within one year?). So if 4.1 was released within a year of 4.0,
it would include backwards compatibility and that would remain until at
least 4.2

Unfortunately some rule name changes are making it out ahead of the 4.0
release. We're working on addressing this, it should be a temporary
condition.


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
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

"Kevin A. McGrail" <kmcgrail@apache.org> writes:

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

Kevin,

Please consider adding an easy way to turn the backward compatibility on
and off.

So we, person in charge of mail systems, can find all the obscure places
where the renaming will break something; because I am strongly beleiving
that issues will arise from the less unsuspected places.

The compatibility enable option will allow us to run without
compatibility, notice where the thing break and enable the compatibility
while solving the issues. That will be the less damaging way for our
users.

Best regards,

Olivier


> 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

--

On 20/07/2020 13:23, Olivier wrote:

> "Kevin A. McGrail" <kmcgrail@apache.org> writes:
>
>> All:
>>
>> As of today, the configuration option WHITELIST_TO has been renamed
>> WELCOMELIST_TO with an alias for backwards compatibility.
>
> Kevin,
>
> Please consider adding an easy way to turn the backward compatibility on
> and off.
>
> So we, person in charge of mail systems, can find all the obscure places
> where the renaming will break something; because I am strongly beleiving
> that issues will arise from the less unsuspected places.
>
> The compatibility enable option will allow us to run without
> compatibility, notice where the thing break and enable the compatibility
> while solving the issues. That will be the less damaging way for our
> users.

Just think of those 10's thousands of running spamassassin who are not
on these lists, all in for a shock when custom scripts start breaking.

--
Regards,
Noel Butler

This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so. If
you are not the intended recipient, please notify the sender then delete
all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.

>> The bug report that introduced this change claimed 100% backward
>> compatability for at least one year, later changed to until 4.0 came out,
>> whenever that will be.
>
> You're misreading that. Backwards compatibility in the code will be
> maintained for at least one year after the 4.0 release,

Sorry about misreading that.

It's a shame that there is no requirement for backward compatability BEFORE
the 4.0 release. Whenever that comes out.

Loren

Noel Butler skrev den 2020-07-20 05:35:

> Just think of those 10's thousands of running spamassassin who are not
> on these lists, all in for a shock when custom scripts start breaking.

lets hope rspamd being marked stable on gentoo before this shock happend
:=)

On 20200719 18:02:18, John Hardin wrote:
> On Sun, 19 Jul 2020, Loren Wilton wrote:
>
>>> In other words, support both "black" and "block", and "white" and "welcome",
>>> for at least 3 months, I suggest.
>>
>> The bug report that introduced this change claimed 100% backward compatability
>> for at least one year, later changed to until 4.0 came out, whenever that will
>> be.
>
> You're misreading that. Backwards compatibility in the code will be maintained
> for at least one year after the 4.0 release, when the code changes take effect,
> and would not be removed until 4.1 is released if it has not been released by
> that point (which is unlikely - 4.0 and 4.1 released within one year?). So if
> 4.1 was released within a year of 4.0, it would include backwards compatibility
> and that would remain until at least 4.2
>
> Unfortunately some rule name changes are making it out ahead of the 4.0 release.
> We're working on addressing this, it should be a temporary condition.

Am I granted an "I told you so?" The results coming out of this betray a
breathtaking level of arrogance and overt racism.

{o.o}

On 19 Jul 2020, at 21:23, Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:
> Please consider adding an easy way to turn the backward compatibility on
> and off.

I would suggest to settings, one that warns the definition has changed and one that errors on the old term rather than just a "turn on compatibility" which will mean that some people just turnout on an then never update.



--
'Never build a dungeon you wouldn't be happy to spend the night in
yourself,' said the Patrician (...). 'The world would be a
happier place if more people remembered that.' --Guards! Guards!

Dear Kevin,

I maintain a rule set specificly targeted at the Dutch language: [ https://dutchspamassassinrules.nl/DSR/DSR.cf | https://dutchspamassassinrules.nl/DSR/DSR.cf ]

One example is that our IRS ("Belastingdienst") is whitelisted by the following rule:

whitelist_from_spf *@belastingdienst.nl

Our IRS ("Belastingdienst") uses DKIM, SPF and DMARC, so fake messages are extremely easy to detect.

This list (DSR) is used by a number of mailservers in the Netherlands. So the changes that were made. will impact all servers that use the DSR


Met vriendelijke groet, Best regards,


Thom van der Boon
E-Mail: thom@vdb.nl


Van: "Kevin A. McGrail" <kmcgrail@apache.org>
Aan: "Thom van der Boon" <thom@vdb.nl>
Cc: "SA Mailing list" <users@spamassassin.apache.org>, "SpamAssassin Devel List" <dev@spamassassin.apache.org>
Verzonden: Zondag 19 juli 2020 19:56:34
Onderwerp: Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

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 < [ mailto:thom@vdb.nl | thom@vdb.nl ] > 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: [ mailto:thom@vdb.nl | thom@vdb.nl ]



Van: "Kevin A. McGrail" < [ mailto:kmcgrail@apache.org | kmcgrail@apache.org ] >
Aan: "SA Mailing list" < [ mailto:users@spamassassin.apache.org | users@spamassassin.apache.org ] >, "SpamAssassin Devel List" < [ mailto:dev@spamassassin.apache.org | dev@spamassassin.apache.org ] >
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
KMcGrail@Apache.org

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

can we use something like that or is there any special edit necessary?

sed -i 's/whitelist/welcomelist/g' $CONFIG

my setting "whitelist_from" to "welcomelist_from" || "welcome_from"?

Thanks

Am 19.07.20 um 18:09 schrieb Kevin A. McGrail:
> 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
>

--
Philipp Ewald
Administrator

DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: philipp.ewald@digionline.de

AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain

Informationen zum Datenschutz: www.digionline.de/ds

What is being used for mail that is not welcome, but still needs to be
allowed thru?



-----Original Message-----
To: users@spamassassin.apache.org
Subject: Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST
in process of being Renamed

can we use something like that or is there any special edit necessary?

sed -i 's/whitelist/welcomelist/g' $CONFIG

my setting "whitelist_from" to "welcomelist_from" || "welcome_from"?

Thanks

Am 19.07.20 um 18:09 schrieb Kevin A. McGrail:
> 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
>

ah sorry i wrote that totally wrong...

i mean we have "whitelist_from" setting.

should i change that to "welcomelist_from" or to "welcome_from", because when changing from "whitelist" to "welcomelist" should "welcomelist_from" be "right" but "welcome_from" sounds better.

So my second question is about how to automatically change that in configuration files?
> sed -i 's/whitelist/welcomelist/g'

Am 20.07.20 um 13:54 schrieb Marc Roos:
>
> What is being used for mail that is not welcome, but still needs to be
> allowed thru?
>
>
>
> -----Original Message-----
> To: users@spamassassin.apache.org
> Subject: Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST
> in process of being Renamed
>
> can we use something like that or is there any special edit necessary?
>
> sed -i 's/whitelist/welcomelist/g' $CONFIG
>
> my setting "whitelist_from" to "welcomelist_from" || "welcome_from"?
>
> Thanks
>
> Am 19.07.20 um 18:09 schrieb Kevin A. McGrail:
>> 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
>>
>
>

--
Philipp Ewald
Administrator

DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: philipp.ewald@digionline.de

AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain

Informationen zum Datenschutz: www.digionline.de/ds

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/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
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

On Mon, 20 Jul 2020, Thom van der Boon wrote:

> One example is that our IRS ("Belastingdienst") is whitelisted by the following rule:
>
> whitelist_from_spf *@belastingdienst.nl

That configuration syntax will continue to be supported for at least one
year after the release of SA 4.0 (i.e. it will not be dropped before the
first release occurring after that year has passed).


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
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

On Mon, 2020-07-20 at 09:30 -0700, John Hardin wrote:
> 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.
>
Repeating previously posted info for completeness: one of my private
rules uses URIBL_BLACK as a subrule. I have no other potential conflicts
with SA rule name changes and no postprocessing that's dependent on SA
rule names.

Martin

On 20/07/20 19:01, Martin Gregorie wrote:

> Repeating previously posted info for completeness: one of my private
> rules uses URIBL_BLACK as a subrule. I have no other potential conflicts
> with SA rule name changes and no postprocessing that's dependent on SA
> rule names.

Here just to say that URIBL Black is the official name that URIBL use
for that blocklist (http://uribl.com/usage.shtml). If there will be a
name change then a proposal should come from the URIBL team, not SA. If
SA is not satisfied with the name it should drop the list from the rules
if the URIBL team is not willing to comply to the name change.

I don't want to enter the discussion about what is good or not, I'm only
concerned that these changes could impact other products in the SA universe

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/

On Mon, 20 Jul 2020, Riccardo Alfieri wrote:

> On 20/07/20 19:01, Martin Gregorie wrote:
>
>> Repeating previously posted info for completeness: one of my private
>> rules uses URIBL_BLACK as a subrule. I have no other potential conflicts
>> with SA rule name changes and no postprocessing that's dependent on SA
>> rule names.
>
> Here just to say that URIBL Black is the official name that URIBL use
> for that blocklist (http://uribl.com/usage.shtml). If there will be a
> name change then a proposal should come from the URIBL team, not SA.

Apologies for not clarifying that detail; I was aware of it. I did hedge
by saying "(potentially) subject to renaming".


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If the rock of doom requires a gentle nudge away from Gaia to
prevent a very bad day for Earthlings, NASA won?t be riding to the
rescue. These days, NASA does dodgy weather research and outreach
programs, not stuff in actual space with rockets piloted by
flinty-eyed men called Buzz. -- Daily Bayonet
-----------------------------------------------------------------------
Today: the 51st anniversary of Apollo 11 landing on the Moon

On 20/07/20 19:31, John Hardin wrote:

>
> Apologies for not clarifying that detail; I was aware of it. I did
> hedge by saying "(potentially) subject to renaming".
>
No apologies necessary, it wasn't directed to you :)

I'm just trying to raise awareness that, while changing things is
possible, it must be done with proper testing and communication to all
the parties involved

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/

You go shut your piehole!!!!

Woke white guys who know best about racism against blacks and who use a
domain name that insults native Americans have spoken!!!

Black people and people of color need to go sit down and shut up while
woke white guys who know best for them do what is best for them.


Ted

PS Just be happy they haven't renamed the program "spamstopper" because
the name Assassin isn't I CAVE-approved (although icave
disbanded when the woke people who hated warner brothers succeeded in
getting Bugs Bunny off the air...was replaced by a bunch of other
splinter groups)

Have sympathy for them it's really tiring to be so woke....<eyeroll>