Better domain management

[tognee]

Currently domains are checked based on the users emails registered and there are no settings to manage them.

I want to make a PR to add this feature.

My proposal:

• Add to the DB a new table for domains.
• Add the option to disable web hosting and A/AAAA records check on single domains
• Edit the user creation form to add a drop-down to choose which domain the user generated should use
• Edit the interface components about domains to reflect the changes made

I'm making this issue to see if the PR could be considered for merging when submitted.

[JoshData]

I would accept that. It's something I've wanted to do.

The main thing I would want to discuss more is "Add the option to disable web hosting and A/AAAA records check on single domains":

• Disabling web hosting is frequently asked for, but it's not exactly a sensible request. If the domain has an A record that points to the box, then the box has to respond to web requests. It can't not respond since it's already listening on its IP address for all of the other websites (including the admin). If the user sets a custom A record pointing elsewhere, or is using External DNS and sets an A record pointing elsewhere, then it doesn't matter if the box is configured to do web hosting for that domain.
• I would like to talk through what exactly would be disabled with different settings for the domain.
• I'd like to discuss the database table schema so that we get something that is easy to maintain for the future.

But these don't have to stop you from starting.

[tognee]

Hi, thanks for your kind response

Database table schema:
Currently I've added a domains table with the fields domain and options. I've modelled the options field to work as the privileges fields in the table users. The options in options act as a boolean value, true if present and false if not. There is only one option for now, no-web that should do what I described in the OP.

What will be disabled:
Let's make an example with a domain example.com.

• box.example.com - box domain
• example.com - primary domain
• anotherexample.com - secondary domain

box.example.com can't enable this option as it's needed to show the admin panel, the webmail and nextcloud.
example.com and anotherexample.com can enable this option.

This option will:

• skip creating the servers on nginx for the root and www subdomains
• remove the entries from the DNS
• hide and skip the checks for the A and AAAA records on root and www subdomains
• hide the actions in the SSL certificates panel and the web panels for the root and www subdomains

As for the why:
The secondary domain is not connected via glue nameservers so the web hosting could be on another server. The primary domain should have an option to disable the web hosting if the box is using an external DNS without glue records or the user doesn't want to host a static website and wants to use their own server with their own instance of nginx. When using glue records the user could still remove the web server and add A AAAA or even CNAME records using the Custom DNS panel already present in the admin.

If any point is not clear enough let me know and I'll try to explain it better.

[test2a]

@JoshData similar to what tognee said, i want box.example.com to be the email server but example.com to be a different IP. is it possible to do that? i see an entry in external dns file example.com - box.example.com. how do i decouple box and primary domain?

[JoshData]

@test2a What you want is possible and not really related to this discussion. Please ask on the forum for help.

[tognee]

I've made some work on this feature on my own branch. It's still not ready for merging and development is proceeding slow as I need to destroy the VM and rebuild it every time I make a change (which takes quite a while).

https://github.com/tognee/mailinabox/tree/feat/domains

I might create a draft pull request when I get it working like I intended

[tognee]

Update: Finally got some time to work on this. I implemented the backend, but I still need to do some more testing before opening a PR.

As for the frontend I saw that everything is managed using vanilla js + jquery. I had the idea to rewrite some chunks of it using Alpine.js. This would help new developers easily extend the UI and provide a better dev expirience overall.

If I get a "go ahead" on this I could add the domains frontend in Alpine and then refactor the current pages, otherwise I'll make the domains frontend with the current tech stack, let me know :+1:

[JoshData]

I had the idea to rewrite some chunks of it using Alpine.js.

Every additional complication reduces the likelihood that I will make enough time to review it.