FQDN unklarheiten

somebodyunknown

Guten Tag Zusammen,

vor wenigen Wochen habe ich mir ein Mailcow-Server eingerichtet.

Habe alles streng nach Dokumentation befolgt, alle DNS Regeln gesetzt bei meinem Domainanbieter.

Bei diversen anderen Emailanbietern die freischaltung meiner static-ip durchgeprügelt usw usf. Soweit läuft alles.

Da auf diesem Server, und Domain, nur die Emails laufen, lautet die domain nur so: meineemaildomain.de (beispiel)

Während der Installation wurde diesbezüglich auch nirgends gemeckert.

Nun sah ich im Dashboard das ein Update (auf 2023-02) verfügbar ist.

Also in der Dokumentation nachgeschaut, und gesehen das ein ./update.sh reichen sollte.

Leider ist es nicht der Fall. Es wird gemeckert mit:

user@mail:/opt/mailcow-dockerized$ sudo ./update.sh
sudo: Hostname meineemaildomain.de kann nicht aufgelöst werden: Der Name oder der Dienst ist nicht bekannt
MAILCOW_HOSTNAME (meineemaildomain.de) is not a FQDN!
Please change it to a FQDN and run docker compose down followed by docker compose up -d
user@mail:/opt/mailcow-dockerized$

Ich möchte aber keine einsubdomainbeispiel.meineemaildomain.de.

Ebenso müsste dann alle Zertifikate neu. Alle Freischaltungen neu. Alle Emailsclienten (viele) neu eingerichtet werden usw usf.

Zumindest wenn ich das richtig verstehe?

pkernstock

Korrekt. Eine TLD wie domain.tld wird nicht als Mailserver-Hostname supported, weil es kein FQDN (mail.domain.tld) ist. Wenn du zukuenftige Probleme vermeiden willst (wie z.B. nun beim Updaten), musst du leider auf eine korrekte FQDN umstellen.

somebodyunknown

pkernstock

Das versteh ich jetzt ehrlich gesagt nicht, weil laut Wikipedia und anderen Docs die ich auf die schnelle durchflogen habe, ist domain.de völlig legitim.

Schlußendlich habe ich einfach:

DOTS=${MAILCOW_HOSTNAME//[^.]}; if [ ${#DOTS} -lt 2 ]; then echo "MAILCOW_HOSTNAME (${MAILCOW_HOSTNAME}) is not a FQDN!" echo "Please change it to a FQDN and run $COMPOSE_COMMAND down followed by $COMPOSE_COMMAND up -d" exit 1 fi
entfernt und alles ist gut. In wie weit “mail.domain.de” weniger Probleme machen sollte als “domain.de” (außer DEVs wollen es so), ist mir auch fern. Schlußendlich wird alles auf eine ganz bestimmte IP übersetzt und darüber auch kommuniziert.

(mal abgesehen davon, das jeder Mailanbieter, zb @t-online.de, @web.de, @gmx.de, etc lautet. nicht als Beispiel @mail.t-online.de, @mail.web.de, etc. oder ich verwechsle/missverstehe etwas.)

mlcwuser

somebodyunknown (mal abgesehen davon, das jeder Mailanbieter, zb @t-online.de, @web.de, @gmx.de, etc lautet. nicht als Beispiel @mail.t-online.de, @mail.web.de, etc. oder ich verwechsle/missverstehe etwas.)

Du kannst trotzdem *@deinedomain.de Adressen einrichten. Es geht hier nur um den Hostnamen des Servers, nicht um die Email Domains, die du daruf hostest. Bei GMX lauten die Servernamen ja z.B. auch imap.gmx.de und mail.gmx.de, und du kriegst dann trotzdem eine *@gmx.de Adresse.

pkernstock

somebodyunknown Das versteh ich jetzt ehrlich gesagt nicht, weil laut Wikipedia und anderen Docs die ich auf die schnelle durchflogen habe, ist domain.de völlig legitim.

Jain. domain.de ist eine root-domain, KEIN FQDN. Steht auch bei Wikipedia: https://en.wikipedia.org/wiki/Fully_qualified_domain_name. Der FQDN definiert den Namen deines Mailserver und des spezifischen Servers, nicht die Domains die der Mailserver verwaltet/verarbeitet.

somebodyunknown mal abgesehen davon, das jeder Mailanbieter, zb @t-online.de, @web.de, @gmx.de

Auch genannte Anbieter haben korrekt FQDNs als Mailserver:

$ dig t-online.de MX +short | head -n2
10 mx03.t-online.de.
10 mx02.t-online.de.

$ dig web.de MX +short | head -n2
100 mx-ha02.web.de.
100 mx-ha03.web.de.

$ dig gmx.de MX +short | head -n 2
10 mx01.emig.gmx.net.
10 mx00.emig.gmx.net.

Aber wie @mlcwuser eben erwaehnt hat, hat der FQDN des Mailservers nichts damit zu tun welche Domains der Mailserver verwaltet.

somebodyunknown

Ah verstehe. Vielen Dank für die Info.

Und ja, habe soeben einfach auf mail.meinedomain.de geändert, und das empfangen und senden funktioniert wohl weiterhin ohne Korrekturen an den Clienten.

Edit:
Habe gerade testweise ausprobiert was bzgl autoconfig/autodiscover passiert. Da nimmt er anscheinend dann mail.meinedomain.de als imap und smtp. Gut das die “alten” meinedomain.de dann noch funktionieren

Edit2:
Vielleicht wäre es empfehlenswert, in der Dokumentation explizit zu erwähnen, das es hier anscheinend primär um “interne” domains geht ala imap und smtp zb. und nicht die @meinedomain.de Adresse an sich. Weil genau das hat mich verwirrt (weil ich davon ausging, das die Mailadressen dann @mail.meinedomain.de lauten würden).

[unknown]

Das einzige was mich jetzt nur noch wundert, alle Zertifikate sind laut Browser und Mailclienten weiterhin gültig (lauteten alle auf meinedomain.de), und meine DNS Records habe ich auch nicht von meinedomain.de auf mail.domain.de geändert.

Und alles läuft, was nicht sollte, denke ich mir? mail-tester zeigt mir auch an das nun mail.meinedomain.de im hintergrund ist, meckert aber auch nicht und gibt mir 10/10.

somebodyunknown

So sieht es z.b bei mir aktuell noch aus.