Der perfekte FQDN | oder die QUAL der WAHL

Diskussionen zur Installation von KeyHelp.
Post Reply
ALrol
Posts: 2
Joined: Fri 19. Apr 2024, 16:46

Der perfekte FQDN | oder die QUAL der WAHL

Post by ALrol »

Hallo zusammen,

ich möchte endlich meinen "i-MSCP" Server ablösen. Dafür gibt es ja ein Skript was mir den Umzug wesentlich erleichtert. @space2place : Vielen Dank dafür!

Ob das hier jetzt die richtige Stelle ist, weiß ich auch nicht. Da es aber nicht um die Bedienung oder das Handling von dem Skript geht, sondern es sich eher um eine Frage der Machbarkeit, bzw. Verständnisfrage handelt, habe ich ein neues Thema erstellt.

Ich hab jetzt ein wenig rumprobiert und getestet, es funktioniert soweit auch alles, wie gewünscht. Mich quält jedoch eine Frage: Welcher Hostname ist der beste für meinen Fall.

Meine i-MSCP Installation ist unter control.server.de erreichbar.
Der Posteingangsserver ist jeweils unter mail.kundendomain.de, imap.kundendomain, sowie mail.server.de als auch imap.server.de erreichbar.
Der Postausgansserver steht jeweils unter smtp.kundendomain.de und smtp.server.de zur Verfügung.
Der Server selbst hat den lediglich den Namen "ns1".
Der Reverse-DNS zeigt auf "ns1.server.de"
Die Server-Domain ist auch als Kundendomain angelegt.

Soviel zur Ausgangssituation. Ich würde nun gerne meinen neuen Keyhelp-Server unter "admin.server.de" erreichbar machen. Anschließend würde ich die Kundendomains schön der Reihe nach umziehen. Dabei sollen die Kunden quasi nix davon mitbekommen. (Klar sie erhalten eine Mail mit den Zugangsdaten zum Panel, der Rest sollte aber eigentlich laufen, ohne dass die Kunden was davon merken) Also vor allem die E-Maildienste sollen auch danach noch wie bisher erreichbar sein. Meint ihr, es funktioniert, wenn ich nach dem Umzug eines Kunden, jeweils noch die Subdomains "mail, imap und smtp" anlege, unter dem Tab "E-Mail" den Schalter "Domain kann für E-Mail verwendet werden" aktiv setzte?

Ich weiß, dass ist eigentlich eine doofe Frage. Ich habe auch schon versucht mir die Frage selbst zu beantworten. Hab schon etliches gelesen und bestimmt auch schon die passende Antwort "überlesen"... Also steinigt mich bitte nicht. ;)

Vielen Dank für Eure Meinung und Unterstützung!

Gruß AL
User avatar
Florian
Keyweb AG
Posts: 1682
Joined: Wed 20. Jan 2016, 02:28

Re: Der perfekte FQDN | oder die QUAL der WAHL

Post by Florian »

Hallo,

ja wenn du mail, imap und smtp nutzen willst, und vor allem mit gültigem Zertifikat via StartTLS oder TLS/SSL musst du diese im Keyhelp als vollwertige Domains anlegen und LE und Maildienste dafür aktivieren
Mit freundlichen Grüßen / Best regards
Florian Cheno

**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany
http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
ALrol
Posts: 2
Joined: Fri 19. Apr 2024, 16:46

Re: Der perfekte FQDN | oder die QUAL der WAHL

Post by ALrol »

Vielen Dank, dann werde ich das mal so testen.
User avatar
superjogi
Posts: 168
Joined: Sat 11. Jan 2020, 23:24

Re: Der perfekte FQDN | oder die QUAL der WAHL

Post by superjogi »

Florian wrote: Tue 23. Apr 2024, 14:37 Hallo,

ja wenn du mail, imap und smtp nutzen willst, und vor allem mit gültigem Zertifikat via StartTLS oder TLS/SSL musst du diese im Keyhelp als vollwertige Domains anlegen und LE und Maildienste dafür aktivieren
Danke für diesen Tipp.
Hier hat sich bei mir bei einem ähnlichen Fall ein Problem ergeben.

Ich hatte eine Domain mx.domainname.de als vollwertige Domain mit SSL Zertifikat angelegt und dann den HOST Namen darauf geändert.
Also domainname.de, und mx.domainname.de als subdomain.
Dies hat für Email und so weiter spitze funktioniert die letzten 2 Jahre.

Nun wollte ich diese Domain zu einem anderen User umsiedeln. Das hatte keinen besonderen Grund, einfach eine sinnvollere Namensgebung.

Nach dem Löschen der Domain in dem einen User konnte ich auch domainname.de und www.domainname.de auf einem anderen User hinzufügen samt SSL.

ABER die Subdomain mx.domainname.de (die auch der Hostname und mx Servername ist) lässt sich nicht mehr hinzufügen.
Ich bekomme die Meldung, dass die Domain schon existiert.

Hmm, ich befürchte, dass nach Auslaufen des Zertifikats, oder früher dann das Einloggen in das Adminpanel, sowie der Emailabruf nicht mehr funktionieren. In der Domainliste kommt mx.domainname.de aber nicht vor.
Was kann ich da tun?
User avatar
superjogi
Posts: 168
Joined: Sat 11. Jan 2020, 23:24

Re: Der perfekte FQDN | oder die QUAL der WAHL

Post by superjogi »

superjogi wrote: Thu 4. Jul 2024, 21:34 Ich hatte eine Domain mx.domainname.de als vollwertige Domain mit SSL Zertifikat angelegt und dann den HOST Namen darauf geändert.
Also domainname.de, und mx.domainname.de als subdomain.
Dies hat für Email und so weiter spitze funktioniert die letzten 2 Jahre.
Ok, ich bin mittlerweile der Ansicht, dass eine gleichlautende Subdomain nur eingetragen werden konnte, weil der FQDN hostname im Nachhinein geändert wurde und die Subdomain schon zuvor da war.
Eine Anlage der Subdomain mit einem Pfad würde ja dazu führen, dass keyhelp nicht mehr erreichbar wäre, wenn dies nicht overridden wird.

Daneben habe ich in /etc/ssl/keyhelp/letsencrypt die let's encrypt files für diese mx.domainname.de nun nicht nur in dem alten User gefunden, sondern auch unter /etc/ssl/keyhelp/letsencrypt/keyhelp und daher denke ich, dass sich keyhelp hier weiter um die Erneuerung des Zertifikates kümmert.

Habe nun den alten User gelöscht und unter Wartung den Zertifikatcronjob ausgelöst. Alles passt soweit.
User avatar
superjogi
Posts: 168
Joined: Sat 11. Jan 2020, 23:24

Re: Der perfekte FQDN | oder die QUAL der WAHL

Post by superjogi »

Ich versuche immer, dass meine Beiträge für jemanden der später liest sinnvoll sind. 'i-MSCP' war mir kein Begriff und ich dachte, dass die FQDN gewechselt werden, und eventuelle Konsequenzen für User, Zertifikate, etc. bedacht werden.
Dadurch waren meine Posts hier off-topic.
Sorry!

Ich würde zum OP bedenken...

NAMING:
Es wäre gut wenn der Hostname / FQDN, Reverse-DNS Eintrag , MX-Eintrag gleich sind.
Also z.B. s1.server.de

Wenn der Hostname, der Reverse-DNS und der MX-Eintrag hilft dies mehrfach:
- E-Mail Zuverlässigkeit: Es hilft, E-Mails richtig zu senden und zu empfangen.
- Spam-Vermeidung: E-Mails werden seltener als Spam markiert.
- Sicherheit: Es schützt vor E-Mail-Fälschungen.
- Vertrauen: Andere Mailserver vertrauen deinen E-Mails mehr.

DOMAIN:
Die Domain kannst du auch für Webseite und Email einem User zuweisen.
Aber die Sub-Domain kannst du nicht zuweisen.

ZERTIFIKAT:
Für die Subdomain wird das Let's Encrypt aus der Zertifikatsverwaltung unter den Konfigurationen sowieso automatisch bezogen, bzw. kannst du ein gekauftes Zertifikat hinzufügen. Dies läuft also nicht wie bei den anderen Domains in den Benutzern.

ALTLASTEN:
Bisher haben deine User die Emails eventuell nicht mit derselben MX Adresse angelegt, die du jetzt zur Verfügung hast.
Ideal wäre, wenn du dieselbe Domain verwenden könntest. z.B. mail.server.de

>Der Posteingangsserver ist jeweils unter mail.kundendomain.de, imap.kundendomain, sowie mail.server.de als auch imap.server.de erreichbar.
>Der Postausgansserver steht jeweils unter smtp.kundendomain.de und smtp.server.de zur Verfügung.

Bei keyhelp habe ich da immer nur ein Eintrag s1.server.de für Eingangs- und Ausgangsserver.
Da wäre also schon etwas umzustellen für deine User. Man muss aufpassen, dass sie nicht das Postfach neu anlegen und Emails verlieren indem sie das alte löschen falls sie pop verwendet hatten.

Eventuell kannst du tatsächlich mit aktiviertem DNS beim Kunden auch die Kundendomain verwenden, dies ist mir aber noch nicht gelungen.

>Dabei sollen die Kunden quasi nix davon mitbekommen.
> Also vor allem die E-Maildienste sollen auch danach noch wie bisher erreichbar sein.
> unter dem Tab "E-Mail" den Schalter "Domain kann für E-Mail verwendet werden" aktiv setzte?
- Wenn du diese Subdomains bei den Domaineinstellungen anlegst, hilft es nichts.
- Nein, "Domain kann für E-Mail verwendet werden" hilft nur um damit ein postfach anzulegen, wie z.B. mail@imap.domainname.de aber es ist keine Weiterleitung.

EMAILÜBERTRAG:
Dies kann man mit imapsync automatisieren, das Skript ist zunächst nicht so einfach zu bedienen, aber wenn man es verstanden hat ist es ein guter Helfer.

SPAM:
TLS Setting wäre eventuell auch zu beachten, wenn du nur die neuesten Protokolle zulässt verlierst du bei manchen älteren Mailservern der Freunde deiner Kunden die Emailzustellbarkeit - diese können nicht erhalten werden und werden beim Handshake abgelehnt (also landen gar nicht im Spam).

Wenn die TLS-Einstellungen zu hoch sind und der sendende E-Mail-Server diese nicht erfüllen kann, wird die E-Mail normalerweise während des sogenannten "Handshakes" abgelehnt. Der "Handshake" ist der Moment, in dem die E-Mail-Server versuchen, eine sichere Verbindung aufzubauen. Wenn sie sich nicht auf die TLS-Einstellungen einigen können, wird die Verbindung nicht hergestellt und die E-Mail wird gar nicht erst zugestellt.

Das bedeutet, dass die E-Mail nicht im Spam-Ordner landet, weil sie nie den Empfänger-Server erreicht. Stattdessen bekommt der Absender oft eine Fehlermeldung, die erklärt, dass die E-Mail nicht zugestellt werden konnte.

SPF-record darfst du auch nicht vergessen
Weitere DMARC, DKIM Settings Infos bekommst du nur angezeigt, wenn du DNS in Keyhelp aktivierst. Die kannst du dann in die Domain DNS übertragen (wenn du die externe DNS verwendest).
Post Reply