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.

[ghost]

@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.

[ghost]

@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.

[AndreKoepke]

Got very stucked here. My hint (which is missing in docs): Use mail.domain.org!
In my mind was something like: "Webmail is under mail.domain.org and SMTP/IMAP is under domain.org because the ports are open in host."
After I realized https://mailcow.github.io/mailcow-dockerized-docs/prerequisite-dns/ the whole world make sense to me. :D

FQDN is misleading, because domain.org is a FQDN. (Keep in mind that the last dot is hidden, so domain.org. is the "real" name). A FQDN does not need a service-indicator.

I would appreciate to change the text in mailcow.conf to something like

# ------------------------------
# mailcow web ui configuration
# ------------------------------
# Strongly recommended to use a domain like "mail.example.org".
# Please set CNAME- and MX-Entries for domain. See https://mailcow.github.io/mailcow-dockerized-docs/prerequisite-dns/
# Default admin user is "admin"
# Default password is "moohoo"

MAILCOW_HOSTNAME=mail.example.org

[bym0]

can vouch for @AndreKoepke, tried the myhost.de. and it worked

[Nightfirecat]

While updating my hostname to use a trailing period (nightfirec.at.) allowed the update to proceed, postfix failed to run, indicating:

warning: valid_hostname: misplaced delimiter: nightfirec.at. fatal: file /opt/postfix/conf/main.cf: parameter myhostname: bad parameter value: nightfirec.at.

To fix this, I had to re-edit mailcow.conf to remove the trailing period after the update had completed and restart the containers.

[MAGICCC]

This can be closed due to https://github.com/mailcow/mailcow-dockerized/pull/5401 The script won't exit if you use example.org, but use it on your own risk.

[rvveber]

It doesn't make much sense to use mail.domain.tld when you only have one ipv4 address, where you host mail and other services and are only able to set one PTR record. You would need to set the single PTR record to mail.domain.tld, which is not what you want to enforce