The fact that Test emails out of my cloudron admin panel were successfully sent and the reply from my other website email was received back DOES THIS MEAN that the 3 email ports in my Linode instance are already OPEN?
I think this is most likely the case. The email was sent straight from your Cloudron server, this means linode opened up the ports.
@girish Hi there. Thanks for checking into this for me.
I had a suspicion that the spam engine was verifying, since I did see those fields in the Spam results headers. However I think it's also useful to have Haraka add the headers as well. It would add very little overhead and will add additional detail that the spam header doesn't contain about the DKIM verification (such as which signature failed or passed, since an email can contain multiple).
In regards to DMARC. I don't believe this would be risky at all if implemented in the following manner:
No DMARC record found, take no action.
DMARC found, DKIM/SPF aligned, take no action
DMARC found, DKIM/SPF alignment fails, but p=none, take no action.
DMARC found, DKIM/SPF alignment fails, but p=quarantine, move to spam folder
DMARC found, DKIM/SPF alignment fails, p=reject, dev/null the mail. If you don't like the risk of this, push it to spam instead... or make it a cloudron option under Settings.
@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.