Dear, as far as I can see rspamd default filter incoming email also for the user that does not have a domain (or email) antispam policy set on ispconfig. And rspamd use the values that we can see in that file here: Code: -- /etc/rspamd/actions.conf [...] reject = 15; # Reject when reaching this score add_header = 6; # Add header when reaching this score greylist = 4; # Apply greylisting when reaching this score (will emit `soft reject action`) [...] In that scenario this can evolve in trouble because often several incoming email get a score over these values, so the customers get his mail filtered also without any rspamd policy set on his mail domain (or email). So if that is correct (and i'm hereby ask a confirm to you), my approach was to increase that default value in the local file, like these: Code: -- /etc/rspamd/local.d/actions.conf [...] reject = 30; # Reject when reaching this score add_header = 15; # Add header when reaching this score greylist = 15; # Apply greylisting when reaching this score (will emit `soft reject action`) [...] The expectation is that in that way if no antispam policy is set, the value are so big that are never reach, and therefore pass the filter stuff only if the customer has a proper policy set. The question: is that approach suitable? Or in your opinion this can override also the per-user preference that I see written by ispconfig in /etc/rspamd/local.d/users/* ? Thank you
No it is not. The behavior is correct. If you don't want that than apply a filter rule to the user that allows all mails, for example by setting the user specific reject, add_header and greylist values to "100" or so. Create a new Spamfilter Poliy and set the values under "rspamd" tab accordingly and enable "Wants Spam" and "Wants Virus". Then apply that policy to the user(s) in question in ISPConfig. I cannot imagine why anyone want's this but to each their own
Generally speaking i can absolutely agree with you. But this is a case of a stack of ispconfig migrated from amavis to rspamd in these days. With amavis we could be sure that if the mail domain (or mail account) was with "-not enabled-", the mail was not filtered. While now with rspamd, they are still filtered with the above default value. So the customers that has "-not enabled-" they expect that no one email is filtered at all, but suddently find that mails the prior was received, now are filtered (or rejected. Some times happens that rspamd give +15 to mail that are not spam, due a _very bad_ writing/mta sender configuration of the mail itself). Moreover some customers want our spamfiltered completely disabled because they use some custom spam filter local on their network. This is a medium-to-big installation (would say >1000 mail domain) so we simply can't modify manually all the mail domain to a generic *very high policy* as advised to you above. With the environment in mind, my strategy was to try to avoid that rspamd with "-not enabled-" filter anything on that domain that are set in that way, in order to be able to force them to use some policy configured instead, if they find too much spammy email incoming. Hope now is more clear. Thank you.
That's not the case, its exactly the same than in Rspamd. In Amavis, all emails with that option get filtered and the amavisd default scores get applied. ISPConfig comes with a rule set for that, its named non-paying if I remember correctly. The rule set applies to Amavis and Rspamd and sets very high scores. But as said by @pyte, amavis and Rspamd will always run all emails trough their filters, its just that they do not add headers for these mails and that's why this rule set exists for users that do not want to get spam headers added. But, you can always alter the defaults of Amavis and Rspamd if the defaults that are shipped by the package maintainer do not match your requirements.
Ok, probably so due the pretty different level of filter that provide rspamd vs amavis, a lot of emails that with amavis goes through, with rspamd are filtered or rejected. That's make sense. Btw i'll check with a couple of nodes, if rise the default value of rspamd is suitable for us, otherwise, we will try a different approach. thank you both.
You should really have a look into these mails then. The defaults are very sane and much more relaxed than any big mailprovider for example. When a default config of rspamd rejects mails, the mails are technically most likley bad.
I reply on this thread, just because i don't like spam to much the forum with several thread, and this others question is slightly related to the previous one. With rspamd the hierarchy of the spam filter policy between mail domain and mail user, works as the same as the previous amavisd-new? I mean in the same way that I see on page 179 of the ispconfig manual that was written when ispconfig used amavisd as default. Because i have a situation where for a mail-domain-wide we use "Normal" policy, and on one specific email address of that domain we use "Permissive". But as far as i can see the policy used on that specific mail is still the "Normal" used for domain wide. Is that an expected behaviour? Moreover: for the outgoing email i see that they are filtered via rspamd following the default value specificed on actions.conf (rspamd) config file. Is that fine too? thank you
There seems to be an issue. ISPConfig writes the "priority" field for the rspamd user config, but sets it to a number + the priority number set in ISPConfig. According to the docs there should be "high", "medium" and "low" set. I don't know if numbers e.g. 1, 2, 3 even work at that place but have to do some testing. I will check this next week, if no one repsonse in the meantime
thank you a lot, i will try some test also from my side. just because you are here, you know if the outgoing policy rate of rspamd is the default one as statet above? Because as far as i can see, from my test seems in that way.
Ok maybe found. Some policy user, are not set as local (so local="" instead local="Y"). For these users (around 10-15% of total) the mailbox policy is not got. No idea why they are in that way. But updating local=Y for these users and then resave the policy, the hierachy is fine. Non need others check from you @pyte thank you any way. The only unanswered things is about the outgoing policy: but in my opinion yes, rspamd get for all the outgoing email the same default filter value (so the one specified by rspamd/actions.conf). thank you for the support
No worries. Still wonders me why it is working that way, as it is not mentioned in the rspamd docs. Does not hurt to do some testing, and may make some changes so stuff does not break in the future.
I reopen this thread, because it's always related to rspamd/policy issue. Probably i have found an issue that should be a bug. But on the bug tracker i see that is advised to discuss on the forum before open the bug itself. This could be a severe one. Because as far as I can see, also considering a total default installation did via autoinstaller (on the latest version), with rspamd, if you modify an email from the ispconfig interface, without change the rspamd policy (for example just updating the quota of the mail) the server.php script that run on the server itself, basically remove the rspamd user config that should be in rspamd/local.d/users/ directory. Then if you change the policy again on the interface, the file is now written again. But if we modify again the email, without changing the spamfilter policy (for example keep the spamfilter to normal, and update again the quota) the file is removed again. And so on. After some debuggin i have seen probably where the cause is. Can i open already the bug, of someone of the ispconfig staff needs to reproduce this before?
Feel free to open an issue report; I will see if I can reproduce it then. The policy to post to the forum first is mainly targeted to inexperienced users as many users don't seem to know the difference between an issue tracker and a support forum and then use the issue tracker to ask for support, which clutters the git system.
i use that thread, because open a new one for that thing, is an overkill for sure. We are seeing some strange numbers on BAYES_SPAM symbol on rspamd (something like 5+ points, with 100% spam probability on a completely legit mailchimp email). I have tried to find out inside the code of ispconfig, but i was not be able to find out how the spam/ham policy are updated. And in some ways they are did because the trainining exist: root@XXX:# rspamc stat | grep Statfile Statfile: BAYES_SPAM type: redis; length: 0; free blocks: 0; total blocks: 0; free: 0.00%; learned: 963; users: 1; languages: 0 Statfile: BAYES_HAM type: redis; length: 0; free blocks: 0; total blocks: 0; free: 0.00%; learned: 1128; users: 1; languages: 0 Is it possible to have info on this until the manual will be updated with rspamd stuff? Because is think that in some ways the train wrong the bayes value. thank you just for context: without the footer text on the mail that you can see on the screenshot we receive BAYES_SPAM 0.2, with that text on the footer the BAYES_SPAM goes up to 5+ point. Something wrong is almost sure to me.
ISPConfig does not do this learning and email classification, so it's not part of the ISPConfig manual anyway. Spam/Ham learning is done by Rspamd on its own. See: https://rspamd.com/doc/configuration/statistic.html The only thing that ISPConfig configures is the Redis login and the standard ham/spam learn level /usr/local/ispconfig/server/conf/rspamd_classifier-bayes.conf.master which gets written to /etc/rspamd/local.d/classifier-bayes.conf
