I have incoming emails going in parallel to both SA and rspamd so I can observe them. It is a small subset of a few email accounts going to the rspam zimbra instance. This gives me a way to observe the same message and how zimbra with SA and zimbra rspamd interact. A few comments less than 24 hours into this.
* Less CPU for rspamd but more context switches (approx 20% perhaps more)
* A lot more of ESTABLISHED local port 53 connections... Saw over 900 since I installed in Aug 1 just leaving the software running with no incoming email but I updated the software and it's stable for the last 24 hours. Just under 100.
* a Zimbra rspamd has approx 2x the number of ESTABLISHED system connections vs the default Zimbra SA
* overall combined memory foot print of zimbra+rspamd instance is slightly larger but not willing to commit to this yet
* Note: I haven't tuned this at all and just used Bill's howto from this thread
* The gui is fairly impressive as is the ability to customize the software
* Feels like the default spam rules are very fast (ridiculously fast) but not very sophisticated in comparison to our SA environment
As far as spam detection, it is not better yet nor close but that comparison is unfair given I have no idea what is going on and I have extensively tuned SA for our spam mix. I also haven't been able to figure out how to make it view the next hop which is critically important given how I am using it for this test system. In general, it would be better for my test system run this on my front-end MX's instead of on the zimbra instances as I think it really wants to be on the front end MTA to do the rejects and bounce it back to the spammer, etc. I was very happy to see the ASN module as I have something similar in my front-end MX's that add headers for SA to use downstream. Also, if your users are sensitive to missed email because of DMARC reject policy (caused by inexperienced senders or mailing lists, etc) then you need to change this behavior as the sender will get bounces back that their email is junk. This problem exists with SA also in a slightly different way so I mention it as reminder for those that have changed this behavior with SA by lowering that rules score.
It feels like this could be a replacement for SA but it's evolving fast (really fast!!!) and some of the ways that dynamic maps are implement has me wondering about security attacks given that we have seen some forged DNS resolver's queries in some data centers. I am probably wrong on this but there is a lot of ways to modify the software on the fly and hackers have a way of finding ways into these input streams causing unexpected behaviors. I like it but not even 24 hours of actual use yet so more questions than answers at this point. I reserve the right to remove this statement in the future if/when I am wrong... hahahahaha
BTW, I would recommend anyone wanting to evaluate this to update local.d/metrics.conf and change the reject score higher so you can see the messages and observe the rspam spam headers. Because this configuration we are testing in this thread appears to want to be on the same machine as zimbra; if you have front-end's passing email be on the lookout for the bounce backs in your outgoing mail queues. Again, a higher REJECT score for actions can prevent this while you gain operational experience with the software. I am so new at this, I don't really understand what is going on but it feels fast, flexible, and is a welcome new spam detection engine IMHO. Here is what rspamd says for SA users migrating.
https://www.rspamd.com/doc/tutorials/migrate_sa.html ... There has been a lot of focus on performance so detection should eventually catch up as more systems deploying this and send in their improvements.
If you are looking for a no configuration option with SA or rspamd... I don't know. There are some sophisticated techniques out there and a few blacklists with overly simple body checks don't work well in all envioronments. That the professional senders (ie. mailchimp, etc) are in most of our whitelists in conjunction with providing their customers test tools to verify their payloads against spam detection software is a significant part of the problem we are facing. The best hedge is to customize your rules for your spam so that your statistical methods like bayes and these rules offer more help for this type of problem. It would be interesting if rspamd and its experimental neural network module
https://www.rspamd.com/doc/modules/fann.html could allow us to decentralize some of analysis but frankly, I have no idea what the possibilities are with it at this point in time.
Jim