Mailing List Archive

On 7/19/2020 11:44 AM, Linkcheck wrote:
> Can someone post a list of ALL the new names, with their originals,
> please?

The only functionality changed so far is WHITELIST_TO which is now
WELCOMELIST_TO in the configuration options with backwards compatibility.

The stock rule that was USER_IN_WHITELIST_TO is now USER_IN_WELCOMELIST_TO

Whitelist will become welcomelist and blacklist will become blocklist.?
Are you running a modern SA like 3.4.4?? If so, you should be able to
proactively add entries for this.

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 17:44:27, Linkcheck wrote:

> Thanks to those responsible for screwing up the scoring of my
> spamassassin installation. It's been working well for years but now my
> changes to scoring have been cancelled due to renaming
> whitelist/blacklist to whatever.
>
> I noticed it purely by accident this morning: USER_IN_WHITELIST_TO no
> longer gave me the expected score because it has now been replaced by
> USER_IN_WELCOMELIST_TO.

I think you must quite possibly be the only person on this list who has not
noticed the 223 emails containing "IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK"
in the subject line over the past 9 days discussing precisely this change.

I sympathise with you - I really do - I do not agree with the changes which
have occurred, the reasons for them, or the lack of discussion with the
community before they were implemented, but I find the fact that you haven't
noticed they have already been done and have been announced here quite
remarkable.

> Can someone post a list of ALL the new names, with their originals, please?

Excellent request - I'm surprised that the powers-that-be who have implemented
these changes haven't simply done this as a matter of course.

I see no mention of such a list in the bug report (how ironic that a bug
report gets filed to announce the introduction of a bug into the software...)
which was quoted in the original announcement of this fait accompli to the
list:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826


Regards,


Antony.

--
There's no such thing as bad weather - only the wrong clothes.

- Billy Connolly

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

On Sun, 2020-07-19 at 11:59 -0400, Kevin A. McGrail wrote:

> Whitelist will become welcomelist and blacklist will become
> blocklist. Are you running a modern SA like 3.4.4? If so, you should
> be able to proactively add entries for this.
>
Just been grepping my local rules for WHITELIST and BLACKLIST without
finding any that none are affected by those changes.

Then I also grepped them for WHITE and BLACK and this time I saw that
two of my local rules reference the standard URIBL_BLACK rule. Is this
name likely to change?

Martin

Great question. That's really a third party rule. I would like to see it
change eventually but maybe that's another phase. Thoughts?

On Sun, Jul 19, 2020, 13:17 Martin Gregorie <martin@gregorie.org> wrote:

> On Sun, 2020-07-19 at 11:59 -0400, Kevin A. McGrail wrote:
>
> > Whitelist will become welcomelist and blacklist will become
> > blocklist. Are you running a modern SA like 3.4.4? If so, you should
> > be able to proactively add entries for this.
> >
> Just been grepping my local rules for WHITELIST and BLACKLIST without
> finding any that none are affected by those changes.
>
> Then I also grepped them for WHITE and BLACK and this time I saw that
> two of my local rules reference the standard URIBL_BLACK rule. Is this
> name likely to change?
>
> Martin
>
>
>

On 19 Jul 2020, at 10:54, Kevin A. McGrail wrote:

> Great question. That's really a third party rule. I would like to
> see it
> change eventually but maybe that's another phase. Thoughts?

My thoughts are to delay any further social/political motivated name
changes until after the extents of the current process are fully
completed and understood. At that time, I would also suggest bringing in
the opinions of the people who will bear the larger extent of the
implementation – the users themselves – as well as the allegedly
aggravated people on whose behalf you seem to favor the change.

Best regards

-lem

On Sun, 2020-07-19 at 15:44 -0700, Luis E. Muñoz wrote:
> On 19 Jul 2020, at 10:54, Kevin A. McGrail wrote:
>
> > Great question. That's really a third party rule. I would like to
> > see it
> > change eventually but maybe that's another phase. Thoughts?
>
The only way I can see to prevent the name changes from affecting SA
users private rules is to duplicate the affected rules: one copy using
BLACKLIST/WHITELIST and the other using BANNEDLIST/WELCOMELIST and,
since both copies will fire, with their scores halved. This will allow
private rules to work as normal until the BLACK/WHITE rule names are
removed from the standard set: the overall score for a message will
remain unchanged.

The above should solve the problem for cases (the majority?) where the
private rules only care whether subrules fire or not. However, if
anybody's private rules compare subrule score values then the private
rules may fail completely unless rewritten.

Martin

On 7/19/2020 8:23 PM, Martin Gregorie wrote:
> The only way I can see to prevent the name changes from affecting SA
> users private rules is to duplicate the affected rules

Yeah, I just posted this idea on the dev list to use a meta like this
which I think will allow it to work backwards to 3.3.x. Will that work
for your install?

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

--
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 20200719 15:44:54, Luis E. Muñoz wrote:
> On 19 Jul 2020, at 10:54, Kevin A. McGrail wrote:
>
>> Great question.  That's really a third party rule.  I would like to see it
>> change eventually but maybe that's another phase.  Thoughts?
>
> My thoughts are to delay any further social/political motivated name changes
> until after the extents of the current process are fully completed and
> understood. At that time, I would also suggest bringing in the opinions of the
> people who will bear the larger extent of the implementation – the users
> themselves – as well as the allegedly aggravated people on whose behalf you seem
> to favor the change.
>
> Best regards
>
> -lem

There is something to be said for running SL 7.x rather than something fancy and
newer. I get to see other people have problems and have plenty of time to deal
with them before they hit me.

{^_-}

On Sun, 2020-07-19 at 20:27 -0400, Kevin A. McGrail wrote:
> On 7/19/2020 8:23 PM, Martin Gregorie wrote:
> > The only way I can see to prevent the name changes from affecting SA
> > users private rules is to duplicate the affected rules
>
> Yeah, I just posted this idea on the dev list to use a meta like this
> which I think will allow it to work backwards to 3.3.x. Will that work
> for your install?
>
Your suggested workround should work here although, because my private
rules don't reference any standard ruleset rules with names containing
'BLACKLIST' or 'WHITELIST', I'm not affected by these name changes:
thats pure luck.

Your idea is neater than my suggestion because it can't mess up private
rules that make use of numeric score values. However, both workrounds
will, I suspect, make standard rule maintenance more complex. What about
maintaining one format in ruleQA output and including a configurable
rule name conversion step in the rules update process? If that was
controlled by a new local.cf directive it should be a pretty small code
change.

Martin

>On Sunday 19 July 2020 at 17:44:27, Linkcheck wrote:
>> Thanks to those responsible for screwing up the scoring of my
>> spamassassin installation. It's been working well for years but now my
>> changes to scoring have been cancelled due to renaming
>> whitelist/blacklist to whatever.
>>
>> I noticed it purely by accident this morning: USER_IN_WHITELIST_TO no
>> longer gave me the expected score because it has now been replaced by
>> USER_IN_WELCOMELIST_TO.

On 19.07.20 18:00, Antony Stone wrote:
>I think you must quite possibly be the only person on this list who has not
>noticed the 223 emails containing "IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK"
>in the subject line over the past 9 days discussing precisely this change.

maybe he is just not running trunk and so ignored tha thread.
Or, maybe he expected tohe change only to take place in trunk.

any way, I would also expect this change happen after new SA release, or at
least after announce different than "... running trunk ..."

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Save the whales. Collect the whole set.

Whether or not it's the ONLY one it should have been NONE. You claimed
we would not have to change anything for at least a year - as I
understodd it. Certainly you should not have broken existing installations!

I am running 3.4.2, dictated by my OS. I am quite happy running that
version - at least, I was before the speciously argued changed that
broke it.

What about all the other whitelist and blacklist nomenclature in the
(pre-broken) version? I have altered scores for those below. Are they
also broken? Or any other that I may have missed?

priority USER_IN_WHITELIST
priority USER_IN_DEF_WHITELIST
priority USER_IN_ALL_SPAM_TO
priority USER_IN_DKIM_WHITELIST
priority USER_IN_DEF_DKIM_WL
priority USER_IN_SPF_WHITELIST
priority USER_IN_DEF_SPF_WL
priority USER_IN_BLACKLIST
priority USER_IN_BLACKLIST_TO
shortcircuit USER_IN_WHITELIST
shortcircuit USER_IN_DEF_WHITELIST
shortcircuit USER_IN_ALL_SPAM_TO
shortcircuit SUBJECT_IN_WHITELIST
shortcircuit USER_IN_DKIM_WHITELIST
shortcircuit USER_IN_DEF_DKIM_WL
shortcircuit USER_IN_SPF_WHITELIST
shortcircuit USER_IN_DEF_SPF_WL
shortcircuit USER_IN_BLACKLIST
shortcircuit USER_IN_BLACKLIST_TO
shortcircuit SUBJECT_IN_BLACKLIST

I read the thread. I didn't comment because it was obvious the rationals
would lose and the unnecessary changes would go ahead. From that
discussion I took away the thought that I had a long-ish breathing space
which would allow me to update my complete mail server - OS, Postfix and
all - and get rid of the now-likely-to-break spamassassin. I did not
expect it to break within a few days!

I wonder how this fiasco will affect all those who do not audit this
list - surely a large number? Or any who, due to the SPF failure
yesterday, missed some of the list?

This whole affair has been badly mis-managed. No engineer should have
behaved in this cavalier fashion for such a spurious, mis-informed
reason and with such a short change-over perdiod.