@girish said in Spam filter doesn't always learn: rspamd is better here but it does require more resources rspamd require less training to work, and less complicated configuration setup. but without clamav is pretty much equal to spamassasin with a little bit of training, and tweak. AntiSpam in general are really havy to run, and complicated, if you take a plesk or cpanel antispam out of the box are similar to cloudron on. The only solution is to implement a more complete stack in general, with blacklist, signature, DNSBL in a collaborative way, so that every cloudron can report spam and especially ham. @imc67 if u want to manually improve you can add barracuda (b.barracudacentral.org) DNSBL to start. (this guide should work; backup your config file before edit it). The issue of cloudron are mostly resources, because an efficient antispam will take to much ram, and cpu, so we need to find alternative solution, and my company is try to help cloudron to improve on this.

OK, with @NCKNE 's help we got this figured out. Cloudron has a anti-spoof check where we don't allow external servers to send email with FROM address set to any incoming domain. In this case, a backup MX is relaying email to Cloudron and it is correctly detected as spoof-ed email. The workaround is to simply whitelist the MX's IP in the SPF record. With this Cloudron has the "authorization" that the server is allowed to relay such email and accepts the mail. I have added a section in our doc here - https://cloudron.io/documentation/email/#alternate-mx

@iamthefij Well the you can make it so you're not discoverable unless you message the person. Thats pretty anonymous

@d19dotca Currently, there is no way. The SA settings are set in stone. I can open up our mail addon git repo tomorrow so you can get a better idea of how we have implemented it. But overall, our idea was that customers don't have to deal with implementation details like SA (for example, maybe we use rspamd later) and that spam detection should just work. If you have SA expertise, I am happy to incorporate your suggestions into the default settings.

@girish I just wanted to add another reason why we need better spam control exposed to admins... I just had a client who had their home IP address blacklisted by Spamhaus in their PBL because of the range of IP it was found in, even though they were not spamming at all (since the PBL blocks IP ranges). I have asked for it to be delisted but it'd be awesome if in the future I could just whitelist the IP address or something like that to quickly resolve it for them. Update: Just found https://cloudron.io/documentation/email/#blacklist-domains-and-ips which is for blacklisting but I extrapolated from that and found the related whitelist files too, so used that. This needs to be added to the docs. I will see if I can submit that change in the git for you guys. With that said though, it'd still be nice to see this exposed in the UI so if an admin is on the road / unable to SSH to the server, it can be easily whitelisted still.

@d19dotca said in How does spam work with special mail folders?: I really think admins should have more control over this, such as setting up their own default folder list, for example, or the ability to mark multiple folders as '\Junk' and the ability to remove the Spam folder in favour of naming it Junk. I can get behind this. But I am quite practical about these things. There's nothing we can do to fix iOS and mac, so I am OK to even rename the folder to Junk if it increases compatibility. In the coming release (5.3), I have put some "state" information that will help us migrate to the release after. Existing installations can be on Spam and new installations can use Junk. I am doing the same for the mailbox separator. (moving things from . to / to make mailbox sharing work).