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, 🤷 ).
@girish Yes, I guess the email from my Cloudron domain is getting flagged as spam on their side, and then they reply to me without removing it from the Subject line. Ok, I'll get in touch with them and figure things out. As far as I know, I've done all I should to legitimize my cloudron domain - they use a provincial ISP for the email so I suspect they are picky.
@necrevistonnezr I noticed the first time enabling it,it has to index each mailbox which takes time depending on how big they are. I am sure if you left it as-is for a bit it would have started on it's own.