Personally, I'm migrating away from GMail, and wouldn't recommend it, although I appreciate it's difficult to cut those ties for some.

Another possible solution: would be to forward to any other email service that does support POP3 but doesn't have spam filtering. That way, you're not sending email to GMail, it's pulling and filtering. Appreciate that a 3 mailserver setup is odd though, but then so is GMail.

I think it's worth just having a POP3 post in Feature Requests though, purely as a way to allow for any other 3rd party email someone wanted to do this with. I can see privacy advantages in POP3 as well, if one didn't want emails stored on their Cloudron and just locally. I wouldn't like to see POP3 ignored as without advantage, when if privacy is a concern, that could be a legitimate use-case.

I use a browser extension that removes all those as well as utm link data.

@d19dotca I will try to reproduce this, it's in my TODO list.

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

@necrevistonnezr said in How does spam work with special mail folders?:

@girish Wouldn't it make sense to create hardlinks instead of symlinks for these folders so that you don't have duplicate folders? Ar am I overlooking something?

The cloudron backup logic does not understand hardlinks. It would then end up taking backup of your junk folder twice. This is unlike symlinks which is ignored by the backup code. Neither the symlink nor the contents of a symlink are backed up.

This does bring up an important point that if you move your mail server to a different server, you have to remember to create this symlink by hand again!