https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7972
--- Comment #1 from Henrik Krohns ---
And in this case I assume we would want to include it by default in distributed
init.pre, so fresh installations will have it, but old ones will not be
overridden.
enable_compat welcomelist_blocklist
-
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #85 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #84)
> if can(Mail::SpamAssassin::Conf::compat_welcomelist_blacklist)
>
> (Yeah this could be in it's own bug, but it's quite tied to this bug at this
> time)
T
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7972
Henrik Krohns changed:
What|Removed |Added
Target Milestone|Undefined |4.0.0
CC|
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7972
Bug ID: 7972
Summary: Version compatibility flagging method
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #84 from Henrik Krohns ---
Assuming we want to go with the welcomelist route, I'd still like to figure out
a more generic solution for defining "version compatibility". So people can
turn on some flag when they have checked their
On Sun, 17 Apr 2022, Axb wrote:
On 4/16/22 19:23, bugzilla-dae...@spamassassin.apache.org wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #72 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #69)
...
- Roll back all the changes from trunk, and wo
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #83 from Bill Cole ---
(In reply to Henrik Krohns from comment #80)
> By the way I'm actually pretty happy with the state of trunk-welcomelist
> now, I'm running it on production too. And it only took some hours of
> determined h
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #82 from Sidney Markowitz ---
(In reply to Henrik Krohns from comment #81)
> There was discussion before if we really need
> one.. I think agreement was that development is so marginal that it's fine
> to do things in trunk direc
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #81 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #77)
> 2) steps that would complete this issue to get to a stable
> and coherent 4.0.0 release.
It could go something like this:
- Test trunk-welcomelist
-
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #80 from Henrik Krohns ---
By the way I'm actually pretty happy with the state of trunk-welcomelist now,
I'm running it on production too. And it only took some hours of determined
hard grinding.
I would not object merging it in
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #79 from Henrik Krohns ---
(In reply to Michael Storz from comment #71)
> I think the whole approach of this rewording is suboptimal. I would strongly
> suggest to separate the renaming from the aliases management. The aliases
>
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
--- Comment #78 from Henrik Krohns ---
I've committed massive update to trunk-welcomelist (revision 1899925), which
renames pretty much all of white->welcome, black->block. You can see how many
changes were missing. Backwards compatibility w
12 matches
Mail list logo
