@artd2019 Currently Cloudron does not offer (a documented) "whitelist" / "allow list" function, so there is no way to guarantee deliverability of an incoming email. There is a feature request for it already that I'd encourage you to upvote. Version 6.3 coming in the not too distant future is supposed to deliver on many of the email improvements users have been clamouring for (including myself).
One thing you can do if you're not already is making sure to remove those emails from the Junk / Spam folder in order for SpamAssassin to unlearn the message as spam. Eventually after a sufficient number of them, it'll learn that those emails are not spam and will decrease the BAYES probability of it being spam.
On a related topic, you may want to consider enhancing your SpamAssassin rules list from the defaults, specifically in your case the BAYES_## rules perhaps as I have offered previously in this forum.
Thing is some apps store the email (just like they store username) in the database. This means that when you change the email in Cloudron, it doesn't change in the app (depends on the app). So, just to keep things easier across apps, we decided to keep login username based as much as possible (since in Cloudron, you cannot change the username, we don't have a problem).
Can you clarify what you mean by "it says"? Is there some error/warning somewhere? Also, I assume that you have put a custom domain in fastmail and also fastmail is able to relay mail as any email address i.e <anything>@domain.com ?
@d19dotca Sadly, they do match. I'm guessing it's something with my current setup that's acting funny. I'll ignore it for now since I plan on migrating either to the new Contabo server that I got or upgrading my current one at DO to Ubuntu 20.04. I just thought it was a wrong setting on my part.
Thank you for looking into this and for sharing the custom spam rules! I know you've put a lot of time into that 👍
@d19dotca since we had some recent timeout issue with the services view (and mail being a service here) it could be that also here the mail container or the server overall is busy during that time and thus the search queries timeout. If you see this happening again, a look into the system/box logs as well as mail service logs should reveal this then.
For reference, Haraka has a greylisting function built in: http://haraka.github.io/plugins/greylist/ - and it works with the DNSWL / whitelist which we should enable too. That way if an IP is on the DNSWL, it automatically skips any greylisting attributes.
If it was random, I was afraid there is still a possibility that they can conflict across servers
Great point - that makes sense. Thanks Girish.
Side note: I think it'd still be great for the OCD in some of us to be able to regenerate the DKIM record on demand so it not only follows the new hostname pattern in Cloudron but also generates a new key if desired too.
Like can there be a memory within cloudron of all subdomains used and when it comes time to renew, just renew it on all of those subdomains?
That's the current behavior. It only renews domains that are in use in Cloudron. AFAIK, there is no way to tell Let's Encrypt to "forget a subdomain" that we had gotten a certificate before. This is the reason why you get the reminder emails from Let's Encrypt about old domains.
I really like the blackllist checking being built-in. Frankly, I'd also be a fan of getting notifications about it. I suppose UX-wise, perhaps this is the appropriate sort of thing to trigger a yellow status on email.
The root cause for this was the Cloudron server had the hostname as "box.domain.com" (same as the relay). Debian/Ubuntu has a quirk that it will put the hostname in /etc/hosts to resolve as 127.0.1.1. This meant that when we try to set it as relay, it resolves to 127.0.1.1 instead of the actual IP.
To add to the confusion, I suggested using the host command which does not use /etc/hosts (i.e the nsswitch mechanisms) and uses only the DNS. If I had suggested using ping then we would have narrowed down the issue more quickly...
Anyway, the fix is simply to hostnamectl set-hostname somethingelse.domain.com and also edit /etc/hosts (for some reason, hostnamectl doesn't change hosts file even after reboot, 🤷 ).