https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
--- Comment #7 from Sidney Markowitz ---
I'm also documenting more complete steps for a release box starting from a
minimal Ubuntu install, putting it on our wiki. Also, updating build/README on
svn.
Items 1-4 done. I'm going to think a bit
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@apache.org
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #10 from Kevin A. McGrail ---
(In reply to Kevin A. McGrail from comment #9)
> (In reply to Henrik Krohns from comment #8)
> > Apologies for misunderstanding, just wanted to make sure there are no
> > "surprise commits" waiting t
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
--- Comment #6 from Kevin A. McGrail ---
(In reply to Henrik Krohns from comment #5)
> (In reply to Sidney Markowitz from comment #4)
> > (In reply to Kevin A. McGrail from comment #1)
> > > Just one note that I believe the root flag was add
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #9 from Kevin A. McGrail ---
(In reply to Henrik Krohns from comment #8)
> Apologies for misunderstanding, just wanted to make sure there are no
> "surprise commits" waiting to happen, as it almost sounded like that.
As we are n
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
--- Comment #5 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #4)
> (In reply to Kevin A. McGrail from comment #1)
> > Just one note that I believe the root flag was added back when the tests
> > would possibly slam a prod
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
--- Comment #4 from Sidney Markowitz ---
(In reply to Kevin A. McGrail from comment #1)
> Just one note that I believe the root flag was added back when the tests
> would possibly slam a production instance of something like spamd running on
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #8 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #7)
> (In reply to Henrik Krohns from comment #6)
> > (In reply to Kevin A. McGrail from comment #5)
> > > I also want to change the compat for
> > > WLBL both
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
--- Comment #4 from Henrik Krohns ---
I mostly agree with everything, great to have extra eyeballs. Can you comment
if my previous list comment and Revision 1900667 additions cleared any things
up for you and changes anything?
As a develope
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #7 from Kevin A. McGrail ---
(In reply to Henrik Krohns from comment #6)
> (In reply to Kevin A. McGrail from comment #5)
> > I also want to change the compat for
> > WLBL both with and without the racially charged language. We'
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
--- Comment #3 from Kevin A. McGrail ---
(In reply to Henrik Krohns from comment #2)
> Good stuff. It should not only be easy for "release manager" to run all
> possible tests, but all the release testers too.
That's feasible nowadays. The
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #6 from Henrik Krohns ---
(In reply to Kevin A. McGrail from comment #5)
> I also want to change the compat for
> WLBL both with and without the racially charged language. We've been
> discussing a test plan and scheduling for t
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@apache.org
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
Henrik Krohns changed:
What|Removed |Added
CC||apa...@hege.li
--- Comment #2 from
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@apache.org
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
Sidney Markowitz changed:
What|Removed |Added
CC||sid...@sidney.com
Target Miles
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7988
Bug ID: 7988
Summary: Fix and streamline tests for release process
Product: Spamassassin
Version: 4.0.0
Hardware: All
OS: All
Status: NEW
Severity: n
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
--- Comment #3 from Michael Storz ---
Well, it took me more than a day of carefully reviewing the call diagram and
implementation of bgsend_and_start_lookup to come to this conclusion. My first
thought was that maybe some tests are not worki
On Sat, May 07, 2022 at 07:41:00PM +0200, Michael Storz wrote:
> Hi Henrik,
>
> you added a rule_ready to OneLineBodyRuleType.pm
>
> +$sub .= '
> + $self->rule_ready(q{'.$rulename.'});
> +';
> +
>
> Why? I thought OneLineBodyRuleType.pm does not have asynchronous calls? And
> if rul
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
Henrik Krohns changed:
What|Removed |Added
CC||apa...@hege.li
--- Comment #2 from
Hi Henrik,
you added a rule_ready to OneLineBodyRuleType.pm
+$sub .= '
+ $self->rule_ready(q{'.$rulename.'});
+';
+
Why? I thought OneLineBodyRuleType.pm does not have asynchronous calls?
And if rule_ready is used, should'n there be a call to rule_pending
first?
A similar case
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
Michael Storz changed:
What|Removed |Added
CC||sa-...@lrz.de
--- Comment #1 from M
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
Bug ID: 7987
Summary: DNSEval.pm,HashBL.pm,URILocalBL.pm: unnecessary use of
rule_pending and rule_ready
Product: Spamassassin
Version: 4.0.0
Hardware: All
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7981
--- Comment #4 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #3)
> A pending task for a full release is to write the description of new
> features and important changes in this version that will go into the
> build/announ
On Sat, May 07, 2022 at 04:47:37PM +0200, Benny Pedersen wrote:
> > So no header would be tokenized by default, unless there is
> > "bayes_allow_header From To Received" etc.
>
> yes i belive this is "install and forget", needed good headers dont change
Who knows what are "good headers" and if ra
On 2022-05-07 16:37, Henrik K wrote:
Ok I got it now..
and its not yet monday ? :)
So no header would be tokenized by default, unless there is
"bayes_allow_header From To Received" etc.
yes i belive this is "install and forget", needed good headers dont
change
Dunno, it might help or mi
On Sat, May 07, 2022 at 04:29:33PM +0200, Benny Pedersen wrote:
> On 2022-05-07 16:14, Henrik K wrote:
> > On Sat, May 07, 2022 at 04:09:02PM +0200, Benny Pedersen wrote:
> > >
> > > with bayes_indexed_header it would make less lines needed to be
> > > added, and
> > > it would not need much updat
On 2022-05-07 16:14, Henrik K wrote:
On Sat, May 07, 2022 at 04:09:02PM +0200, Benny Pedersen wrote:
with bayes_indexed_header it would make less lines needed to be added,
and
it would not need much updates either, and also less memory usage is
needed
Please explain how "bayes_indexed_heade
On Sat, May 07, 2022 at 04:09:02PM +0200, Benny Pedersen wrote:
>
> with bayes_indexed_header it would make less lines needed to be added, and
> it would not need much updates either, and also less memory usage is needed
Please explain how "bayes_indexed_header" (whatever it is) would make less
l
On 2022-05-07 15:58, Henrik K wrote:
I don't understand what you mean with "trust".
sorry my wording on it then :/
bayes_ignore_header is used for ignoring headers that produces random
garbage tokens, or too common ones that have no use for classifying
other
messages.
lets just continue
On Sat, May 07, 2022 at 03:46:13PM +0200, Benny Pedersen wrote:
> On 2022-05-07 15:19, Henrik K wrote:
>
> > > 3) a better patch :=)
> > Sorry, I tried reading three times, but I don't understand your
> > suggestion..
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hege.li; s=hege2;
>
On 2022-05-07 15:19, Henrik K wrote:
3) a better patch :=)
Sorry, I tried reading three times, but I don't understand your
suggestion..
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hege.li; s=hege2;
t=1651929565; bh=mDJa8KTm9fQckBvDRBvqjvPDd2nTerfIP3931ZK07fQ=;
h=Dat
On Sat, May 07, 2022 at 03:08:08PM +0200, Benny Pedersen wrote:
> On 2022-05-07 10:42, Henrik K wrote:
>
> > Wouldn't these be better put directly into bayes/23_bayes.cf instead of
> > some
> > sandbox, that's intended more for testing rules than changing SA config?
>
> i think we would change it
On 2022-05-07 10:42, Henrik K wrote:
Wouldn't these be better put directly into bayes/23_bayes.cf instead of
some
sandbox, that's intended more for testing rules than changing SA
config?
i think we would change it to be a list of headers always indexed, not
just random ignored ?
could be d
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7363
Nick Alcock changed:
What|Removed |Added
CC||n...@esperi.org.uk
--- Comment #8 fro
There's lots of common headers that are basically huge base64 strings,
creating stupid amounts of random Bayes tokens.
Apparently rulesrc/sandbox/axb/23_bayes_ignore_header.cf was created to
handle some of these already?
I've found atleast these missing:
IronPort-SDR
X-Exchange-Antispam-Report
36 matches
Mail list logo
