Issue with RSpamd

I was hoping that after the new learning process the issue will be resolved, but unfortunately, after coming to 98%, the learning process has been restarted once again from the start. Now the situation is like this

The only thing that might trigger it (at least my assumption) was several dirty restarts few days ago due to no power supply (the UPS obviously had a faulty battery and didn’t help to gracefully shut down the server).

Any idea how to reconfigure to use the already learned spam and hams or I have to wait for another round of learning?

I see the same behavior in myself all the time. I have given up trying to understand it. Even after a brand new installation, the phenomenon occurs.

Thank you Marko, at least I know that I’m not the only one with this experience.

the only things we could smell is a redis database corruption, what is the output

ls -la /var/lib/redis/rspamd/

# ls -la /var/lib/redis/rspamd/
total 10280
drwxr-xr-x 2 redis redis       22 Feb 18 12:53 .
drwxr-x--- 3 redis redis       20 Jan 15 18:55 ..
-rw-r--r-- 1 redis mail  10524677 Feb 18 12:53 dump.rdb

In my case

Screenshot 2022-02-18

1 Like

today the next reset and a full spammed mailbox :frowning:

Ok, I trained my bayes filter manually again.

# rspamc stat

Messages learned: 1305

3 Likes

Nice trick :). You made my day with this one, thank you Marko!

No laptop next to me but I can confirm this, I have a wave of spam since three days

me too

1 Like

I wonder if the culprit is not here

I wonder if we do not purge the database each 100 days

This is the default, I think we could set to -1, we already set a max memory to 300MB

See the documentation

1 Like

image

I am not sure the bayes has been set to null in my case

I set to expire = -1 in /etc/e-smith/templates/etc/rspamd/local.d/classifier-bayes.conf/10Base, then signal-event nethserver-mail-filter-update

obviously the next rpm update will set again the former value

by curiosity @capote could you give the size of your database /var/lib/redis/rspamd/dump.rdb

# ll /var/lib/redis/rspamd/
total 19728
-rw-r--r-- 1 redis mail 20199725 Feb 25 20:02 dump.rdb

I have the same problem. Even tough I use NS over a year now, the spam filter never got above 20%.

I now created a custom-template with the above suggestions:

mkdir -p /etc/e-smith/templates-custom/etc/rspamd/local.d/classifier-bayes.conf/
sed 's/expire.*=.*/expire = -1/' </etc/e-smith/templates/etc/rspamd/local.d/classifier-bayes.conf/10Base >/etc/e-smith/templates-custom/etc/rspamd/local.d/classifier-bayes.conf/10Base
signal-event nethserver-mail-filter-update

Is there any means to retrain the filter according to the current inbox or send box?

1 Like

I’m facing (with an external email service and on a completely different platform/set of tools) an increased wave of spam.

IMVHO current and close past events are also affecting the volume and “noise” of unwanted messages due to a decreased signal-to-noise ratio on the world communications (so much more spam than usual).

IMVHO i’d train the “spam” section instead of the “ham” section, after the manual classification. It’s tedious do the selection instead of make the do the evaluation to amavisd/rSpamd.
But as usual, spam fight is about reaction, more than prevention.

I have myself a spam wave, they use forged sender email, I am not sure that a bayes filter can help.

I needed to check and find the exact sender in the maillog transaction to reject them. They have a really good MX and DNS set, they are better than us :smiley:

19896:Mar  8 12:44:27 prometheus rspamd[8110]: <901b7b>; proxy; rspamd_task_write_log: id: <9389962d5972dcafff1400e966a7ced3@curlylimit.com>, qid: <1188918D999C0>, ip: 5.135.203.49, from: <newsletter@curlylimit.com>, (default: F (no action): [3.78/19.90] [FROM_EXCESS_QP(1.20){},SUBJ_EXCESS_QP(1.20){},URI_COUNT_ODD(1.00){5;},IP_REPUTATION_SPAM(0.75){asn: 16276(0.19), country: FR(-0.00), ip: 5.135.203.49(0.00);},R_DKIM_ALLOW(-0.20){curlylimit.com:s=dkim;},R_SPF_ALLOW(-0.20){+ip4:5.135.203.49;},MIME_GOOD(-0.10){multipart/alternative;text/plain;},ZERO_FONT(0.10){1;},MANY_INVISIBLE_PARTS(0.05){1;},HAS_LIST_UNSUB(-0.01){},MX_GOOD(-0.01){},ASN(0.00){asn:16276, ipnet:5.135.0.0/16, country:FR;},DKIM_TRACE(0.00){curlylimit.com:+;},DMARC_NA(0.00){curlylimit.com;},FROM_EQ_ENVFROM(0.00){},FROM_HAS_DN(0.00){},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;1:+;2:~;},NEURAL_HAM(0.00){-0.337;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_ZERO(0.00){0;},TO_DN_ALL(0.00){},TO_EXCESS_QP(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 13385, time: 219.536ms, dns req: 27, digest: <5fac38cf8b5ed85aeec2b5c4e0291f74>, rcpts: <stephane@domain.com>, mime_rcpts: <stephane@domain.com>



18179:Mar  8 08:35:36 prometheus rspamd[8110]: <6c11c6>; proxy; rspamd_task_write_log: id: <8189cf40540cccd4a0c0a514eaa59d2b@paltryeffect.com>, qid: <BE31518D99BE2>, ip: 212.227.126.187, from: <SRS0=y9vl=TT=paltryeffect.com=newsletter@srs2.kundenserver.de>, (default: F (no action): [0.91/19.90] [FROM_EXCESS_QP(1.20){},TO_EXCESS_QP(1.20){},URI_COUNT_ODD(1.00){5;},IP_REPUTATION_HAM(-0.75){asn: 8560(-0.18), country: DE(-0.00), ip: 212.227.126.187(-0.57);},BAYES_HAM(-0.58){81.47%;},GENERIC_REPUTATION(-0.58){-0.58107106869464;},DMARC_POLICY_ALLOW(-0.50){paltryeffect.com;none;},FORGED_SENDER(0.30){newsletter@paltryeffect.com;SRS0=y9vl=TT=paltryeffect.com=newsletter@srs2.kundenserver.de;},R_DKIM_ALLOW(-0.20){paltryeffect.com:s=dkim;},R_SPF_ALLOW(-0.20){+ip4:212.227.126.128/25:c;},MIME_GOOD(-0.10){multipart/alternative;text/plain;},ZERO_FONT(0.10){1;},MANY_INVISIBLE_PARTS(0.05){1;},HAS_LIST_UNSUB(-0.01){},MX_GOOD(-0.01){},ASN(0.00){asn:8560, ipnet:212.227.0.0/16, country:DE;},DKIM_TRACE(0.00){paltryeffect.com:+;},FROM_HAS_DN(0.00){},FROM_NEQ_ENVFROM(0.00){newsletter@paltryeffect.com;SRS0=y9vl=TT=paltryeffect.com=newsletter@srs2.kundenserver.de;},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;1:+;2:~;},NEURAL_HAM(0.00){-0.990;},PREVIOUSLY_DELIVERED(0.00){stephane@domain.com;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_TWO(0.00){2;},RCVD_IN_DNSWL_NONE(0.00){212.227.126.187:from;},RCVD_TLS_ALL(0.00){},RWL_MAILSPIKE_POSSIBLE(0.00){212.227.126.187:from;},TO_DN_ALL(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 13603, time: 367.463ms, dns req: 32, digest: <7d429949e2b38af1459d9a0fa01cce91>, rcpts: <stephane@domain.com>, mime_rcpts: <stephane@domain.com>

Often SPF is useful for this kind of unwanted traffic.
And Greylisting might lower the fake sender queue… until they become part of lists (blacklists, ipthreat lists, firehol lists, crowsourced lists…)

I have implemented SPF and graylisting (together with TLSA/DMARC/DANE), but recognize the same big spam wave.

Additionally, my WordPress firewall reports a lot of critical attacks like Brute-force each day.