Ok, TBH I didn't get the "bare/root domain" comment in the first place. For autoconfiguration of mail clients you need these configurations: https://docs.iredmail.org/iredmail-easy.autoconfig.autodiscover.html
as cloudron has control over the NS of the domains hosted we can set these entries (unless they are set already, then we should warn the user) and we can create the nginx docker container serving the autodiscover.xml.
Am I missing something?
ok, but you have such a polished email system - should this not happen automatically?
Ok, here with a newly added domain it doesn't work. There are no DNS entries been set in cloudflare (in this case), so thunderbird tries to "guess" in my case (and fails).
I feel you, try creating accounts with unusual settings, the UI wildly changes entered values when pressing save or test buttons, a true maniac must have designed it.
anyways, the devs should know?
As I only find a very old thread - is mail client autoconfig (thunderbird/outlook etc.) implemented yet or do we still need to do this manually?
ok, is this still on a roadmap? I could set up loki and promtail on a seperate docker server, but really would like to have this integrated into cloudron..
it's a one off thing, but preferrable within a script (so it should resolve the local container-id by hostname)
we want to use this in a script which runs locally on the cloudron server - what would be the preferred way here?
for an import script I want to run a bash command inside a (here: nextcloud..) container. This instruction to identify the container from the hostname doesn't seem to work anymore:
https://forum.cloudron.io/post/2011
what's the current approach?
@nebulon ok, not that many requests 
- any chance to do it anyway? I have no real clue how long something like this takes but it would open quite a lot of possibilities for my tiny hosting business as all our domains are at InternetX. For instance we have a DIY multi client nextcloud server based on docker which we would love to move to cloudron. And InternetX is quite big in Germany, may attract some business..
@nebulon I was maybe not clear enough, the feature request is for sending out an HTTP request when a backup is successful, not reacting to an API request.
We like to monitor our backups with healthchecks.io. The principle behind this is, that you not send an email when an email fails which leaves you in deep water, when, for whatever reason, the mail doesn't arrive/is not seen. Instead you send an email or ping a specific URL at https://healthchecks.io/ when a backup was successful. You then ask healthchecks.io to send you an email if there was no successful backup for X days (and you can manually check the panel there for failed backups).
It should be quite easy to implement.
@nebulon ok, I am an admin and wouldn't want to inject my limited hacking skills into your code - but, as the test just seems to access the nextcloud app URL it would help if you could add ../apps/mail/box/priority as a test to see that nothing crashes and we would risk to roll this out into production (I think as @WiseMetalhead that these featured apps are fairly stable and you don't do too much to the nextcloud code in your repo, do you?)
@nebulon ok and thanks for the clarifications. Everything was quite my understanding of the situation and the reason for the feature request. As email is such an important part of an integrated solution, mayby you can support (and test pre-release) the nextcloud mail app as you test the other mailapps integrated into cloudron itself?
Basically make it a "supported cloudron app".
@WiseMetalhead Says who?
The official cloudron demo warns here to not install nextcloud apps. https://docs.cloudron.io/apps/nextcloud/#email
This is kind of fine for Rainloop etc. which are integrated (with differing perfection) into cloudron itself anyway.
But.. the Nextcloud Mail App has the label "Featured" and I think cloudron should think about supporting these featured apps.
If it is too much hassle to suppurt all featured apps, I am most interested in the Nextcloud Mail app. The reason is, that not that many cloudron admins will host mail accounts on their cloudron servers and only in this configuration an almost seemless integration into cloudron is possible. All external mail needs to be manually configured in some ways before first use and my experience is, that most users are fine with this. For them it's more important, that the integration itself (after the first setup) is good, an as most users spend their time in nextcloud nowadays, it appears, it's much more natural for them to have the mailclient inside nextcloud as well (although the UI is, IMO, a crime).
hi,
any chance to get https://help.internetx.com/display/APIXMLDE/API-Grundlagen+JSON supported as DNS provider?
It's the backend for InternetX, AutoDNS, Schlund and maybe some other resellers.
Certifytheweb (letsencrypt frontend) supports it, so I think it should be doable.
@girish thanks, tried it this way and it works now.
