Mailcow-dockerized: FQDN not accepted by updater script

[bn4t]

In the updater script there is a check to verify that the hostname is an FQDN (Added in commit b0b18dfc892428f7e7012c9dde2ea25609b77086).

Now the updater script no longer accpets my Mailserver's hostname, since it isn't a subdomain (e.g. My server's hostname isexample.com instead of mail.example.com).

Is this on purpose?

[lenovouser]

Same question here, I got my main domain (example.com) and then got me a 2nd one for email (example.email) and am running the mail server directly over that one.

[mkuron]

The FQDN consists of at least three parts divided by a dot.
A FQDN is always a subdomain.

That's not quite true. Anything that ends in a top-level domain is an FQDN, even if it only has two parts.

Using a domain as hostname is legitimate and always worked in Mailcow. However, it's not what most people want. DNS setup can be a bit different in that case. If you know what you are doing, you don't need to use the update script. Everyone else should probably use a subdomain as their hostname.

I suppose we could replace the check with one that only ensures that there is a valid TLD at the end.

[andryyy]

I see I removed $myhostname from mydestination. That was my biggest concern.

There were other conflicts I came across when using a sld as mailcow_hostname - but I cannot tell you which, because iForgot (tm).

We should add a warning at least.

[mkuron]

The RFC doesn't say anything about the number of labels needed. FQDN is synonymous with absolute host name or absolute domain name. That means anything that is globally unique, i.e. ends in a TLD. The opposite is a relative (or unqualified) name, which is only unique within the local search domain.

So _mail.example.com_ and _example.com_ are FQDNs. _mail_ (when addressed from _other.example.com_) is a relative name. So is _example_ (when addressed from _other.com_), but nobody sets their search domain to _com_.

_com_ is actually an FQDN too, but it is not a host name because it doesn't have an A/AAAA record. Most implementations distinguish between relative and absolute names by the presence of dots. If there are none, the search domain is appended.

[andryyy]

exampe.com is not a FQDN. com is absolutely not a FQDN. This is not open to interpretation.

[mkuron]

Have a look at the wikipedia article: https://en.m.wikipedia.org/wiki/Fully_qualified_domain_name. It does a good job explaining how being an FQDN is only about being anchored to the DNS root.

From a DNS perspective, there is no qualitative difference between _mail.example.com_ and _example.com_.

[mkuron]

Also, it probably makes more sense to simply check for the presence of an A/AAAA record for the own IP address instead of counting the number of dots. The latter would discriminate between, for example, example.com and example.co.uk.

[etique57]

I agree with @mkuron. A properly setup DNS zone should suffice. It's perfectly possible to have a working setup using domain.tld.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[whalehub]

@andryyy Any plans to fix this issue? My mail server works fine on domain.tld so it's strange that I need to change it to sub.domain.tld just so I can update mailcow.

[tkorves]

domain.tld is NOT a FQDN - mail.domain.tld is a FQDN.

I think, this article explains it better than I'm able to: https://kb.iu.edu/d/aiuv

[mkuron]

Actually, it is an FQDN. See my comments above. There is no fundamental difference between example.co.uk and mail.example.com. Anything anchored to the root zone is an FQDN. As opposed to a "plain" name, which is relative to the current search domain (e.g. mail if your search domain is example.com)

However, almost nobody uses example.com for their mail server, that's why the check in the script still makes sense. Nobody has to use the update script though (I don't use it), so it doesn't need to support advanced usage like this. The only reasonable way to resolve this issue is by checking for an A record instead of counting the number of dots. Pull requests are welcome.

[andryyy]

I don't think it is an FQDN. It is not a matter of the dots, but a defined hostname. example.co.uk does not resolve to "example" as host part.

[andryyy]

Anyway... the main reason this is not implemented were difficulties in the configuration I am not sure are fixed. It is quite possible it works with a domain name, but I don't want to support it, as long as I am unsure.

[whalehub]

@andryyy What about this compromise? #3284

[fenio]

@andryyy What about this compromise? #3284

+1

[fenio]

@andryyy What exactly are you unsure about?
RFC doesn't say anything about number of dots. If you're unsure then stop counting them as part of the solution cause you broke perfectly working setups.
My address is fully qualified domain name as it fully identifies exact machine/server.
DNS doesn't care how much dots in domain name are needed to achieve resolution of the name to IP.