Cloudron Forum

@marcusquinn I think DNS automation (provider specific) atleast needs to come from elasticemail itself ideally. It's not possible to keep track of all the DNS records each provider wants to set and if it's even available with API. It's basically impossible to test on our side atleast.

@girish Yes I did, and the problem with the certificates is now fixed. Thank you!

@jdaviescoates Yeah, removed it from our code for the next release. 5.5 should be out next week.

I've added a task in gitlab for this now at https://git.cloudron.io/cloudron/box/-/issues/738

This is implemented in Cloudron 6 ! https://forum.cloudron.io/topic/3205/what-s-coming-in-6-0-take-2/99

@austinsonger Is the server also hosted in Azure? PTR records are not part of your DNS zone. They should instead be set from wherever your server is hosted (i.e whoever owns the IP address of the server) It seem Azure does not have a UI to set PTR records but you have to use the CLI - https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services . What you are trying to do is https://docs.microsoft.com/en-us/azure/dns/dns-reverse-dns-hosting I think, this is not what we want. Quite confusing from Azure. Tagging @derek since he knows Azure stuff.

@girish That would be ideal! In fact if that can come in the next couple of months, I'll hold off my own DNS change until that's there. Because the whole "my." doesn't really conform to the standards that people expect when they need to enter in their server names for a mail server. I'd definitely love if Cloudron could use it's own "mail" subdomain and it's own certificate for the mail server portion so that I can still have clients connect to mail.<domain>.<tld> without impact since that's what I have told a dozen or so to do already over the last 1.5 years. And no, the decision wasn't anything to do with Cloudron or DigitalOcean really. My main reason for the move away from DigitalOcean isn't anything to do with Cloudron or DigitalOcean. If you're curious... the decision was mostly for two reasons: A movement from both myself and my clients to keep everything (as much as possible) in Canada. And my current DNS provider (LunaNode) has their infrastructure in Canada only (well France too, I believe). It's one of those "shop local" sort of things. The DNS provider I currently use has a great feature that I can take advantage of in the future when running a secondary Cloudron server as a mirror image of the first one (waiting for that clustering capabilities in the future, hint hint haha). The advantage is that they have monitoring tools I can use, and based on those monitoring tools they can automatically update DNS records to the other IP address if monitoring detects one of the servers as "down" for whatever reason. To me this is like the health checks in load balancing, but I don't have to pay for load balancing with this solution. I see this as a further advantage to using LunaNode for the DNS management. So yeah, nothing to do with Cloudron or DigitalOcean really, so no worries there. Just a decision made for various reasons (the biggest two above, but also a bit of my own OCD and others haha). I will keep my primary domain on DigitalOcean then for now if you think the SSL cert for the mail subdomain would arrive in the next couple of months. Because I think that's a fantastic idea, and I think that was something I mentioned or questioned back when I started using Cloudron because I was so surprised that it had to be "my." as that's not something that conforms to the standards of mail server hostnames, and I wanted to keep things more standard for my clients to avoid having to explain non-standard implementations. I say standard loosely here as I realize there's no official standard, but it's more a de-facto one that mail. is the subdomain to use, or imap., etc. Hope that helps.

If this is disabled or archived, this also means that it is still "known" to the system, currently the data simply is not removed from the disk, but other relevant information is purged from the database. So I agree, that deleting an account should also delete the mailbox data, if there is no proper way to restore that (currently you have to create a new mailbox record with the same mailbox handle and magically the data comes back). For that some archived state could be the solution to have a structured way to restore.

@girish much appreciated... thanks for looking into it!

Yeah, we made changes specifically to preserve the mail from. If you find that it doesn't work, please report back.

I made a copy of my profile folder and upgraded. My Mail Accounts were visible in settings but not in the folder pane(?). Reverted as I did not have time to dive deeper into the issue. Also, the TbSync Addon is only in beta for 78, though apparently they are working with staff to get it integrated like Lightning.

Awesome this got resolved on it's own

@marcusquinn Thanks for the info!

@Mastadamus said in Seeking recommendations based on experience for Sendmail Relays: Mailgun seems like a better deal for those not using a massive amount of emails a month. Yeah, they are the only one I've tried because you have to use it for Ghost newsletters. But I've never paid anything for it because you can send up to 5000 emails a month for free and I don't send anywhere like that amount.

Indeed, currently catch-all has to have the feature to set mailboxes across domains (like aliases).

@necrevistonnezr Great questions! I'm still pondering this myself, but got delayed with some other projects. I don't have an HA setup yet, but I'd assume the easiest way to achieve it may be to duplicate the server (i.e. restore Cloudron backup on a new server), then use rsync to keep them in sync on the boxdata directory for example, then use DNS for failover where the MX server address on the other server can be used with a higher weight to be last in the selection and thus only used if the first MX server isn't responding. Just my initial two cents anyways, but haven't thought it out thoroughly yet. Will probably give it more thought once the Cloudron multi-server management feature is in-place as it may make things a little bit easier.

@edapm Personally, I'm all-in with Hetzner, not free but the best value for features I've found, particularly having network DDoS protection as standard. Others recommended include Contabo and Scaleway. If you're getting free (inclusive) stuff from Microsoft then I suppose that's decent. Personally, I'm all GitLab, so anything GitHub is second-choice. I guess there's nothing truly free, including your time, but those are the options I recommend, otherwise it's support tickets to Azure and hope for their ability to allow for port needs.

Woah; Now I understand why so much user end by not using KMail (if you are curious look at KDE forum and Reddit for KMail issue) Basically @girish you were on the right track simply I had to go a little bit deeper instead of looking under identities (because, of course, my Identity was well configured) the issue is located under the sending configuration where you have to declare the mail email (not the alias even if my test is not with the alias.) [image: 1593673080925-9b78073a-ff99-4158-acb0-011f3f510209-image-resized.png] Anyway thanks for your help!

BTW, for the "dot" thing, the mailbox separator in Cloudron is ".". This is why folders with dot don't work. If you create a folder named "foo.bar.baz", it is like subfolder bar under foo and subfolder baz under bar. While using "." as a seperator is not a bug as such, using "/" as a separator instead of "." would have been a better choice for Cloudron but we didn't know this when we started (sadly, "." is the dovecot default too). And also using "/" as separator is required for mailbox sharing to work. We are slowly working towards moving the separator to be "/", step by step.

https://help.nexcess.net/77209-third-party-email-clients/how-to-allow-outlook-to-connect-over-tls-1112 has the registry instructions.