[TODO]: Transition to DMS_FQDN

[polarathene]

Description

This issue is to keep track of plans to move away from hostname (compose.yaml) / OVERRIDE_HOSTNAME (ENV) to DMS_FQDN ENV in a future release.

There's been some very big discussions in the past about going forward with such a change and the various problems with how it's managed currently (and prior to the current the state).

As it's a critical part of DMS to handle correctly, I've insisted strongly that we get our test suite into better shape where it can be run with the ability to support test environment-wide changes (config variants), which will provide more confidence in such an important change, while also allowing us to better catch regressions that slip through review (often as a well-intended "fix", that was actually deployment dependent and would accidentally break support for deployments that were working well prior).

---

Context

• Some users (often due to misunderstanding, but sometimes legitimate) choose to configure DMS with the hostname matching the mail account domain (eg: both example.com, instead of DMS using a hostname of mail.example.com).
  • We have a FAQ entry in our docs, and refer to it as configuring for a bare-domain. It's not entirely correct approach though and affects internal system mail (such as recipients that are system users for services: amavis, clamav, root).
  • There exists a more problematic and niche variation of this (we've had a few users run into this problem). Instead of example.com they want to use mail.example.com for both hostname and mail accounts. Presently DMS makes some assumptions ($mydomain in Postfix main.cf, ${DOMAINNAME} to Postfix vhost and used elsewhere too, setup config dkim default domain, login name automatically adding the domain-part when none provided, etc), which can work for @example.com bare-domain, but not so much when you want @mail.example.com as your accounts mail domain.
• In the past, compose.yaml had also advised configuring domainname to manage this separation with hostname, but this was a misunderanding. domainname in compose.yaml (or the Docker CLI) is actually for setting an NIS domain, even though it partially worked, the behaviour was found to vary based on base image distro used (Debian, Alpine, etc). The command behaviour wasn't just limited to the base image OS choice, but also other networking influences.
• Additionally even within Docker / Compose networking implementation (which may configure /etc/hosts) which did improve with future releases, and we support running DMS via other container platforms like Podman and Kubernetes which likewise play a role. Regarding /etc/hosts, Postfix previously ran via chroot which would make it's own copy during container startup, but would not sync to any changes that were introduced afterwards in the original source.
• Some environments like kubernetes required a workaround via an ENV to set the hostname, which uses OVERRIDE_HOSTNAME. Which while we supported domainname in compose.yaml, was another point of divergence.
• Our scripts retrieve hostname via hostname -f to get the fully qualified value as it should be, but due to legacy use the system ENV ${HOSTNAME}, and create our own slice of that without a potential subdomain ${DOMAINNAME}.

Transition

Final result that is user facing would be the config change from hostname (compose.yaml) / OVERRIDE_HOSTNAME (ENV) to DMS_FQDN ENV.

• Moving away from ${HOSTNAME} to ${DMS_FQDN} internally, while still using hostname in compose.yaml should be safe and a good first step.
• Moving from hostname to the ENV DMS_FQDN in compose.yaml is a bigger change. Other software beyond our scripts may attempt to source the hostname via other means (of which there is many ways). Usually that software can be configured explicitly to correct against that, but proper test coverage and environment would better detect no breakage. Arguably those that actually require OVERRIDE_HOSTNAME supposedly do not experience any issues (none that they've noticed to report at least), so one could assume that this may be safe to change too, even without extensive test coverage.
• ${DOMAINNAME} is a bit more tricky. It makes assumptions on config that is most common as the happy path (mail.example.com hostname + @example.com mail account domain) and there is similar explicit configuration by DMS elsewhere (Postfix main.cf with $mydomain usage) to account for. We already know there is breakage in DMS for deployments not configuring for our the happy path. Technically this could be left as-is and rename to DMS_DOMAIN, but it would be good to ensure alternative deployment configs can be supported properly.

If proper test coverage is not accomplished, but this change goes forward anyway; it would be advised to minimize any other breaking changes in that release so that it would be easier to attribute to this networking change.

[polarathene]

Related issues:

• feature request: Support for multiple «certificate managers» #3486 (comment)
• bug report: Rspamd can not find the key to sign. #3431 (comment)

Recently we added swaks to the image. It's default --data if not configured is to implicitly append a Message-Id header with the hostname detected. That was fine for our hostname.bats test when --hostname was configured, but it failed our ENV OVERRIDE_HOSTNAME which would be applicable to this proposed DMS_FQDN ENV.