Apart from the comment and example being a tad confusing, it should sit above the property when it's that long.

It's incomplete

Whoops, didn't mean to resolve this.

How do we feel about eliminating domainname entirely at this point @polarathene @casperklein ? I've confirmed that both subdomains and regular domains work in hostname without domainname.

domainname is not well documented and a little confusing.

I am not sure, what exactly you mean be "removing" domainname (ps: haven't read the whole PR discussion)?

The docker(compose) options for domainname do only affect /etc/hosts in the container afaik.

Of course without domainname, similar can be achieved by using a FQDN as hostname. What do you exactly try to achieve? What improvements are you expecting?

It seems like all we require is setting hostname and not domainname. I'd like to pull it out but it's a breaking change so I'll leave it alone for now.

How do we feel about eliminating domainname entirely at this point

👍

I've confirmed that both subdomains and regular domains work in hostname without domainname.

I identified some cases where that's not the case I think, although I did not try them against docker-mailserver, and they're likely niche if at all in use (and some non-sensical ones).

I'd prefer to get the test suite refactored to run it against the variants though.

domainname is not well documented and a little confusing.

Yeah, IIRC it was made available for some need, but was generally advised against. Probably why the docs are lacking. I think it was adopted by this project either by misunderstanding or an attempted workaround.

The docker(compose) options for domainname do only affect /etc/hosts in the container afaik.

I've tested docker-compose config and it matches expectation of /etc/hosts with the Docker CLI results I observed. I didn't do a full parity comparison, but assume they're in sync these days.

Of course without domainname, similar can be achieved by using a FQDN as hostname. What do you exactly try to achieve? What improvements are you expecting?

Supporting domainname is legacy. These two config options used to behave differently with CLI and docker-compose a while back. There are past issues and PRs for the project related to it with workarounds due to confusion IIRC.

Depending on the config, and other contexts (eg network host mode), inconsistencies can be introduced.

Proposal is to at some point move any reference/usage of $HOSTNAME env (and not overwrite it) to a DMS scoped one, look at any usage of hostname command etc. We have some workaround ENV like OVERRIDE_HOSTNAME that may no longer be relevant, plus various *DOMAIN ENV.

Docs in a follow up PR will remove the usage of domainname and only advise hostname if this is the only relevant option to set. I am not sure what's required to support mail.example.com that uses mail headers example.com, or other related changes (eg if FQDN is more than 3 labels), but those use cases should be covered (I think we have tests that do).

Has hostname -d been checked with:

• hostname: mail.example.com (no domainname)
• hostname: example.com (no domainname)
• hostname: mail and domainname: example.com

Yep. Looks good.

hostname: deliver
domainname: xkr.email

root@deliver:/# hostname -f
deliver.xkr.email
root@deliver:/# hostname -d
xkr.email
root@deliver:/# hostname
deliver
root@deliver:/# echo $HOSTNAME
deliver

hostname: xkr.email

root@xkr:/# hostname -f
xkr.email
root@xkr:/# hostname -d
email # We override this and use HOSTNAME internally in the scripts
root@xkr:/# hostname
xkr.email
root@xkr:/# echo $HOSTNAME
xkr.email

hostname: deliver.xkr.email

root@deliver:/# hostname -f
deliver.xkr.email
root@deliver:/# hostname -d
xkr.email
root@deliver:/# hostname
deliver.xkr.email
root@deliver:/# echo $HOSTNAME
deliver.xkr.email

Yep. Looks good.

Was this the output from docker-mailserver after scripts are run? Or on a direct base image without docker-mailserver (at least it's scripts) involved? (EDIT: I've collected results from Debian and Alpine base images and have shared them in a follow up comment)

# We override this and use HOSTNAME internally in the scripts

This is kind of an issue for me as it sounds like we're messing with it when we shouldn't need to?

Is the difference in $HOSTNAME from hostname -f desirable? (it's the same in two examples, but in the 1st it is different), same with the commented -d result for xhr.email in the 2nd example.

UPDATE: Consistent outputs can be done with:

• domainname command will output the actual domainname set for the container. Don't use hostname -d to retrieve it. Unless you want the FQDN minus the 1st label. If domainname was not set, the returned value for the domainname command is (none).
• hostname likewise matches the actual hostname set for the container. hostname -f will return the composite value of hostname + domainname if a match is in /etc/hosts, but it must have an alias that matches the queried hostname (value of /proc/sys/kernel/hostname). For all 3 examples hostname -f will output the expected result (unless using --net=host).

Perhaps something like?:

Not in a situation where hostname in the docker-compose/run is set as a normal domain like example.com. hostname -d would be com :(

EDIT: At the time of writing this comment I had some misunderstandings. Those have since been cleared up with findings described here.

hostname -d would be com :(

That would be expected and working correctly imo. Can you explain why that's bad?

Think about it with 4 labels or 5 perhaps, and what you'd expect. Or what about example.co.uk and mail.example.co.uk, some may even have mail.internal.company.com but want company.com in the email header? 🤷‍♂️

Perhaps this just highlights the issue you're working on here? Should you be relying on HOSTNAME/DOMAINNAME?

When is a distinction of separation important and would it be better handled via setting only hostname, reading HOSTNAME(or hostname -s and hostname -f) and having a separate ENV that we use internally (unrelated to DOMAINNAME or hostname -d and similar) that allows control to explicitly deviate from the default behaviour?

I know that some software like Postfix can implicitly use the detected hostname (and possibly the domainname) values it queries from the system, as can others, but if they also support explicit config, then that's a non-issue.

Some routing is handled via /etc/hosts based on these two values, but it would only impact services within the container AFAIK, since we're using containers for sandboxing, other containers on the same network I believe also can query the containers IP via that, but nothing on the docker daemon host itself should.

I know that the tests cover different variations, but I'm not familiar of what the different use-cases are that they're all covering. Lacks examples 😅

I assume setting hostname is still of value.

AFAIK our use of OVERRIDE_HOSTNAME, HOSTNAME, and DOMAINNAME (now DMS_HOSTNAME_DOMAIN) is simply to create uniformity and predictability depending on what the user ends up configuring.

You'd notice that HOSTNAME takes priority over DOMAINNAME in postfix's config and several other important places. Changing it gives me a lot of anxiety.

Having hostname -d be com or in my case email (xkr.email) is not correct and doesn't work without some changes ( I'd rather not be responsible for ;) ).

We can't use hostname it's the just subdomain part of subdomain.sld.tld.

It looks like the /etc/hosts entry is being set properly and I've added tests for it too.

AFAIK our use of OVERRIDE_HOSTNAME, HOSTNAME, and DOMAINNAME (now DMS_HOSTNAME_DOMAIN) is simply to create uniformity and predictability depending on what the user ends up configuring.

Seems a bit much and these names are a bit overloaded? The word HOSTNAME and DOMAINNAME is getting awfully confusing looking into this and discussing it since the values vary based on context.

I'd like to try address that in future. The less I have to think about things the better 😅

This is the current usage right?:

• Public (user provided): OVERRIDE_HOSTNAME.
• Private (internal): DOMAINNAME, DMS_HOSTNAME_DOMAIN.
• System (container default ENV already set): HOSTNAME (partial internal override).

Changing it gives me a lot of anxiety.

That's fine. No need to change it any time soon if there's no immediate issues.

I'd like to get the test suite into a better shape for more easily testing this sort of change. I'll create a PR for it when I have the time.

Having hostname -d be com or in my case email (xkr.email) is not correct and doesn't work without some changes ( I'd rather not be responsible for ;) ).

My point was that it's the correct behaviour for those commands.

• Use only hostname config option with the two label FQDN (example.com or xkr.email) instead.
• Use hostname or domainname commands if you want to match the equivalent config, or source directly from /proc/sys/kernel/{hostname,domainname}.
• hostname -d or domainname -d will both output the same result. It is the 1st value from a matched /etc/hosts entry after the IP. The full value is what hostname -f/domainname -f output, while the -d variant truncates the 1st label.
• For the short hostname, Debian will provide the first label via hostname -s. Alpine linux and others however may do the same or act similar to -d and -f in sourcing from /etc/hosts, depending on packages installed. Remember that -s is always the first label only, regardless if you set a multi-label hostname and still provide a domainname.
• In the even that there is no valid match in /etc/hosts, the queried hostname may perform a DNS query to public resolvers, which may not be desireable (rarely likely to be an issue, but may hide the underlying issue).

We can't use hostname it's the just subdomain part of subdomain.sld.tld.

The command? As mentioned above, it's whatever was assigned to the container's hostname via config options.

The hostname is meant to identify the container itself on a network. That network doesn't need to be publicly accessible AFAIK.

It looks like the /etc/hosts entry is being set properly and I've added tests for it too.

It's valid if not:

• Duplicating labels between hostname and domainname.
• Having both config options set but with a multi-label hostname value.
• Using host network mode, unless an entry has been added for the containers hostname into /etc/hosts (host or container copy, note that these differ in resolution behaviour).

Just curious what the point is to provide subdomain2 if you have ENV OVERRIDE_HOSTNAME with subdomain?

Is this ENV meant to simulate -h subdomain.sld.tld while having some value in hostname -s returning subdomain2 or hostname -f returning subdomain2.sld.tld? I haven't looked into what goes on logic wise, but that's the impression I get. I would look at /etc/hosts as well, as presumably it would container the FQDN of subdomain2.sld2.tld and alias subdomain2.

If I'm correct, it could be why some breakage is already being experienced, and possibly affecting your encryption PR issues if you've got a similar setup and Dovecot or similar tries to query the hostname (short or FQDN) and that conflicts with the HOSTNAME ENV that docker-mailserver modifies?

EDIT: I viewed the related test and see that it at least checks for expected override behaviour from all known occurrences.

Is this ENV meant to simulate -h subdomain.sld.tld
Yep. That's what OVVERIDE_HOSTNAME does from what I can tell.

I would look at /etc/hosts as well, as presumably it would container the FQDN of subdomain2.sld2.tld and alias subdomain2.

Correct. We don't override /etc/hosts.

possibly affecting your encryption PR issues if you've got a similar setup and Dovecot or similar tries to query the hostname (short or FQDN) and that conflicts with the HOSTNAME ENV that docker-mailserver modifies?

Good point -- I'm hoping to try that stuff again and find the time to reach out to dovecot admins list after this is addressed.

The docs also mention this should work.

However, a FAQ entry points out that using a bare domain requires additional configuration.

mydestination should not contain a value that /etc/postfix/vhost does, which is used for virtual_mailbox_domains in Postfix main.cf, the Postfix docs specifically warn against this:

NEVER list a virtual MAILBOX domain name as a mydestination domain!

We may want to add some extra handling logic to detect and abort or possibly fix this issue before advising bare domain support like this.

May want to additionally add mention of issues with --network=host which will have trouble establishing the hostname from /etc/hosts. Present advice has been to use OVERRIDE_HOSTNAME, but it's probably more correct to ensure an entry in /etc/hosts.