New GUI for docker-mailserver – Invitation to Collaborate!

[dunaj-dev]

New GUI for docker-mailserver – Invitation to Collaborate!

Hello docker-mailserver community!

First of all, I would like to express my sincere gratitude to the creators of docker-mailserver for developing such a wonderful and powerful tool! Thanks to your hard work, we can enjoy a stable and reliable mail server.

I would like to share with you information about a new project I have created: GUI for docker-mailserver (https://github.com/dunaj-dev/docker-mailserver-GUI). It is a graphical user interface designed to simplify the management of mail servers based on docker-mailserver.

What is docker-mailserver-GUI?

docker-mailserver-GUI is an intuitive web interface that allows you to:

• Manage user accounts
• Configure aliases ️
• Monitor server status

Important: The project is in its early stages of development. Currently, user account management, alias configuration, and server status monitoring features are available. My goal, however, is to eventually have the application cover 100% of docker-mailserver's configuration capabilities.

Why did I create this?

As a docker-mailserver user, I noticed that managing the server from the command line can be time-consuming and complex, especially for those new to Docker and mail servers. Therefore, I decided to create a GUI that would simplify this process and make it more accessible.

Invitation to Collaborate

The project is under development and I welcome any feedback, suggestions, and assistance in its development. If you are interested in collaborating, you can:

• Report bugs and suggestions via GitHub Issues
• Submit pull requests with fixes and new features ✨
• Share your opinions and ideas

I believe that together we can create a tool that will be useful for the entire docker-mailserver community.

How to get started?

1. Visit the project repository on GitHub: https://github.com/dunaj-dev/docker-mailserver-GUI
2. Review the documentation and installation instructions
3. Try out the GUI and share your feedback!

Thank you for your attention, and I hope docker-mailserver-GUI will be helpful to you!

Best regards,
DunajDev

Additional information ℹ️

• Screenshots or a short video demonstrating the GUI ️
  • 
  • 
  • 

[audioscavenger]

okay I tried, thanks. here are my remarks:

• "no need for network": really? and how do you access it from your swag proxy? yes a network is needed for the proxy access
• your docker documentation says use port 80 but it actually listens on 3001
• i don't think my cpu usage is 343%

• it found all my aliases, nice!
• it shows 0 email account but I have 7
• New major version of npm available! 10.8.2 -> 11.6.0
• those values are wrong by default:

• I updated them and saved, but they are not retained
• I used DOCKER_CONTAINER: dms in my compose but does not seem to be used at all

hope that helps! good start!!!

[JPRauwolf]

@audioscavenger
between the CLAUDE.md file in the root directory, the documentation that says different things than it does, the replys in AI speak You are absolutely right, this whole repo seems to be 100% AI slop. sad, I like the idea, but just the point that it is using the docker socket to interface with the mailserver is a no go

[polarathene]

just the point that it is using the docker socket to interface with the mailserver is a no go

That shouldn't be a deal breaker if you have a socket proxy to restrict what can be done.

It isn't necessary though if a small API service is added to the DMS image (by extending it or mounting a binary + config). If needing to secure access from any other container within that network, then it'd be better to offer the API over a unix socket with a shared volume rather than HTTP/S.

It would be fairly straight-forward to distribute a complimentary compose.dms-ui.yaml that extends the primary compose.yaml. That'd provide a more secure approach over docker socket access if preferred, and should require minimal changes to use.

---

Regarding the AI commentary, as someone that has often been accused of using AI when I write my messages when I absolutely do not, and being familiar enough with AI generated text mannerisms, it definitely does look like @dunaj-dev responded with AI tooling rather than personally engaging 😓 (@dunaj-dev I'd discourage you from doing that, it may seem convenient but will risk losing trust / reputation from peers)

I've not looked at the repo myself. AI assisted dev is okay if the dev understands what they're doing properly, but my experiences when contributors create pull requests that I review personally is that's often no the case 😞

For entire projects reliant upon it, I'd generally steer clear unless it can be run isolated/securely.

[dunaj-dev]

@audioscavenger between the CLAUDE.md file in the root directory, the documentation that says different things than it does, the replys in AI speak You are absolutely right, this whole repo seems to be 100% AI slop. sad, I like the idea, but just the point that it is using the docker socket to interface with the mailserver is a no go

"You're absolutely right!" I did use AI to create that tool; I never claimed to have written it 100% myself. 😉 The core idea was mine, though.

The CLAUDE.md file is indeed deprecated because I switched to a different AI model.

This whole project has two main goals for me:

To force myself to build something more complex than a simple function using AI tools, and to check if it's even possible.

To create something I will actually use myself.

Regarding my solution using the Docker socket to communicate with DMS: it was the first idea that came to me when I was trying to create a GUI for a CLI-handled application. Also, I only had a few hours to do a POC and check if this approach would work. Since it did, I left it as it was.

just the point that it is using the docker socket to interface with the mailserver is a no go

That shouldn't be a deal breaker if you have a socket proxy to restrict what can be done.

It isn't necessary though if a small API service is added to the DMS image (by extending it or mounting a binary + config). If needing to secure access from any other container within that network, then it'd be better to offer the API over a unix socket with a shared volume rather than HTTP/S.

It would be fairly straight-forward to distribute a complimentary compose.dms-ui.yaml that extends the primary compose.yaml. That'd provide a more secure approach over docker socket access if preferred, and should require minimal changes to use.

Regarding the AI commentary, as someone that has often been accused of using AI when I write my messages when I absolutely do not, and being familiar enough with AI generated text mannerisms, it definitely does look like @dunaj-dev responded with AI tooling rather than personally engaging 😓 (@dunaj-dev I'd discourage you from doing that, it may seem convenient but will risk losing trust / reputation from peers)

I've not looked at the repo myself. AI assisted dev is okay if the dev understands what they're doing properly, but my experiences when contributors create pull requests that I review personally is that's often no the case 😞

For entire projects reliant upon it, I'd generally steer clear unless it can be run isolated/securely.

I think creating a small API that could be enabled by some flag in Docker Compose will be the best solution going forward. First of all, it will be much faster and more responsive, and many of the CLI output parsing issues will be gone.

I am on board with adopting a more secure approach, but I don't quite get at this time what you mean by 'API over a unix socket with a shared volume' in this context. Could you elaborate on how that setup would function in a typical Docker Compose environment? I'll be searching for information on this approach myself to understand it better, but if you happen to have a good article handy, that would be greatly appreciated!

[polarathene]

Quick answer is a standard HTTP API service, but the listener is binded with UDS (a special type of file) instead of TCP (network socket). Instead of connecting the two containers via a network for API access, you'd share that file via a volume.

---

I am on board with adopting a more secure approach, but I don't quite get at this time what you mean by 'API over a unix socket with a shared volume' in this context.

You can have your service (or a reverse proxy) listen on a unix socket (file that can be shared between containers through a common volume) rather than a TCP socket (network ip + port).

I have a WIP project that I didn't quite finish getting around to polishing up and publishing on Github, but it was effectively a Caddy version of the HAProxy or Nginx Docker socket proxy projects (I personally think mine did it better though, along with the unix socket approach).

If your API service can directly listen/bind to a unix domain socket (UDS), then it should still be able to receive the same routes and HTTP requests through that file, and your security for access then becomes the files permissions and whatever can access that. Much like how it works with the Docker Socket API you commonly see with volume mounting to share that into containers that need to integrate with that API, only you'd be using a volume between two containers instead of host to container sharing.

The volume can be a bind mount volume, or it could just be a named volume (keeping it self-contained within the compose project since there isn't much value in a bind mount volume for this). With a named volume, it should be simpler for any user as they don't have to really understand the details of all this, and if they do want to there's probably less concern?

You could use the default compose.override.yaml (I think that's the default override name) to distribute your container and required compose additions besides the DMS compose.yaml, which would keep a nice clean separation. If users want to they could merge that into a single compose.yaml (or running docker compose config should output the final resolved compose.yaml IIRC), they'd probably only need to change the service name should that differ for some reason. Then that's it for setup, everything is self-contained, so they just copy that file from your repo beside their DMS compose.yaml and run the usual docker compose up -d --force-recreate and now your API service is up and running (separate container running your GUI with backend ports for the browser + executable and service added to DMS to auto-run a local API service in DMS to do whatever is needed via unix socket access).

I could put together a rough example for you to reference if I can find the time over the next few days perhaps if that'd be helpful to understanding it better? (I'm not the best at explaining this stuff 😅)

---

I'll be searching for information on this approach myself to understand it better, but if you happen to have a good article handy, that would be greatly appreciated!

I'm not sure how well this sort of thing is talked about out there. So you might not find much in tutorials or AI assistance (at least my experience with AI tooling is it can fumble when things are too niche). We're looking roughly at the following:

• An API service that is accessible via a unix domain socket, much like the Docker API is by default (it can offer web with TLS, and you could layer security there for further access control).
  • This is otherwise just like a typical web API service, and you've already got your project interacting with the Docker API over UDS, so it'd be very much like that.
  • Only difference is access control is via a file (that your API service would create upon binding the listener, so far I've only done this with Caddy which handled creation/removal implicitly when started/stopped, and I had that forward queries to the UDS over to an HTTP backend service at another container). A named volume will work well here. For added security you would want to limit access to your service user/group when creating the file.
  • To add this binary to the DMS container without also bind mounting an external file, I believe there is support to volume mount from images now (possibly landed in the past year or so? so this would raise your minimum Docker Compose supported version to mention in the docs). If your API service is reliant on NodeJS or Python, both do have some tooling out there for packaging a single executable IIRC (deno for NodeJS, and few options for Python projects like PyInstaller IIRC)
• compose.override.yaml should be documented well enough to sort out. Only part you might have trouble with is DMS specific if you want your UDS service automatically started. We presently use supervisord to manage services and we load any of the service configs in it's config directory, IIRC you should only need to copy/paste one of those service configs to mount as your own file and have it enable autostart and that should be sorted 👍 (bonus, use the Docker Compsoe configs content feature to inline this config file into your compose override, and it'll remain self-contained in that same YAML file).

All that said, Docker API via socket is fine too but users should be leveraging a proxy service for those to minimize what your container can do with that API access. However since your service is more bespoke, requiring write API access to execute anything in any container is probably a big ask that will not sit well. Full access into the DMS container only via the alternative approach I mentioned should be more comfortable to trust your software on their systems, and avoids the issue with ports based access (without added security to control access, any other service able to reach that container port and knows the API could do some potential damage if there was a compromise) minimizing risk via UDS based access (simpler to secure).

---

I'd like to eventually have this UDS API service officially in DMS at some point, but that is probably some time off. It would be written in Rust due to two active DMS maintainers preferring that language. So if you build out something similar (any language), it may provide a good reference of what works well (and any lessons learned along the way). It'd also reduce maintenance burden for projects like yours, should breaking changes happen to any configs for example, you wouldn't have to worry so much compatibility wise going forward.

Rust aside, Caddy can provide the unix socket access quite easily, and there is a Caddy plugin for executing commands, so a custom build of the caddy binary could be done (xcaddy build makes this simple and can be part of CI / Dockerfile). If you just want to run commands instead of your own code within the DMS container, this could also be an option that might work well for you.

[polarathene]

@dunaj-dev you were interested in examples/references, I have recently provided a full example that you can try.

That shows a JS client (Deno instead of NodeJS) interacting with a web service that maps HTTP requests (received on a unix socket instead of TCP port) to CLI commands.

For additional reference I also put together this example earlier which was a bit more involved.

Neither has touched the actual CLI to make it more appropriate for API responses to consume however. I don't know when I'd find time to refactor that 😓

[audioscavenger]

are you redeveloping mailu UI just for us? maybe I'll participate if you like

[dunaj-dev]

Thanks for asking!

I started this project primarily for myself because I prefer using a user interface over a complex command line. docker-mailserver is a powerful tool, but managing it can be a challenge, especially for those who aren't command-line experts.

My goal was to build a tool that simplifies and speeds up everyday tasks, making docker-mailserver more accessible to a wider audience.

I'm really glad you're interested in participating! This is an open-source project, and it's being developed with the community in mind. Any help is greatly appreciated. You can start by sharing your ideas in the Issues section, and if you feel like it, pull requests are always welcome! Together, we can create a really useful tool.