Mailing List Archive

On 16/07/2020 14:47, jdow wrote:

> You can probably fork the project and go on running what exists now going forward. That is something I am mulling doing for myself. I just have to ask myself, which is more painful?

Actually, might not have to reinvent the wheel, last time I looked at
rspamd was several years ago.

Since the politically motivated change in spamassassin was made public
last week, I reinstalled it in a dev lab. Running over the weekend,
tests showed rspamd has remarkably improved, 603% speed increase over
spamassassin (well it does run in C), and 18% more hit rates, when it
came to known false positives, it equalled spamassassin though.

Obviously before moving production over to it, I need to run it again
over a much longer period of time, but it looks promising, I'll see it
how goes over the next 4 weeks.

--

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.

> On Jul 19, 2020, at 10:12 PM, Noel Butler <noel.butler@ausics.net> wrote:
>
> On 16/07/2020 14:47, jdow wrote:
>
>>
>> You can probably fork the project and go on running what exists now going forward. That is something I am mulling doing for myself. I just have to ask myself, which is more painful?
>>
>>
>
> Actually, might not have to reinvent the wheel, last time I looked at rspamd was several years ago.
>
> Since the politically motivated change in spamassassin was made public last week, I reinstalled it in a dev lab. Running over the weekend, tests showed rspamd has remarkably improved, 603% speed increase over spamassassin (well it does run in C), and 18% more hit rates, when it came to known false positives, it equalled spamassassin though.
>
> Obviously before moving production over to it, I need to run it again over a much longer period of time, but it looks promising, I'll see it how goes over the next 4 weeks.
>

Yes, but what if they choose to use inclusive language? Then where do you go to avoid this oppression?
>
> --
>
> 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.
>

Noel Butler skrev den 2020-07-20 04:12:

> Actually, might not have to reinvent the wheel, last time I looked at
> rspamd was several years ago.

bah

> Since the politically motivated change in spamassassin was made public
> last week, I reinstalled it in a dev lab. Running over the weekend,
> tests showed rspamd has remarkably improved, 603% speed increase over
> spamassassin (well it does run in C), and 18% more hit rates, when it
> came to known false positives, it equalled spamassassin though.

sure political jokes does not come to rspamd, and rspamd is well simple
to configure for a programmer have screwdrivers in the pocket, ucl is
way more simple then xml is, counting all the craping xml standard
programs does not help much to ones own needs make it even more
complicted to just do what spamassassin does

if rspamd is a succes, why not just use dspam, learn it bayes spam and
bayes ham, job done, its really so simple that i would try it in fuglu
and have it all done in python code

but this step will still not be done from me since i like to stay with
the spamassassin problem for ever :-)

> Obviously before moving production over to it, I need to run it again
> over a much longer period of time, but it looks promising, I'll see it
> how goes over the next 4 weeks.

rspamd is hmm let me say it a joke of we want something better then
spamassassin, we could just nok dokument what we want as a programmer
point of view, so we make our own problem reinventing the wheel, sadly

are you saying just becourcs rspamd is in c its much better then
spamassassin ?

On 20/07/2020 13:57, Benny Pedersen wrote:

> rspamd is hmm let me say it a joke of we want something better then spamassassin, we could just nok dokument what we want as a programmer point of view, so we make our own problem reinventing the

I have proved over 60 hours that it is insanely better, but, it would be
remiss of me not to conduct a larger, lengthy test before committing
staff resources to wiping spamassassin from our networks

> are you saying just becourcs rspamd is in c its much better then spamassassin ?

I love perl, I can code it in my sleep, and likely may have on many a
time, but everyone knows that C is many magnitudes faster.

--
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.

What about mailfromd? I have this. I am really surprised it is not in
default repo's. I also looked at rspamd, but I have a bit of a problem
with these thousands of lines of config. Also their approach towards
stats/graphics is 'old fashioned', who is programming that when you have
tools like grafana.

I have proposed to the mailfromd to make something for prometheus
metrics, also where you can add your own metrics in the config file, so
you can tune and graph your config on specific areas.




-----Original Message-----
From: Noel Butler [mailto:noel.butler@ausics.net]
Sent: maandag 20 juli 2020 4:13
To: users@spamassassin.apache.org
Subject: Re: Thanks to Guardian Digital & LinuxSecurity for the nice
post about SpamAssassin's upcoming change

On 16/07/2020 14:47, jdow wrote:


You can probably fork the project and go on running what exists now
going forward. That is something I am mulling doing for myself. I just
have to ask myself, which is more painful?







Actually, might not have to reinvent the wheel, last time I looked at
rspamd was several years ago.

Since the politically motivated change in spamassassin was made public
last week, I reinstalled it in a dev lab. Running over the weekend,
tests showed rspamd has remarkably improved, 603% speed increase over
spamassassin (well it does run in C), and 18% more hit rates, when it
came to known false positives, it equalled spamassassin though.

Obviously before moving production over to it, I need to run it again
over a much longer period of time, but it looks promising, I'll see it
how goes over the next 4 weeks.




--

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.

On Mon, 20 Jul 2020 15:41:43 +1000
Noel Butler wrote:


>
> I have proved over 60 hours that it is insanely better, but, it would
> be remiss of me not to conduct a larger, lengthy test before
> committing staff resources to wiping spamassassin from our networks
>
> > are you saying just becourcs rspamd is in c its much better then
> > spamassassin ?
>
> I love perl, I can code it in my sleep, and likely may have on many a
> time, but everyone knows that C is many magnitudes faster.


My understanding is that most SA cpu cycles are spent in regular
expression library code and other binary libraries, and so the perl
interpreter overhead is relatively small.

The author of rspamd cited two reasons for its being faster. One is
that it uses automatic shortcircuiting to avoid evaluating the
more expensive dependencies of meta-rules. The other is that perl
programmers tend to overuse regular expressions.

I'm a bit suspicious about some of the speedup figures quoted, and
whether rspamd was tested against an optimized and similarly
parameterized SA. It's very easy to make SA look bad.

> I'm a bit suspicious about some of the speedup figures quoted, and
whether rspamd was tested
> against an optimized and similarly parameterized SA. It's very easy to
make SA look bad.

I agree. I have even asked on the mailing list how many test rspamd does
and how I can configure it to do just one test. Both questions were left
unanswered. Have a look at this mailfromd it is really nice.

On Mon, 20 Jul 2020 17:05:25 +0200
Marc Roos wrote:

>> I'm a bit suspicious about some of the speedup figures quoted, and
>> whether rspamd was tested against an optimized and similarly
>> parameterized SA. It's very easy to make SA look bad.
>
> I agree. I have even asked on the mailing list how many test rspamd
> does and how I can configure it to do just one test. Both questions
> were left unanswered.

rspamd is threaded so it should process a single message much faster
than SA. Whether it has better throughput under heavy load is a
different matter.

If it's still true that most cpu time is spent on evaluating rule
regexes then the throughput should be similar, with SA getting a modest
boost from sa-compile and rspamd getting a modest boost from
shortcircuiting out some subrules.


It wouldn't surprise me if the factor of 6 simply came from scanning
the test corpus one at a time on a 6 core cpu.

On 21/07/2020 01:05, Marc Roos wrote:

>> I'm a bit suspicious about some of the speedup figures quoted, and
> whether rspamd was tested
>
>> against an optimized and similarly parameterized SA. It's very easy to
> make SA look bad.
>
> I agree. I have even asked on the mailing list how many test rspamd does
> and how I can configure it to do just one test. Both questions were left
> unanswered. Have a look at this mailfromd it is really nice.

you did? I did'nt see it, the batch i put through it was hundreds of
thousands of messages. my month long test should yield about 30 million
msgs, be glad to let you know at the end of that.

I did nothing fancy since i'm not an rspamd expert.

--
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.

On Tue, 21 Jul 2020 20:25:58 +1000
Noel Butler wrote:

> On 21/07/2020 01:05, Marc Roos wrote:
>
> >> I'm a bit suspicious about some of the speedup figures quoted, and
> >>
> > whether rspamd was tested
> >
> >> against an optimized and similarly parameterized SA. It's very
> >> easy to
> > make SA look bad.
> >
> > I agree. I have even asked on the mailing list how many test rspamd
> > does and how I can configure it to do just one test. Both questions
> > were left unanswered. Have a look at this mailfromd it is really
> > nice.
>
> you did? I did'nt see it, the batch i put through it was hundreds of
> thousands of messages. my month long test should yield about 30
> million msgs, be glad to let you know at the end of that.

I'd missed that it was your testing. So when testing speed did you
measure throughput with enough concurrent tests and spamd child
processes to keep all the CPU cores fully occupied?

On 22/07/20 16:00, RW wrote:

>
> I'd missed that it was your testing. So when testing speed did you
> measure throughput with enough concurrent tests and spamd child
> processes to keep all the CPU cores fully occupied?

I have two VMs with same HW (2vCPU, 4GB RAM), one SA 3.4.4 and one
Rspamd 2.6, being fed by the same mail stream (20-30k mail/day).

Rspamd is, I'd say, more than 50% light on CPU and memory. And also
orders of magnitude quicker in doing checks. But to truly compare SA and
Rspamd you should run Rspamd with the SpamAssassin compatibility module
(https://rspamd.com/doc/modules/spamassassin.html) and have it load all
SA rules too.

--
Best regards,
Riccardo Alfieri

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

On Wed, 22 Jul 2020 14:11:31 +0000
Riccardo Alfieri wrote:

> On 22/07/20 16:00, RW wrote:
>
> >
> > I'd missed that it was your testing. So when testing speed did you
> > measure throughput with enough concurrent tests and spamd child
> > processes to keep all the CPU cores fully occupied?

> Rspamd is, I'd say, more than 50% light on CPU and memory.


Which implies that it's really only twice as fast in terms of
throughput. And I'm guessing that's on a lighter rule set.

This seems consistent with my expectation that the underlying engines
are of similar efficiency. A factor of two could easily be explained by
SA's huge historic rule cruft and other rule differences.


> But to truly compare SA
> and Rspamd you should run Rspamd with the SpamAssassin compatibility
> module (https://rspamd.com/doc/modules/spamassassin.html) and have it
> load all SA rules too.

The original claim made by the rspamd project was that it's much faster
on SA's own rules. I'm still not seeing any real evidence based on
measuring throughput with a meaningful methodology that involves full
core use on both tools.

I am wondering what grey list should be renamed...
--

Something benign like
"we're-bending-over-backwards-to-invent-offenses-that-we-can-remedy-a-shade-halfway-between-welcomelist-and-blocklist"

On 7/22/2020 8:36 PM, Olivier wrote:
> I am wondering what grey list should be renamed...

Maybelist?
Neutrallist?
Pcbalancedlist?





Sent via the Samsung Galaxy, powered by Cricket Wireless


-------- Original message --------
From: Olivier <Olivier.Nicole@cs.ait.ac.th>
Date: 7/22/20 7:38 PM (GMT-08:00)
To: users@spamassassin.apache.org
Subject: Re: Thanks to Guardian Digital & LinuxSecurity for the nice post about SpamAssassin's upcoming change

I am wondering what grey list should be renamed...
--

DelayList would be my off the cuff thought. Grey isn't racially charged
but renaming it would be more descriptive on what it does. The SA project
doesn't have any greylisting functionality, that is usually the MTA.

On Wed, Jul 22, 2020, 22:37 Olivier <Olivier.Nicole@cs.ait.ac.th> wrote:

> I am wondering what grey list should be renamed...
> --
>

On Thu, 2020-07-23 at 09:36 +0700, Olivier wrote:
> I am wondering what grey list should be renamed...

Ageist!


;-)

Martin

On Thursday 23 July 2020 at 04:36:41, Olivier wrote:

> I am wondering what grey list should be renamed...

Why - has the zombie population started complaining about racial slurs?


Antony.

--
"The future is already here. It's just not evenly distributed yet."

- William Gibson

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

On Thu, 23 Jul 2020, Antony Stone wrote:

> On Thursday 23 July 2020 at 04:36:41, Olivier wrote:
>
>> I am wondering what grey list should be renamed...
>
> Why - has the zombie population started complaining about racial slurs?

You have just pissed off Oscar the gray geriatric grouch. ;)

This is the letter G brought to you by Oscar the grouch.

--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{