How do you deal with changing user passwords?

[s0ftcorn]

Since this great project started it has been for me amazing in almost every aspect. But a kinda ongoing problem is dealing with users changing their password.
There was stuff like https://github.com/docker-mailserver/docker-mailserver-admin started, but went nowhere. Hence this small poll.

[audioscavenger]

thanks for your interest in a GUI that offers what iRedmail and mailu offer. here is the one I am working on 4h+ a day for 2 weeks now
https://github.com/audioscavenger/dms-gui

[audioscavenger]

wow... thanks

1. i finally developed a python simple apy listener, that executes received commands (sent as json with api_key) and replies a json body with errorcode, stderr and stdout
2. you are right, the user-patches.sh hangs without a nohup + & when calling the python api server
3. the user-patches mount indeed has a flaw where some users do actually use it, therefore I cannot just tell them to replace it. Either they have to modify the DMS compose and this file too, or use a compose override i will provide, I don't know yet
4. I explored the unix socket idea briefly and I don't like it:
   a. I could not mount a socket file with just a volume in compose, there is more to it
   b. using it, I can separate stderr and stdout, but cannot get the errorcode any other way then by creating a file.errorcode and also read it back somehow; the exec process from node js is therefore too many separate steps: echo command into socket, wait, read 3 files
   c. how do you pass an API_KEY to the commands you echo into a unix socket file? zero security. file is also accessible from the docker host.
5. you caddy approach is (in my eyes) exactly the same principle as the python api listener, just some files to mount into DMS + 2 env variables (port 8888 and API_KEY) and a way to launch it at start. Since I provide all that's needed, it's just a matter of choosing what's easier for the end user to add to their DMS, and for me to maintain. I don't know yet, I need to test the caddy cgi thing. You gave ALL that you could so far, you went above and beyond, and therefore, I will try
6. some of your maintainers don't like python? it doesn't matter since dms-gui is the container injecting and maintaining the api (if i go that route) - as long as you embed python in DMS, indeed.
7. for the doveadm commands, I think all will go through the api even though I can already send some commands to doveadm api:8080 - i don't like splitting the work between different access points.
8. finally, I understand that I don't have to do any of this, as you are not in the process of looking for a GUI. I will do it anyways because it's fun and I need it. Then we'll see if some are interested

I read everything but now need to give a try to the caddy approach. will take some time but thanks again for all the advice

[polarathene]

4. I explored the unix socket idea briefly and I don't like it:
a. I could not mount a socket file with just a volume in compose, there is more to it

Your earlier example snippet wasn't using unix socket files but FIFO (aka named pipes).

I don't have much experience with named pipes, but Docker bind volume mounts aren't special to Docker it has whatever limitations a bind mount on the host would have. I have mentioned one of those to you regarding directly mounting a file vs the parent directory as any change that affects the inode of the file/folder mounted would encounter a problem scenario.

There is no equivalent command to mkfifo for unix sockets, but you can use software like netcat (or Python) as shown in that link.

In the examples I showed you, a volume (directory) is given to the container with Caddy to create the unix socket. From that I can provide a read-only mount to your DMS GUI container of just the file (although the directory is fine too in this case since it should be the only file exposed and will cause less trouble). If directly mounting the unix socket, you need to ensure it's already created upfront I think (might not be the case with Caddy if it's not run immediately when the container starts there could be a race condition even with the basic depends_on condition given to your DMS GUI container to defer it's own container start).

---

    b. using it, I can separate stderr and stdout, but cannot get the errorcode any other way then by creating a file.errorcode and also read it back somehow; the exec process from node js is therefore too many separate steps: echo command into socket, wait, read 3 files

See my example with Caddy that receives the HTTP request (either via TCP or unix socket, doesn't matter) and then calls the CGI script (bash in this case) to run the command and collect CLI output along with the correct exit status of the command. Since there was other steps required inbetween that required a bit more work to support but it does so correctly and could capture that into a JSON response if it was of any actual value than the 422 HTTP status I had it return.

There is no echo of a command into a socket or reading of extra files, whatever you were messing around with. Just have your HTTP API service (such as Caddy or Python) listen on TCP socket (IP/interface + port) or unix socket and then run a command (or script that does) and return a response as you see fit.

---

    c. how do you pass an API_KEY to the commands you echo into a unix socket file? zero security. file is also accessible from the docker host.

Sorry? I don't quite follow this question?

If you're using a unix socket, access to that is already all the authorization you need really. It's like with the Docker socket.

I had a volume that was used to share access to containers, in this case it's only DMS and your DMS GUI container involved, but I've also used this as a way to proxy the Docker socket itself with restricted access to many containers (where I can use different unix sockets to represent different access rights granted to a container).

You could include the need for an API key or similar in addition to that if you really wanted to (and I did document and demonstrate this in my prior response), but it shouldn't be necessary like it would be with TCP (which is far more accessible by default, thus needs an added layer for authorizing access).

Since this is an HTTP request to an HTTP API, the process is no different between TCP or unix sockets, these are just the transport that the request goes through to reach the API service that binds a listener to the socket type (TCP/unix). For unix sockets, your request isn't going through the network so there's no DNS resolution on a hostname or port to consider, nor firewalls/routing, etc... it's much simpler to manage and troubleshoot, you're just unfamiliar with it (it's also more secure in the sense that you're not accidentally exposing your private internal web service to any publicly accessible networks which some users do make the mistake of with containers default publishing to 0.0.0.0 or even not being aware that containers sharing the same network can reach each other directly without any port publishing required).

---

5. you caddy approach is (in my eyes) exactly the same principle as the python api listener, just some files to mount into DMS + 2 env variables (port 8888 and API_KEY) and a way to launch it at start.
Since I provide all that's needed, it's just a matter of choosing what's easier for the end user to add to their DMS, and for me to maintain. I don't know yet, I need to test the caddy cgi thing. You gave ALL that you could so far, you went above and beyond, and therefore, I will try

Well yes... and seeing that I suggested it with a tangible example provided over a month ago, I'd phrase that more as your Python approach is the same principle as I showed with Caddy 😆 (just with extra steps like ENV vars, API key, redundantly exposing port, etc)

As for what's easier to the user? Less changes and thinking on their part. I gave a self-contained single compose.override.yaml config file that was effectively copy/paste (the only potential issue for the user was if their DMS service wasn't called dms, that would need to change for the override config to work). Your main complain was it looked too heavy in content, so I stripped away the helpful contextual commentary explaining everything and showed you how you could narrow that all down if you really wanted to.

As for what's easier for you to maintain?

• I think I demonstrated how simple Caddy was when I broke it down to you for the basics, showing the equivalent of what you were already piecing together. You likely won't have to touch the bash script (unless DMS introduces a breaking change), but if you're more comfortable with Python just port that logic to a Python script.
• I haven't looked at the equivalent setup with Python. If you can keep that easily maintainable in a single Python file and prefer that instead, go for it?

The custom build of Caddy (and it's 40MB+ size making it unfriendly to committing into git) is a slight drawback in favor of Python.

• You can bundle the build into your own image Dockerfile build. The volume image type mount will make it accessible which is convenient, it's just a bit verbose your users aren't likely to be interacting much with the content of the compose.override.yaml anyway? Only other drawback here is it's Docker Compose specific I think (and recent, the user needs Docker Compose v2.35 or newer (April 2025)), otherwise they'll need to resort to a traditional bind volume mount.
• For the more broadly compatible approach to bind mounting the custom caddy build into the container instead, they can either:

  • Build locally:

    docker run --rm -it --volume ./:/build caddy:2.10.2-builder \
      xcaddy build --with github.com/aksdb/caddy-cgi/v2 --output /build/dms-api

  • Download from the official site:
    Caddy's download page is convenient for requesting builds with third-party plugins included.

    Just direct them to this URL which already has the plugin needed selected (for x86_64/AMD64, link would differ for ARM64 support). They can just click the download button from there instead of doing a local build (which needs extra disk/RAM to build).

---

6. some of your maintainers don't like python? it doesn't matter since dms-gui is the container injecting and maintaining the api (if i go that route) - as long as you embed python in DMS, indeed.

Misunderstanding. I had the impression you were also discussing the possibility of whatever Python API service you develop to be bundled into DMS officially.

We've had discussions in the past about such contributions and no active maintainer has an interest for introducing Python source code, since such contributions tend to delegate maintenance to us as a result 😓

Two of the three of us active maintainers are in support of Rust (built and maintained via a separate repo), at least to better manage and maintain logic that's not pleasant with Bash such as the account + alias management scripts. If that ever happens it'll be a library that adds in proper API support in addition to our CLI, but it'll need to get approval from the other maintainer too (possibly likely, given that none of us enjoy maintaining that portion of the project, it's difficult to grok the logic and flows given the caveats of implementing with bash).

---

7. for the doveadm commands, I think all will go through the api even though I can already send some commands to doveadm api:8080 - i don't like splitting the work between different access points.

Your call. If their proper API works better for you (understandable) go for it. I just wanted to point out that the CLI works for that functionality (which I think was suggested as a way to "login"/authorize non-admin users to a user-specific page for changing passwords).

---

I read everything but now need to give a try to the caddy approach. will take some time but thanks again for all the advice

Thanks ❤️

It should be fairly straight-forward to get running with the examples I gave, if not let me know.

I have provided links to more verbosely documented variations of the snippets provided, which should clarify each setting but if you have trouble making sense of any of it just ask here and I'll help you make sense of it :)

[audioscavenger]

dms-gui version 1.4.2 is out!

• switch to ES6 syntax
• there is officially no file from the original commit that I did not delete, add, or rewrite completely. This project is now 99% hand written and 1% AI only (google helped me a little)
• secured python API to inject commands from dms-gui, with a simple expose:8888 and a single volume mount, it cannot be simpler then that
• login and profile page
• last TODOS before jumping on the original need for the project:
  • a way to let normal users change password of each mailbox they manage vs only their dms-gui password
  • a way to let them add their own aliases and only for the domains they own
  • a way to send emails for their password reset needs

left tbd is the actual meat of what I wanted to achieve in the first place:

• domains and dns management that includes: MX, SVR, TLSA, and various TXT for DKIM etc
• dkim management

[polarathene]

domains and dns management that includes: MX, SVR, TLSA, and various TXT for DKIM etc

I wanted to have time to look into the DNS automation a bit more, but have too much of a backlog elsewhere atm.

I mentioned to you earlier I knew of another alternative to OctoDNS, and it may suit you better. That project is from StackExchange to manage their DNS, it's called dnscontrol. It's built on Go, so single binary and IIRC uses JS (or a subset of it as a DSL) for the config. I wanted to try it out and compare before bringing it up, but I'm not sure when I'd get around to that next 😓

[audioscavenger]

I mentioned to you earlier I knew of another alternative to OctoDNS, and it may suit you better. That project is from StackExchange to manage their DNS, it's called dnscontrol.

Looks amazing and better suited then octo, 100% thanks for that one.

Will take a little break from dev for some days and start working on it. The user management part and security was difficult in the end, and I had to ask my friend Claude for support as no one was helping me anywhere I tried. No one except you ;) . you seem to be a different breed, kudos to you

[audioscavenger]

all mailboxes are scanned and create a login linked to each mailbox at once. now for the passwords... either let the users reset the password or wait until DMS 16 with dovecot 2.4 where we can login users via dovecot API

[audioscavenger]

Since this great project started it has been for me amazing in almost every aspect. But a kinda ongoing problem is dealing with users changing their password.

Search no more, friend. Latest version let them change their password! soon I will add the forgot password stuff as well. Have fun

dms-gui v1.5.0

[s0ftcorn]

Well, seems like my excuses for not trying this are running out :D
Because of recent events (react2shell), i would suggest using something like dependabot. Can be setup non-breaking and helps a lot with managing dependencies.

Out of curiosity: Why go through an python api when (at least to my knowledge) you could've used docker socket + proxy?