Good notes to follow up when we look into email in the next release.
IIRC, whitelist setting is a bit dangerous because it allows "spoofed" emails as it pretty much bypasses all the SPF/DMARC/DKIM checks. Meaning, Cloudron does not reject mail if those checks do not pass because there are too many misconfigured mail servers out there. Instead we tag the failures and allow spamassassin to score the rules. whitelisting makes spamassassin bypass the checks altogether.
@d19dotca Ah good point about editing those files. In the next release, I am hoping to make the filemanager be able to edit mail data (so admins can setup sieve rules etc for a mailbox), so this will atleast partly fix that issue.
@necrevistonnezr True, but imapfilter ( or another workaround ) is here today for you to achieve what you want. Beats waiting for the feature you're asking for which might be available sometime soon, later .... or never.
Mystery solved; The server i was hosting Afterlogic on turns out is just too slow. Checking the logs it would always time out, which is 15 seconds.
I ran Afterlogic on a much faster server and now it sends emails just fine.
Thanks all for your efforts to help me, it was much appreciated.
A bit of a wild guess: mail from is usually <> for bounce mail. So, this seems like some poor denial of service or maybe those IPs know that some mail software misbehaves with such carefully crafted mail.
Ah very interesting, I appreciate that insight. It was definitely strange when I saw it happening - so many requests at once. I'll keep an eye out for it. Sounds like it's all good then as far as Cloudron is concerned. 🙂 Thanks Girish.
Okay... I may be on the side of this working properly again. lol. Maybe I've been wrong this whole time in thinking it wasn't working correctly.
So coincidentally I was checking the mail server logs and saw another example of the same message go through to the same recipient from the same mail server, it was listed in the logs as "just now" so I quickly checked mxtoolbox and found that only 4 at that time had been listed, none of which were ones I was using.
Here is how it looked at the very moment I checked when it was "just now" in the logs:
Edit: Checking about 6 minutes later, I see the blocklists have aleady been updated for more (Spamhaus Zen in this case would have caught it if it were about 5 minutes earlier):
So I guess we can probably mark this as resolved, as I now see conclusive evidence that the various blocklists used just didn't have it listed until a few minutes after the message was received. I guess in order for it to adapt so quickly this spam attack on one of my users from those mail servers must be right at the beginning of a spam wave. Kind of neat actually to see how real-time these lists are. haha.