>> You go shut your piehole
Ehhh, who exactly? Having a nice evening with a vodka bottle? ;)
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
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,
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 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
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
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
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
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
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
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
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
On 19 Jul 2020, at 21:23, Olivier 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
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
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
:=)
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
On 20/07/2020 13:23, Olivier wrote:
> "Kevin A. McGrail" 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
"Kevin A. McGrail" 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
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,
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
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
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
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: t...@vdb.nl
Van: "Kevin A. McGrail"
Aan: "SA Mailing list" , "SpamAssassin Devel
List"
> 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
> 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
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.
26 matches
Mail list logo
