dms-gui v1.5.4 is out: security, multi-arch and dovecot logins!

[audioscavenger]

Latest release v1.5.4 is out:

• hub.docker
• git dms-gui
• DEMO SERVER

Primary goals:

1. kick start the project: done, thanks to dunajdev and Claude
2. refactor, fix all the bugs, document and define scope: done/WIP
3. ability to load/save/refresh data from json files or dms commands: done
4. add rebuild/refresh xapian index buttons in Accounts page: done
5. add a login page done
6. add a Profile page and ability to change mailbox passwords done
7. add Domains+DNS+DKIM entries page
8. add DNS push entries with custom cloudflare API or octoDNS
9. add Backup/Import menu entries

Security

• no docker.sock anymore
• API secret keys and token refresh keys everywhere
• frontend zero-trust
• container daily auto-reboot
• super simple integration with DMS

Compatibility Chart

dms	dms-gui	x86_64	aarch64	details
v15.1.0	v1.5	✔️	✔️	dovecot 2.3
v16?	❌	❌	❌	dovecot 2.4

User types

user / Access	password	Profile	Dashboard	Accounts	Aliases	Logins	Settings	Backups	Imports
admins	dms-gui	✔️	✔️	✔️	✔️	✔️	✔️	✔️	✔️
users	dms-gui	✔️	✔️	partial	partial	❌	❌	partial	❌
linked users	DMS	✔️	partial	❌	partial	❌	❌	partial	❌

[polarathene]

I understand some of you abhorred the use of docker.sock but the alternative being ssh, is worse. What's wrong with using a socket? That allows the UI to access setup and doveadm and other funny commands inside dms, making it actually useful.

I detail a better alternative and why relying on a Docker socket is generally ill-advised here: https://github.com/orgs/docker-mailserver/discussions/4437#discussioncomment-14516460

The main concern is when giving write access to that API you allow any compromised container with access to it to become root on the host (assuming rootful), which is obviously dangerous. This is less of a concern in more established projects where it may be used selectively out of trust, but smaller community projects it's a bigger ask for someone to trust the developer (the developer doesn't have to be malicious either, but is more likely at risk of being compromised themselves).

My follow-up comment details how a project can take the approach of a unix socket API service shared between a separate GUI project container and the DMS container, whilst only distributing a compose.override.yaml for the user to integrate into DMS.

Use whatever you're comfortable with. When it's your project you can have more confidence and trust in using the Docker API via UDS, but I think it's understandable to take caution when a third-party project wants such access.

---

Goal 2 is maybe handle also the dkim and DNS injections via Cloudflare API. That's what I use so that's what I will develop.

In a response to you on another discussion on the topic, I did suggest OctoDNS. That would provide a broader range of DNS providers, but I can totally understand staying focused on what works best for you specifically.

[polarathene]

Sorry sorry, I only tried and learn Angular, and the global structure of a project looked more appealing to me is what I meant.

👍 Angular is good for it's conveniences (I haven't been following it for some time 😅 ), last I recall it was rather opinionated and provided quite a bit of structure. It definitely has it's fair share of advantages :)

React is more versatile, similar to Linux vs Windows/macOS which does add initial friction contributing towards analysis paralysis if you don't delegate choices of libs to someone else, but I much prefer that ecosystem personally.

Thanks a lot, however refactoring the main pages (menu items) is beyond the time I want to spent on this project.

All good, totally understandable 👍

However, zod is it's own beast of a framework. Unless you know it by using it extensively or was forced to use it at work, I don't think the form validation currently used is that bad.

Yeah no worries, I wasn't suggesting you invest time like that when what you have works well enough.

A UI project for DMS is fairly niche, and may not attract many other contributors or grow in size that all this extra feedback I shared would be worth bothering with. I was mostly wanting to show some reference examples and explain them a little bit for context should that be helpful.

---

Did I understood that right?
I don't really care what your decision is, for 2 reasons: 1. I don't have a say and 2. it's pretty easy to transform the execInContainer() calls to API calls with a function switch.

I don't think DMS will have any official API service in the near future. Beyond someone contributing one into the DMS org, it would most likely depend on me and my backlog for DMS is already very full 😅

If one is contributed I would provide review, but I don't expect a contribution would be in Rust (preferred), or a refactor of the bash scripts into a library for both CLI and API to share. If that was done that would be favourable.

There is a discussion back in 2024 about this with some info/examples too. One of the maintainers shares a small snippet in Go, we discuss concerns about the Docker socket API usage, and I mention Caddy as simple way to implement a CLI proxy service (paired with the caddy-exec plugin, you can just define routes and call commands).

EDIT: Turns out caddy-exec plugin is not as ideal, since it lacks the ability to return stdout as a response. aksdb/caddy-cgi is a similar plugin that can do this however (and in basic usage only differs by directive name cgi instead of exec).

If you do want to have a more secure approach than the docker socket API, you could bundle a custom Caddy build into your image, and use a volume mount from your image into DMS.

I wish someone would join the train but I fear someone else with more baggage like yourself within your own team, will start it and all my hard work will go to waste. That's okay, it's part of life.

Yes, if I had the time to spare for it I would probably do my own from scratch. I find it annoying enough to maintain DMS with changes that need to consider existing users and the review process, which slows things down (far easier to pile on new stuff than it is to remove or introduce breaking changes, such as migrating postfix-accounts.cf to a more standard format like JSON/TOML).

I don't believe I'd have time for such for a while, I've been wanting to tackle something like it over the years but it's rather low priority. I've also invested plenty of time into contributions or personal projects that get redundant/outdated/rejected and don't even make it to the end-user 😓

Well, that's also python based and dms-gui is node based. I could add python to alpine or find a base image that has both, but then that will affect the build images too and explode the size of the container.

IMO it might not be worth it.

If I was to look at such for DMS, I might document an example of leveraging a separate container for such, but once you add another integration then you're prone to user support queries about it, which can be a time sink should you care to answer those as the users seek to delegate figuring it out and troubleshooting to you 😅

I just mentioned OctoDNS as a nice project for when you do want something that is considerably portable/flexible for managing DNS.

Should you want to support that via a UI, you're just managing a YAML config for example and doing a CLI call. Adding the python package can add a bit of weight depending on the base image and how it's packaged. There are other ways to bring the size down, or even package into executables.

I don't find Alpine to be that great of an image size saver to be worth caveats you can run into with musl libc, instead a better base image choice is probably Fedora where dnf can install to a minimal rootfs, or for some more verbosity Canonical's chisel tool will make an even smaller Ubuntu base image at times (openSUSE can be competitive here with their package manager zypper, but I have had more positive experiences with Fedora and dnf).

This is an area I'm quite experienced in (yet I've not bothered to tackle such with DMS), but honestly the payoff to shave off some disk space often isn't worth the hassle 😅 (if you're new to optimizing images, there's quite a bit to learn)

[polarathene]

Docker Compose override example for UDS API service in DMS to proxy setup CLI

This example will demonstrate how to map a portion of the setup CLI commands which should be helpful enough of a reference to complete the rest.

The portion covered is the following:

setup email add <EMAIL ADDRESS> [<PASSWORD>]
setup email update <EMAIL ADDRESS> [<PASSWORD>]
setup email del [ OPTIONS... ] <EMAIL ADDRESS> [ <EMAIL ADDRESS>... ]
setup email restrict <add|del|list> <send|receive> [<EMAIL ADDRESS>]
setup email list

setup config dkim [ ARGUMENTS... ]

setup relay add-auth <DOMAIN> <USERNAME> [<PASSWORD>]
setup relay add-domain <DOMAIN> <HOST> [<PORT>]
setup relay exclude-domain <DOMAIN>

This would be the user's own DMS compose.yaml:

name: example-dms-api

services:
  dms:
    image: ghcr.io/docker-mailserver/docker-mailserver:${DMS_RELEASE:-15.1.0}
    hostname: mail.example.test
    configs:
      - source: dms-accounts
        target: /tmp/docker-mailserver/postfix-accounts.cf

# The Docker Compose `configs` feature inlines file content into `compose.yaml`
# NOTE: `$` will be inferred as an ENV on the host to replace with a value if found,
#       `$$` is required as an escape to opt-out of that feature when an actual `$` is expected in the file content.
configs:
  dms-accounts:
    content: |
      john.doe@example.test|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.

And with compose.override.yaml you distribute, you could self-contain the integration like this:

services:
  dms:
    volumes:
      # Use a shared named volume for the API service to create a unix socket that
      # will be accessible through this volume to another container (`my-dms-ui`):
      - api-socket:/var/run/dms-api/
      # Add the API service into the DMS image via an image volume:
      # Mounting an `image` type volume requires Docker Compose 2.35+ (April 2025)
      # https://docs.docker.com/reference/compose-file/services/#volumes
      # https://docs.docker.com/compose/releases/release-notes/#2350
      - type: image
        source: localhost/dms-api:latest
        target: /opt/dms-api/bin/dms-api
        image:
          subpath: usr/bin/caddy
    # NOTE: These could be bundled under a common subpath of your UI image,
    # which would allow them to all be shared through the common image volume above.
    # The supervisor config would require a separate image volume, or you could continue
    # to use the `configs` approach shown here (or alternatively instead extend DMS as a base image).
    configs:
      - source: supervisord-dms-api
        target: /etc/supervisor/conf.d/dms-api.conf
      - source: caddyfile
        target: /opt/dms-api/Caddyfile
      - source: proxy-to-cli
        target: /opt/dms-api/bin/proxy-to-cli
        # Ensure that the script can be executed:
        mode: 0500

  my-dms-ui:
    image: localhost/dms-api:latest
    # NOTE: You'd probably have your own image published at a public registry instead.
    # This example just builds an image with Caddy that includes a community plugin to run CLI commands:
    pull_policy: build
    build:
      # NOTE: `$$` escapes `$` to opt-out of the Docker Compose ENV interpolation feature.
      dockerfile_inline: |
        ARG CADDY_VERSION=2.10.2
        FROM caddy:$${CADDY_VERSION}-builder AS builder
        RUN xcaddy build \
          --with github.com/aksdb/caddy-cgi/v2

        FROM caddy:$${CADDY_VERSION}-alpine
        RUN apk add curl
        COPY --link --from=builder /usr/bin/caddy /usr/bin/caddy
    # Prevents starting this service for `docker compose up`:
    scale: 0
    # Long-syntax is required to use named volume with subpath.
    # In this case since the volume is not sharing multiple socket files, this verbosity
    # is not as useful (a subpath allows for restricted client access per file via a common volume)
    volumes:
      - type: volume
        source: api-socket
        target: /var/run/dms-api/api.sock
        read_only: true
        volume:
          nocopy: true
          subpath: api.sock

volumes:
  api-socket:
    name: api-socket

configs:
  supervisord-dms-api:
    content: |
      [program:dms-api]
      startsecs=0
      stopwaitsecs=55
      autostart=true
      autorestart=true
      stdout_logfile=/var/log/supervisor/%(program_name)s.log
      stderr_logfile=/var/log/supervisor/%(program_name)s.log
      command=/opt/dms-api/bin/dms-api run --config /opt/dms-api/Caddyfile --adapter caddyfile

  caddyfile:
    content: |
      {
        # This configures Caddy to bind to a unix socket by default:
        default_bind unix//var/run/dms-api/api.sock
        # Optional - This turns off automatic HTTP => HTTPS + LetsEncrypt cert provisioning (neither useful in this case):
        auto_https off
        # Optional - No need to have Caddy's admin API enabled either:
        admin off
      }

      # POST 'http://localhost/api/emails/?address=jane.doe@example.test&secret=some-password'
      # setup email add jane.doe@example.test some-password
      (api-email) {
         handle_path /api/emails/ {
           map {method} {subcommand} {cli-args} {
               GET      "list"
               POST     "add"        "{query.address} {query.secret}"
               PUT      "update"     "{query.address} {query.secret}"
               DELETE   "del"        "{query.options} {query.address}"
           }

           cgi * /opt/dms-api/bin/proxy-to-cli "email {subcommand}" {cli-args}
         }

         handle_path /api/emails/restrict/ {
           map {method} {subcommand} {cli-args} {
               GET      "list"       "{query.restriction}"
               POST     "add"        "{query.restriction} {query.address}"
               DELETE   "del"        "{query.restriction} {query.address}"
           }

           cgi * /opt/dms-api/bin/proxy-to-cli "email restrict {subcommand}" {cli-args}
         }
      }

      # POST 'http://localhost/api/config/dkim/'
      # setup config dkim
      (api-dkim) {
        handle_path /api/config/dkim/ {
          # Matchers are used here to prepend the option name when the query string value exists:
          @dkim-domain query domain=*
          vars @dkim-domain arg-domain "domain {query.domain}"

          @dkim-keysize query keysize=*
          vars @dkim-keysize arg-keysize "keysize {query.keysize}"

          @dkim-selector query selector=*
          vars @dkim-selector arg-selector "selector {query.selector}"

          vars cli-args "{vars.arg-domain} {vars.arg-keysize} {vars.arg-selector}"

          @post-request method POST
          cgi @post-request /opt/dms-api/bin/proxy-to-cli "config dkim" {vars.cli-args}
        }
      }

      # POST 'http://localhost/api/relay-hosts/auth/?sender-domain=example.test&relay-host-user=hello&relay-host-secret=world'
      # setup relay add-auth example.test hello world
      (api-relay) {
        handle_path /api/relay-hosts/* {
          map {path}    {subcommand}     {cli-args} {
              /add/     "add-domain"     "{query.sender-domain} {query.relay-host-fqdn} {query.relay-host-port}"
              /auth/    "add-auth"       "{query.sender-domain} {query.relay-host-user} {query.relay-host-secret}"
              /exclude/ "exclude-domain" "{query.sender-domain}"
          }

          @post-request method POST
          cgi @post-request /opt/dms-api/bin/proxy-to-cli "relay {subcommand}" {cli-args}
        }
      }

      # This is the API service entrypoint:
      # `http://` => Listen for HTTP requests from any host (since TCP port is irrelevant for traffic from Unix Domain Sockets)
      http:// {
         # External "snippets" declared above are imported here to keep this part easier to grok:
         import api-email
         import api-dkim
         import api-relay

         # Fallback if no valid route matched:
         handle {
           respond "Not Found" 404
         }
      }

  # `cgi` directive needs to set the `Content-type` response header; thus calls a script,
  # this is also useful for splitting inputs into individual args to the `setup` CLI
  # NOTE: `setup` CLI may check/expect some ENV when called, `cgi` strips away ENV by default (use `pass_env_all` if needed)
  # https://github.com/aksdb/caddy-cgi/blob/main/doc/document.md#troubleshooting
  proxy-to-cli:
    content: |
      #!/bin/bash

      # Required as part of the `cgi` directive to return a successful response:
      printf "Content-type: text/plain\n\n"

      function run() {
        # For readability capture into named vars:
        local SUBCOMMAND="$${1}"
        local ARGS="$${2}"

        # The two arg variables are expanded (no quotes):
        # - This splits to the expected separate args for the `setup` CLI
        # - NOTE: May not work if one of the real args was intended to preserve white-space
        /usr/local/bin/setup $${SUBCOMMAND} $${ARGS}
      }

      # Pass the args to this script into this function with their spacing retained
      run "$${@}"

While Caddy doesn't have any official support for handling on JSON request body's instead of request query parameters, you could potentially use jq in the proxy-to-cli shell script (reference for accessing the request body), adjusting the ARGS to instead be input as a list of sequential keys to extract, but this would need extra handling for the setup config dkim example.

Alternatively within the Caddyfile, this caddy-json-parse plugin could be leveraged similar to how query has been used, although I'm not sure how well it'd work for the DKIM matchers 🤔

At that point you might as well just provide your own API service rather than try to leverage Caddy. I just used Caddy here to demonstrate a unix socket API that calls CLI commands 😅 (_if that part is something you'd rather avoid, you can use Caddy just for that purpose and have it's http:// { ... } block use reverse_proxy directive to call your own local web service (just listen locally on 127.0.0.1 to prevent unrestricted access from any container on the same connected network).

Example usage

# Start-up DMS
$ docker compose up --force-recreate -d

# Add `jane.doe@example.test` via API calling `setup email add ...` from a different container:
$ docker compose run --rm --quiet my-dms-ui curl -fsS -X POST --unix-socket /var/run/dms-api/api.sock \
  'http://localhost/api/emails/?address=jane.doe@example.test&secret=some-password'

# List the accounts to verify new account was added:
$ docker compose run --rm --quiet my-dms-ui curl -fsS --unix-socket /var/run/dms-api/api.sock \
  'http://localhost/api/emails/'

* john.doe@example.test ( 0 / ~ ) [0%]

* jane.doe@example.test ( 0 / ~ ) [0%]

---

NOTE: The Caddyfile config is a bit over-engineered btw.

You could just have a single route and pass a string of text to append to the setup CLI command, having that expanded into separate args (as is already demonstrated in the proxy-to-cli script). Doing so drops away plenty of complexity if that works for you.

UPDATE: I have an example to reference for such here.

[audioscavenger]

awesome stuff... I will definitely look into Caddy. Thanks a bunch for your time

I don't find Alpine to be that great of an image size saver to be worth caveats you can run into with musl libc

okay fair enough, so I ran some tests today and here are the results (dms-gui builds and runs in all scenarios):

image	size	comment
node:24-alpine	is 168MB
node:24-alpine dms-gui	217MB	(virtual 217MB) has node v24
node:24-alpine dms-gui +py3	255MB	(virtual 255MB) has node v24
node:24-alpine dms-gui +py3+pip	276MB	(virtual 276MB) has node v24
debian:12-slim	is 75MB
debian:12-slim dms-gui +node18+py3	is 366MB	(virtual 366MB)
debian:13-slim	is 79MB
debian:13-slim dms-gui +node20+py3	is 393MB	(virtual 392MB)
docker-mailserver/docker-mailserver:latest	is 762MB	has py3 and requires +70MB for nodejs v18
debian:13-slim	is 79MB	(virtual 261MB)
debian:13-slim +node20	is 79MB	+127MB
debian:13-slim +node20-recommends	is 79MB	+105MB
debian:13-slim +py3	is 79MB	+443MB
debian:13-slim +py3-recommends	is 79MB	+38MB
debian:13-slim +node20+py3-recommends	is 79MB	+143MB

Therefore, node:24-alpine is still the best in term of size, but does not share layers with your base layer that is debian:12-slim.

I could base my image off debian:12-slim and save 75MB as base layer, but then adding node and pyhon adds +291MB and that's without the recommended dependencies. Also it's a downgrade to node js 18.

And so for the GUI to share layers with DMS using debian:12-slim, I would save 75MB and so 366-75 = +291 , and that is still >276MB alpine based image+node+py3, which includes all that I need.

So yeah I could base the gui off debian 12 but why... And when will you upgrade to debian 13 btw?

[polarathene]

awesome stuff... I will definitely look into Caddy. Thanks a bunch for your time

You're welcome! :) I like to share my knowledge so it doesn't go to waste haha.

I could base my image off debian:12-slim and save 75MB as base layer

No you would not save that. That tag gets updated, so the digest would likely differ which means no layer sharing due to different image build times.

Your Alpine figure is higher than it would be if you just used Alpine directly. The official NodeJS image (like many official language images) builds from source, offering the latest releases on multiple base images.

You're looking at roughly 119MB for Alpine with nodejs + python3 packages, or a couple MB less with apk add --no-cache:

Alpine 3.22:

• NodeJS v22.16.0
• Python 3.12.11

$ docker run --rm -it alpine:3.22 ash

$ du -shx /
8.5M    /

$ apk add nodejs
$ du -shx /
81.5M   /

$ apk add python3
$ du -shx /
119.4M  /

Fedora 43:

• Python 3.14.0rc3 (3.13 on Fedora 42)
• NodeJS v22.19.0

# NOTE: `fedora:43` is to be released on Nov 2025, use `fedora:42` if you intend to publish before then.
$ docker run --rm -it fedora:43 bash

$ dnf -yq --installroot /root-fs --use-host-config --setopt=install_weak_deps=0 install nodejs python3
$ dnf --installroot /root-fs --use-host-config clean all

# This would be the target for a `COPY` into a `FROM scratch` image via multi-stage build `Dockerfile`:
$ du -shx /root-fs
191M    /root-fs

NodeJS v22 is the current LTS release and it's latest release on 24th September was 22.20.0. v24 will be the next LTS but has not been promoted to that yet. So unless there's any major motivation for it, v22 is fine 🤷‍♂️ (there's other ways to install language runtimes though should you need to do that, you don't have to use the one provided via a package manager of the distro)

You can likewise use deno (here is their docker images repo, just COPY the /deno binary from denoland/deno:bin or extend one of their images). That is 114MB binary uncompressed, but less than 50MB over the network (compressed from registry). If you're not familiar deno is an alternative NodeJS but for many projects can be a drop-in replacement.

Later I will show how to package OctoDNS into a single executable for a small 22MB image (uncompressed), so you'd be looking at around 70MB compressed / 140MB uncompressed. All that and still smaller than anything you have in your table there, you could probably bring that down further too, but I doubt the extra effort is worth it.

FWIW the earlier Caddy executable I documented for an API service running in the DMS container, that was 60MB uncompressed, but would be around 24MB when stored at a registry and pulled:

$ docker save localhost/dms-api  | gzip -c | wc -c | numfmt --to iec
24M

That too could probably be smaller if optimizing the Go build like your would with Rust for deno.

---

So yeah I could base the gui off debian 12 but why...

Do what you like 😎

I don't think it will matter much, DMS is a fat image yet still many users happy to use it. I've shared plenty of my own expertise here should you really care to optimize for this concern.

And when will you upgrade to debian 13 btw?

DMS upgrading to Debian 13 is blocked by needing to migrate to Dovecot 2.4 (breaking changes) and a few other tasks. We are short on volunteers, and I've sustained injuries since August which limits my availability (the longer I sit at my desk, the worse my recovery).

Ideally we'll have DMS v16 out before the end of the year, but if that's largely dependent upon me for some tasks, it really depends on my health.

[audioscavenger]

good luck, I will see what I can participate in, as long as I understand the task at hand.

[audioscavenger]

okay i gave a try to octodns and after 2 hours of labor, i give up. always the same error and bad samples all over the internet, not a single example they give works at all
I doubt this is used by anyone

[polarathene]

22MB Docker runtime image for OctoDNS

UPDATE: With complimentary compose.yaml example: octodns/octodns-bind#88 (comment)

This Dockerfile below is adapted from an example I shared elsewhere for packaging a different Python project. I mention some caveats to keep in mind there for maintaining an image like this, and likewise for OctoDNS (or any Python project really) you'd probably want to pin the deps versions properly.

This will produce a minimal image with OctoDNS only at a mere ~22MB in size (under 17MB compressed), which is fairly small for a Python project.

The size is minimal because:

• PyInstaller bundles the project into a single executable (compressed), no separate Python runtime required.
• Chisel for a minimal glibc base image (based off Ubuntu).
• Fedora as a build image was used for convenience and out of preference, could be whatever you like.

Dockerfile:

# syntax=docker/dockerfile:1

FROM fedora:42 AS builder
RUN dnf install -yq python binutils which && dnf clean all
# Install `octodns` + additional DNS providers, then package into a single ~14MB executable via PyInstaller:
WORKDIR /opt/pyinstaller
RUN <<HEREDOC
  python -m venv env
  source env/bin/activate
  python -m pip install octodns octodns-bind pyinstaller

  # Create the bundled executable:
  # `--hidden-import` is required as the DNS provider modules are dynamically imported at runtime via config
  pyinstaller --onefile "$(which octodns-sync)" --hidden-import octodns_bind
HEREDOC

# Using a custom chisel image until an official one from Canonical is released:
FROM alpine AS chisel
ARG CHISEL_VERSION=1.2.0
ARG TARGETARCH
# NOTE: `--no-same-owner` used as `chisel` release has ownership of `1001:128`
RUN <<HEREDOC
  CHISEL_RELEASE="https://github.com/canonical/chisel/releases/download/v${CHISEL_VERSION}/chisel_v${CHISEL_VERSION}_linux_${TARGETARCH}.tar.gz"
  wget -qO - "${CHISEL_RELEASE}" | tar -xz --no-same-owner -C /usr/local/bin chisel
HEREDOC

# Use Canonical's Chisel tool to create a minimal Ubuntu base image (8MB /root-fs):
FROM chisel AS root-fs
WORKDIR /root-fs
RUN chisel cut --release ubuntu-24.04 --root /root-fs base-files_base libc6_libs libstdc++6_libs zlib1g_libs

# Runtime image (22MB):
FROM scratch
COPY --link --from=root-fs /root-fs /
COPY --link --from=builder /opt/pyinstaller/dist/octodns-sync /usr/local/bin/octodns-sync
WORKDIR /opt/octodns
ENTRYPOINT ["octodns-sync", "--config-file", "/opt/octodns/config.yaml"]

Build and inspect:

# Build:
$ docker build --tag localhost/octodns .

# Optionally locally test with some config mounted into the image:
$ docker run --rm -it -v ./octodns:/opt/octodns localhost/octodns

# Inspect layers/contents for size if you like:
$ docker run --rm -it \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --security-opt label:disable \
  ghcr.io/wagoodman/dive:latest localhost/octodns

# Rough estimation of gzip compressed image at registry (_for network pull size_):
$ docker save localhost/octodns | gzip -c | wc -c | numfmt --to iec
17M

Now that can be adapted to using Docker Compose with the configs inlined for this example (typically they'd just be bind volume mounted).

UPDATE: I've documented an example of such here for reference with some records like SPF and DKIM, along with some extra inline documentation to understand OctoDNS config a bit better 👍

---

Adding Cloudflare support

In your case, you'd swap out the octodns-bind provider for octodns-cloudflare (or add as an additional provider). See it's repo for docs on config, should be fairly similar to get going.

That's the primary benefit though, once it's setup you're just switching in the different DNS provider configs for the target config and then run the same commands / source to update universally 🎉 That's handy if you have to deal with many clients with various DNS providers that for whatever reason don't want to migrate to Cloudflare (or can't).

Is it worth integrating a UI for?

Personally, while I have spent the effort and time to document all of this info about OctoDNS.. I'm not sure it would be worth you pursuing for UI integration?

This doesn't seem like your area of expertise to support your users for (should things go bad like they did when you attempted it yourself), and users are likewise going to be less trusting of a third-party web UI feature that needs credentials access to their DNS 😅 (I'm sure some won't mind that risk)

[audioscavenger]

wow, just wow. thanks a lot for the extra miles and examples provided, I will re-explore this soon enough.

yes it is worth adding in the UI 100%:

1. currently i'm adding/changing DNS entries manually or via some bash scripts I created but it's a mess.
2. the UI should 100% at the very least display the dozens of records to add based of the current configuration, it's easy enough to generate with JS
3. Since you are displaying them, it should be easy enough to add a button to sync or push it from the UI

I will absolutely retry it as its own container as you described, and hopefully we can move the whole discussion to a separate thread called octo or smth. My only concern is that when I got it working somehow, both octo-validate and octo-sync would replace ALL the dns entries and that's not what I want: I want to add/modify entries not replace the whole zone.

I don't see this option to just add/modify existing entries in their docs, but I maybe wrong. Will see later.

Also you added a zonefile: entry in your example, which I haven't seen anywhere and not in their own wiki at all. So yeah it's not so simple to get started, and thank you so much for providing this example.

users are likewise going to be less trusting of a third-party web UI feature that needs credentials access to their DNS

Not too concerned about that at all.

Users are trusting your own mailserver project with their life, to not become an open relay or a spy tool for the NSA, right? So why would that be different with other containers? It's supposed to be in the same compose with dms, dms-gui, snappymail or roundcube etc so you are in control. I fail to see where the trust would be eroded. Is it because I'm a rogue developer? I'm not even employed as a dev btw, just an IT guy who can rtfm and logs for troubleshooting.

Also as 99% of users also need a swag proxy and certainly use other 3rd-party containers, they may have to enter credentials such as maxminddb, discord discogs, CROWDSEC_API_KEY, etc and I cannot believe no one is distrusting the solution they chose because of having to enter credentials and keys. As always with open source projects, you can explore the files and see for yourself that the project is not collecting individual IDs and sending them to shady servers in china. Or maybe I misunderstood what you meant?

[polarathene]

My only concern is that when I got it working somehow, both octo-validate and octo-sync would replace ALL the dns entries and that's not what I want: I want to add/modify entries not replace the whole zone.

I think the command name octo-sync might hint as to why that is 😅

It seems to focus on syncing records from sources to targets. What you're asking for is the ability to add/modify records at a target, but if not a sync then what would a record removal look like?

I suppose separate commands could allow for that, or options for octodns-sync to toggle that kind of sync expectation would work? You'd have to request such upstream at OctoDNS as from looking at the project it does not appear to support for that I think. (EDIT: Thinking it through below, I think it might be clear why this isn't supported)

That said, if you add to sources your DNS provider (such as from octodns-cloudflare), then it should be able to merge with the config source in the example (I assume config would need to be the final source item to override prior sources).

I haven't tried it but assume it would send a request to Cloudflare to get all the records for that zone, and the matching YAML zone config found by config is merged and the changes would be reported like my earlier CLI output showed when running octodns-sync. So that then gets applied to any targets, which for you may be the same as your Cloudflare declared sources provider, and presumably if you only had one record change in config it would only perform a request to sync that one record change via the Cloudflare API.

In that sense there isn't much benefit to granular remove or add/modify features? OctoDNS just gets configured to understand what the DNS records for the zone is with any changes you introduce, and you don't have to think about that much, just a common octodns-sync call that will figure it all out for you.

I suppose it'd still be convenient to be able to filter a subset of records to sync, but that still requires knowing what the state of the target is for any of those records, so having the target as a source still makes sense 🤔

---

Also you added a zonefile: entry in your example, which I haven't seen anywhere and not in their own wiki at all. So yeah it's not so simple to get started, and thank you so much for providing this example.

To be fair I cheated a little, as might be evident at my link to an issue at octodns-bind, after my compose.yaml example there, I updated a comment of mine from 2023 that links to the compose.yaml example (with back ref link now added by GitHub beneath my example comment). So I had been familiar with OctoDNS as a project for a while and that octodns-bind was a DNS provider for creating zone files.

When I went through the docs yesterday to actually try OctoDNS out, I had forgotten the provider name and initially tried a third-party one from community which hadn't been updated in years and was not what I wanted. I only found octodns-bind (primarily intended for a Bind9 DNS server) by searching the main octodns repo for issues / PRs with me as a commenter since I knew I had engaged on the topic before 😅

They absolutely should update their "Getting Started" docs to be more approachable with a provider that anyone can use locally, octodns-bind is great for that (but the provider docs don't imply it is usable without Bind9). I likewise had a bit of confusion about DNS records support and config expectations (especially with the mixed support for object / array syntax and value (string) / values (array) props for records, which I only learned ad-hoc through the example configs I saw on docs/Github).

I'll open an issue to let them know about this 👍

They do have some Docker Compose examples on their docs in a later section that self-hosts PowerDNS, but rather than linking to Github files, the links seem to be to files integrated as part of the docs site which was ehhh..

Perhaps I'll contribute an official image and improve their docs, but I doubt I'd find the time with my existing backlog 😮‍💨

---

Users are trusting your own mailserver project with their life, to not become an open relay or a spy tool for the NSA, right? So why would that be different with other containers?

As someone who is wary of adopting cool projects I come across on Github with low trust factors, this is how I look at it.

You're a much smaller project, with presently you as the sole maintainer. DMS has over 15k stars, has been going for approx a decade (first commit was around 2015 IIRC), multiple maintainers. It's not quite as big as some other projects like Caddy or NodeJS, but users are far more likely to be comfortable trusting DMS due to these factors.

DMS could become compromised, a maintainer may merge something and lack the security expertise to realize the impact on users, or users themselves misconfigure their deployment in some manner (sometimes implicitly, as I think in the past there was a problem with IPv6 and how Docker specifically handled proxying client IPv6 connections to IPv4 only containers by default, which I've documented in DMS docs). So DMS definitely isn't immune to such risks itself (nor even larger / more established projects), but users can often trust that the project tends to do a better job than the user would if they attempted it on their own.

A smaller project such as in your case, the convenience can be great, but one does have to weigh up the trust factor risks which are higher.

For me personally, giving credentials to my DNS would need need consideration of the damage that could be caused if they were compromised. For Cloudflare I think it's less of a concern as you can create API tokens with scopes that restrict usage to only what you're intending to allow, so that can be ok.

With Docker socket API access, I often don't mind using a proxy when only read access is needed (such as container labels), but write access can be quite dangerous (I'm able to write a proxy which can further restrict this per container for example but not everyone has that option easily available AFAIK?).

Using the API service with unix domain sockets works much better at restricting what you can do to the container, and only allowing your container to interact that way. Better still is when your project isn't also responsible for that API service, but DMS having an official one, since your project would be far more limited in scope to what it could do with the DMS container then.

So it's all just risk management and that varies depending on how security conscious the user is. Many are not going to care (or know any better), but I use containers specifically for the sandboxing/protection, not just conveniences like deployment.

My reluctance sometimes hinders me as a result (similar to preferring open-source vs paid proprietary solutions), but hey I've been a volunteer maintainer for DMS since the start of 2021, a niche project for deploying mail servers and I've never actually deployed DMS 😆 (but I sure have sunk a huge amount of time into nurturing DMS)

---

It's supposed to be in the same compose with dms, dms-gui, snappymail or roundcube etc so you are in control. I fail to see where the trust would be eroded.

I think I covered this already. Projects like Roundcube are well established too, so they'd have a higher trust factor. I think the larger concern with what's being discussed here is DNS credentials, that's not specific to DMS handling mail, depending on the user and what their DNS credentials allow, that can be quite the ask.

I absolutely see value in a UI frontend to something like OctoDNS, and having that integration for record values with DMS would be pretty cool too. But if it's a project with low trust factors, I may be more inclined to skip the abstraction and just go through OctoDNS directly myself.

Technically, your project doesn't have to bundle/run OctoDNS. It could offer that convenience, but besides opt-in into that feature with credentials, you could also just generate the relevant YAML zone for the YAML provider (config source), and that could be available in the UI for copy/paste, along with some directory it writes to regardless which I could have as a shared volume with a separate container for OctoDNS. That would allow less trusting users like myself to keep our secrets safe for a little inconvenience.

Similar to the Caddy API example I gave, one could also call an endpoint that runs the command outside of your own images control, which still provides the convenience of automation. I like the Caddy approach vs a DIY API service only because for users other than ourselves (the author of the API), it's easier to audit and trust because Caddy is a third-party binary they can build/acquire elsewhere (and has a higher trust factor, maybe a little less due to reliance on that third-party plugin for the custom build, but that is so generic in purpose that I don't see it being compromised for such a specific attack vs a tailored service like your project would if compromised), and the Caddyfile config file is likewise generic enough vs a bunch of source files and libs for a specific use-case API.

So if I were to write a Docker socket API proxy, I could publish one which is just a Caddyfile, or DIY my own in Rust (which I'd personally prefer and be happy to use myself). The libraries I use for that Rust implementation could all be well established and trusted, but end of the day you'd have to either compile it yourself from my source code and audit everything at my repo related to that for each update if you're paranoid, or you could delegate that trust to the more established Caddy project that isn't focused on being a Docker socket proxy specifically, and in this case does not require any custom community plugin build, just standard Caddy binary from their website (or their own official image), and the Caddyfile I provide. Personally for project that would proxy the Docker API socket (big security risk), its far easier to trust the config file of a well known/established reverse proxy software. Hopefully that is a good example of the difference, it's not that the Rust solution or me as a developer is less trustworthy, just that a user is more likely to be comfortable in trusting the Caddy approach (which was more hassle to implement than if I wrote some actual code myself tbh).

---

Is it because I'm a rogue developer?

I dunno about "rogue", it's just about leaking secrets/access to a project by some stranger on Github, especially when the project is fairly young/new. For users concerned about that, it's just convenience vs risk. Giving credentials can be risky.

Heck there was an NPM package that had been well established too IIRC, but the dev went rogue for political reasons and published a new release with malicious code that detected the IP of a system when the package was installed, and if it believed that was an IP from Russia, then a protest message was logged followed by an attempt to delete the entire filesystem (or whatever it could delete).

Your project specifically is probably going to be less of a worry in practice. I've suggested some ways you could still provide conveniences to avoid the need for providing your service secrets, so that's totally viable.

When I was learning about AI tools, I tried ComfyUI out, but while ComfyUI is well established, it relies quite a bit on the community providing packages and being in the AI space and having a large audience of less technically competent users following guides on youtube (or using tooling that simplifies setup), it was ripe target for malicious packages. These are reliant on Python scripts in the backend, and JS in the browser for their UI, installing packages was a concern for me, even with containerization as a safeguard I remember there was some risk I was concerned about. That's probably the best example that comes to mind about locking down access and minimizing risk of damage, since so many untrusted deps could be compromised (the dep authors are more likely to be at higher risk of compromise too).

I'm not even employed as a dev btw, just an IT guy who can rtfm and logs for troubleshooting.

I am not employed in IT myself, I lack the confidence 😓 (I don't tend to interview that well and tend to be too diverse in skillset from what employers usually seek)

---

As always with open source projects, you can explore the files and see for yourself that the project is not collecting individual IDs and sending them to shady servers in china. Or maybe I misunderstood what you meant?

You are right. Not many will do that in practice, and much less likely for highly active projects pushing lots of changes between image updates.

If not building the image from source yourself, you may not be able to trust the image has used the same source either (some projects have their build process external of the image, some don't even use CI for the image builds, preferring to do so locally on their own machines and push to a registry that way).

There is some support to better establish trust along the supply chain, but it varies from project to project. Typically users will adopt OSS projects in good faith, and for anything requiring secrets, that'll likely be based on trust factors like I've mentioned above.

I've definitely witnessed some questionable things in projects before. Be that processes like CI being bugged and handwaved as a non-issue, contributions slipping through that maintainers didn't catch as a concern because it's complimentary support outside their expertise (in one case I saw a PR contribute docker API socket support insecurely, the contributor was either not that wise or had malicious intent and convinced review approval to merge), telemetry defaults, etc.

[audioscavenger]

a lot to digest...

Agreed on Comfy, it's a mess atm but as I also maintain 2 plugins for that thing, it's true that lots can be hidden in the various files included. True true.

Will definitely revisit octo when I feel ready but the push of the whole zone is a no go atm. My (and anyone's, I guess) DNS is not only used for emails and hosts lots of other stuff so that cannot work. Will start with at least a page display of all the entries needed and revisit later. Mailu does that and it's really useful.

And for the socket replacement with Caddy, same as octo, more research needed. Will revisit when I am ready or when someone wants to join. I worked a lot on refactoring the form section of the settings today, and did what you advised, ie refactoring stuff. Now I have 2 independent forms in the same page and can read/save data to their own files without collision. Quite happy with it. This project is not AI slop anymore, it's now stack overflow slop.

Next big thing is designing the page/modals for the DNS entries, re/indexing, and detect dms's environment (or load dms's config) to show/hide sections like indexing etc. lots of fun, but I'm still not convinced by the slowness of React. It's not made for small gigs like this. I guarantee that if I started this as a PHP gig, it would be 10 times faster.

Anyhow, take some rest, or invest in a rising desk? that lets you work and stand up instead of sitting, as I understand you should not sit too long these days ;)

[polarathene]

Will definitely revisit octo when I feel ready but the push of the whole zone is a no go atm. My (and anyone's, I guess) DNS is not only used for emails and hosts lots of other stuff so that cannot work.

I understand that, perhaps you missed the suggestion that OctoDNS sources the existing DNS records from the target to update, and overlays that with the separate YAML config for records you want to add/modify, although I'm not quite sure how that works for removing a record then 😓

For the Cloudflare DNS provider I'm not sure if it can act as a source or only as a target. However it does have specific "Processors" to filter records by a specific tag for either inclusion or exclusion 🤔

There is similar standard processors in OctoDNS that could be used generically, but I've not looked into using that myself. As you're comfortable with Python as a dev, you can apparently write a custom processor plugin of your own if those don't quite filter how you'd want.

---

I would like to ask how you might go about managing some records via Cloudflare DNS API directly? A TXT record for SPF for example, you could easily create a new one to add it, but if you wanted to update an existing record? You need the ID for that specific record right?

I'm not sure how that'd work with OctoDNS even with that processor setup for filtering, if there were other TXT records where it'd be ambiguous. Just try dig TXT github.com for an example of what I'm talking about 😅

Possibly that'd be handled with ValueAllowlistFilter filtering on a record value starting with v=spf1 🤔

---

And for the socket replacement with Caddy, same as octo, more research needed. Will revisit when I am ready or when someone wants to join

Do you have any specific questions beyond getting familiar with Caddy and the snippets I shared?

I showed a bit more complicated way of implementing a proper HTTP interface to each command, but you could also take the naive approach which is much simpler for the Caddyfile:

{
  default_bind unix//var/run/dms-api/api.sock
  auto_https off
  admin off
  order cgi before respond
}

http:// {
  # POST 'http://localhost/setup-cli/?cli-args=email%20jane.doe@example.test%20some-password'
  # setup email add jane.doe@example.test some-password
  handle_path /setup-cli {
    @post-request method POST
    cgi @post-request /opt/dms-api/bin/proxy-to-cli {query.cli-args}
  }

  # Similar if you wanted to work with the portable OctoDNS executable:
  handle_path /octodns {
    @post-request method POST
    cgi @post-request /opt/dms-api/bin/proxy-to-octodns
  }

  # Fallback if no valid route matched:
  handle {
    respond "Not Found" 404
  }
}

The proxy-to-cli shell script would then be like:

#!/bin/bash

# Required as part of the `cgi` directive to return a successful response:
printf "Content-type: text/plain\n\n"

# This splits the input arg from a single string into separate args to the `setup` CLI
# NOTE: May not work if one of the real args was intended to preserve white-space
setup ${1}

I haven't tested that, so it's pseudo-code, pretty sure that with a query string, it'll have spaced encoded (%20), so you'd need to replace those with an actual space in the script but other than that it should work.

The HTTP response will be the stdout from running the command/script called by the cgi directive.

Another option instead of using a query string for params would be to do the post request with a JSON body instead (see the cgi repo, there is info there for how to do this), and having the proxy-to-cli script read that JSON payload with a cli-args or similar property, jq (which DMS has available) could then grab that value. Should be fairly simple.

Alternatively, write your own equivalent service in whatever language you're comfortable with.

---

but I'm still not convinced by the slowness of React. It's not made for small gigs like this. I guarantee that if I started this as a PHP gig, it would be 10 times faster.

I'm not sure what slowness you're referring to?

• DX? (you're inexperienced with React so I'm not surprised you'd be faster with what you're more comfortable with)
• Runtime speed? React should be plenty fast for typical UI that this shouldn't be a concern 🤔 If you feel it's heavy, take a look at this
  • It's a rather basic looking site I made as a demo some time back, but it's incredibly lightweight. That used Gatsby (when it was relevant) to optimize 100MB+ of image input and render the base HTML from React. IIRC all network traffic for that is less than 500KB (bulk of which is the images and their variants from the <picture> element)
  • If it did have an actual requirement for JS at runtime, it would have that during the hydration phase.
• Something else? Could you clarify?

Personally I'm not a fan of Bootstrap UI, and I didn't look into how the react project was setup, but I see you're using webpack which I'm not sure how relevant that is these days? Last I recall in 2022 (when I was more active in this area) there was more modern tooling. Vite was great for frontends and made things good for DX too.

Anyhow, take some rest, or invest in a rising desk?

Cheers! I'd like a desk like that but it's not something I can budget for any time soon.

[audioscavenger]

what slowness you're referring to?

Each page refresh takes seconds. That's not normal. Front calls its internal API that calls the backend API that executes the backend code etc... I fails to see how this is progress. Aside from allowing large projects to be sliced into pieces that can be developed by third world countries. Another subject.

Do you have any specific questions beyond getting familiar with Caddy and the snippets I shared?

Not ATM, I'm working on the UI to fits the goals I have in mind, ie reproduce what mailu-admin container does and even beyond.

I would like to ask how you might go about managing some records via Cloudflare DNS API directly? A TXT record for SPF for example,

That's quite easy actually. Almost all DNS providers have APIs and Cloudflare is really nice to deal with. It offers POST, PUT, PATCH, DELETE etc

All you need really is CF_ACCOUNT_ID and CF_AUTH_TOKEN to get started. Create tokens for all zones, or one per zone, one for ro or rw, etc. Then it's a matter of pulling records ID, then if exist, PATCH or replace or delete or PUT, etc. All data pulled from Cloudflare is json... and with bash++curl+jq it's like a breeze.

crude example from a bash function to update a record:

# https://developers.cloudflare.com/api/resources/dns/subresources/records/methods/edit/
curl -sSL "https://api.cloudflare.com/client/v4/zones/${cloudflare[zone_id.$DOMAIN]}/dns_records/$DNS_RECORD_ID" \
    -X PATCH \
  --header "Content-Type:application/json" \
  --header "Authorization: Bearer ${cloudflare[bearer.read]}" \
    -d '{
      "comment": "Domain verification record",
      "content": "198.51.100.4",
      "name": "example.com",
      "proxied": true,
      "ttl": 3600,
      "type": "A"
    }'

This is easily translatable into node, and I bet my money there is even a npm module for that. neither Mailu or iRedMail or poste.io or anything else offers that, and my UI will be the first haha

[polarathene]

Each page refresh takes seconds. That's not normal.

Is this during development, or when running it via deployment?

Either way, I don't recall that being the case when I did React development, it's very likely a fault with how it's been configured/setup, something you adopted.

That's quite easy actually. Almost all DNS providers have APIs and Cloudflare is really nice to deal with. It offers POST, PUT, PATCH, DELETE etc

Ok, so you retrieve any existing records first 👍 (something I effectively suggested for OctoDNS to do via sources)

My point was more that an ambiguous record definition given to OctoDNS would not know which record to match at the DNS provider if there were more than one entry for that.

So a partial update would be ambiguous as it's unclear if you'd be deleting, adding, or modifying a new TXT record at the domain root. Whereas with a full sync of records, there is no ambiguity.

I've not used any DNS provider APIs personally, but assume they have equivalent support for associating a record ID, however for a local zone file managed via octodns-bind, it should be rather obvious that there isn't any sense of a stable record ID.

It's much simpler when you're directly integrating with one service/API 😅

---

I've not got the time atm to play around with OctoDNS or similar, but I did come across some features that presumably do allow only managing a subset of records at the provider. OctoDNS has "processors" that I touched on already, so it possibly can do what you want by retrieving the records and filtering what is applied. That approach presumably would even work with octodns-bind since it only needs to know which lines to adjust.

[audioscavenger]

Thanks for all the info, you are a great team player and I truly command you on that.

For the slowness of React, I take that back. Since I refactored and defered backend calls to json db files, it's been much faster. And now that I added better-sqlite3 it's blazing fast. Probably I didn't know what I was doing, as I just discovered React anyways. Moving on!

Now I would love to have a philosophical discussion with the one who called that project AI slop. As I learn React, I found myself pulling lots of examples from various blogs, Stack, medium, and even google search can you believe it. The snippets I grab all look legit and similar, as long as I ask the right questions and add the react version I work with. At the end of the day, I will put gears in place that I partially developed, does that make me an AI monkey?

As much as I hate machine learning and want to call out the people who blindly call everything AI, it's a tool like gg search and helped me tremendously. When can I stop calling this project AI slop? at which point will the added code from my bare hands, outweigh the initial push coming from Claude?

[polarathene]

When can I stop calling this project AI slop?

There's nothing wrong with using AI assistance tools to develop with, so long as you are able to grok what it generates that you can know when it's outputting "slop".

Some developers rely on such tooling too heavily and then run into similar problems like inexperienced devs would manually with poorly written/disorganized code becoming a tangled spaghetti mess. At that point bugs that appear may not be well isolated and fixing them (especially via AI tooling) can lead to swapping one bug for another.

I've used Gemini to better grasp some language features I'm working with when my usual resources aren't as effective to hunt down that information. It wasn't always accurate, but other times it was surprisingly helpful, you just need to be able to verify and not trust blindly. More niche tasks I work on I don't expect AI tools to be as helpful due to complexity, but sometimes I'm impressed.

I've also seen AI integrated into Github projects for initial review (CodeRabbit I think was the name), where it confidently claimed I was doing something wrong and provided a change request that would have introduced a bug. As the contribution in question was an area I'm far more experienced in than many devs, I knew better than to trust though 😅

So for me personally, AI in dev is like a rubber duck method when I get stuck. When I started out doing dev there wasn't as much communities or quality online resources available, so when you had a problem you had to show all the effort you had done upfront before getting assistance. So I'm reluctant to reach out to others for help, but I've found capable LLMs to be an alternative that sometimes save me considerable time but I also know when they're not appropriate and would just waste my time too.

---

at which point will the added code from my bare hands, outweigh the initial push coming from Claude?

The original author that used Claude presumably didn't blindly delegate all effort to it. They did however seem to lean into it a bit heavily, including for a reply in this discussion (which I'm not fond of).

End of the day, so long as the code works and doesn't have any security issues introduced I don't think people using the software mind all that much. At least barely anyone has ever looked at my work outside of PRs to express any care about the source code.

If you're maintaining the project, then it's no different to outsourcing parts to someone else really. DMS has varying quality depending on the contributions from volunteers for example. I think it's more of an issue when someone contributes a PR that's been heavily reliant upon AI tooling since the developer may not understand their own contribution well enough that it's a negative experience for maintainers to engage with. I've also seen PRs delegate the PR description of the changes to AI tooling as well 😓

It's not too different from those who blindly copy/paste from other resources to solve problems without understanding it. It can be a time saver initially, but often has a cost towards tech debt if not careful, and sometimes security (which I've seen at a variety of projects before LLMs were involved).

[audioscavenger]

latest release is out v1.1.0!

worked a lot on the UI, added Accordions, column sorting and filtering, better-sqlite3 db, login page, and refactored tons of stuff.

[audioscavenger]

Now finally working on adding the Domains page and I would love some ideas/feedback before I mess up things.
Since DMS is account centric instead of domain centric, it's a bit convoluted and domains list is build from docker environment pull function (sub function that pulls dkim file if RSPAMD is enabled).

The page will be a DataTable with rendered action buttons opening modals, showing at least:

• domain name
• number of accounts and aliases
• dkim status and modal button
• spf status and modal button
• TLSA status and modal button
• SpamHaus/am I blacklisted sort of status
• DNS modal button: display all entries as table with push/pull all or individual entries
• DNS records entries modal: display all entries as bind compatible flat text

just looking at the simplest way to organize and show these data

[polarathene]

Since DMS is account centric instead of domain centric, it's a bit convoluted and domains list is build from docker environment pull function (sub function that pulls dkim file if RSPAMD is enabled).

Just to clarify, DMS uses full email addresses for an account login username and we associate a mailbox to that account address implicitly. This is more of a legacy decision way before I joined but technically it's not required (DMS scripts likely expect it though).

Domains aren't particularly relevant in that sense, you can have more than one resolve to the same mailbox storage via aliases for example, but an account is required to have a mailbox created. We take the domain-part of postfix-accounts.cf and postfix-virtual.cf entries and filter that down to get the configured domains, storing that in /etc/postfix/vhosts. However that won't be accurate if accounts are provisioned differently, such as via LDAP.

[audioscavenger]

dnscontrol is absolutely perfect and fits all the boxes:

• can and will be run on the fly via exec() with direct call to ghcr.io/stackexchange/dnscontrol, it's like having it installed locally, wow
• can pull zones in various formats, that we can alter and read but we ain't gonna do that at all
• instead i will push with the NO_PURGE option, which will effectively only add and modify records, which was exactly what I wanted from the beginning
• i could get it working in minutes and the commands and config files I created actually are readable and actually make sense, unlike octo
• we got a winner, and now is time for me to start working on the design of the domains page and the various entries needed for a mail server

so exciting! thanks for pointing me in the right direction

[audioscavenger]

now handling of regex aliases!

[audioscavenger]

now with logins management page and user roles!

next step is to finish reading the entirety of https://blog.logrocket.com/authentication-react-router-v6/#using-nested-routes-outlet and implement user access based off their roles, through nested routes to only when they should see.