Kopano / Mailsystem einrichten....Anfänger

Hallo Zusammen,

ich habe mir einen UCS Server eingerichtet. Dieser “hängt” an einem Unitymedia Business Anschluss mit statischer IP. Meine Domain Nameserver Daten habe ich wie folgt eingestellt:

[ul]ucs.meinserver.de A 1.2.3.4

meinserver.de MX 10 ucs.meinserver.de
*.meinserver.de MX 10 ucs.meinserver.de

imap.meinserver.de CNAME ucs.meinserver.de
pop3.meinserver.de CNAME ucs.meinserver.de
smtp.meinserver.de CNAME ucs.meinserver.de[/ul]

Auf dem UCS habe die Kopano Apps installiert. Webapp funktioniert und eine Testmail konnte ich versenden.

Sind meine NS Einträge so richtig? Gibt es was anders / besser zu machen?
Was muss ich tun, damit der UCS / Kopano auch Mails empfängt?
Muss ich in der Firewall dahinter spezielle Ports aufmachen?
Muss ich / soll ich ein externes Mail Relay einsetzen? Also den Postausgang über z-B. 1&1 leiten`?
Oder würdet ihr ein anderes Mailsystem empfehlen?

Danke und Grüße

Frank

Hallo Frank,

der MX Eintrag für *. wird afaik nicht greifen und auch die CNAME Einträge sind eventuell gut zu merken, aber rein technisch nicht notwendig. Ob Unity Media Traffic auf Port 25 sperrt, oder Mailtraffic aus dem Unity Media Netz häufiger als Spam klassifiziert wird kann ich dir nicht sagen (die meisten Dialup IPs haben weltweit aber eine geringere Reputation).

Bezüglich "was kann ich DNS-Technisch noch so machen ist iredmail.org/docs/setup.dns.html eine gute Zusammenstellung. Mir ist aber nicht bekannt, ob der Univention Mailstack für DKIM vorbereitet ist.

[quote=“my_ucs_2017”]Was muss ich tun, damit der UCS / Kopano auch Mails empfängt?
[/quote]
Die Domaineinträge nicht auf dem UCS machen sondern in der Domainverwaltung wo die Domäne gehostet ist :wink: Ich nehme mal an das es 1&1 ist.
der *. ist falsch, für jede Subdomain müsste ein eigener MX angelegt werden. Aber da die Subdomains keine Mail empfangen sollen wird dort kein MX angelegt.

Du müsstest unter deiner Domain beim Provider die Subdomain ucs.meinserver.de, imap,meinserver.de … anlegen. Ich würde aber anstelle von POP, IMAP und SMTP nur eine allgemeine MAIL Subdomain anlegen.

Auf dem UCS hat die Zone meinserver.de nichts zu suchen, dafür ist der Hoster der Domäne zuständig. Auf dem UCS müssen die Zonen ucs.meinserver.de und z.b. mail.meinserver.de angelegt werden. die verweisen mit der IP auf die interne IP des UCS.

Solltest du deine interne Domäne meinserver.de, also wie die Internetdomäne, genannt haben hast du leider einen Designfehler begangen. In diesem Fall musst du alle Einträge, die im DNS beim Hoster stehen von Hand auf den UCS übertragen und eventuell an das interne Netz anpassen.
Entweder sollte die interne Domäne auf .local oder .lan enden, oder man verwendet als interne Domäne eine Subdomäne der Internetdomäne. Diese muss nicht in den DNS beim Hoster eingetragen werden.

Dann prüfen ob man bei Unitimedia einen Reverseintrag auf ucs.meinserver.de setzen kann. Wenn nein dann zwingend den Mailserver beim Provider als Relay eintragen.

.local wird von mDNS verwendet, ist also keine gute Idee. Und .lan oder eine private Top-Level-Domain würde ich angesichts der Top-Level-Domain-Schwemme auch nicht mehr empfehlen.

[quote=“SirTux”]
.local wird von mDNS verwendet, ist also keine gute Idee. Und .lan oder eine private Top-Level-Domain würde ich angesichts der Top-Level-Domain-Schwemme auch nicht mehr empfehlen.[/quote]

+1

Für die Nachwelt halte ich das nochmal als Empfehlung fest:
Bitte für eine neue UCS Installation nach Möglichkeit eine Subdomain von einer Internetdomain verwenden, deren DNS Records man kontrolliert. Als Beispiel an der Organisation “Cabbages Corp”:
Ich habe schon “cabbages.com” als Domain bei einem Domain Name Registrar beantragt, damit meine Website dort laufen kann.
Wenn ich nun ein UCS für die interne Domain installiere, nehme ich sowas wie “intern.cabbages.com” oder “intranet.cabbages.com” oder, oder … was ich da vorne als Sudomain dran schreibe ist erstmal mir selbst überlassen, aber der zweite und dritte Teil sollten mit der externen Internetdomain übereinstimmen.
Das hat mehrere Vorteile:

  • Ich vermeide .local und mache damit Dinge wie zeroconf, Bonjour oder generell mDNS nicht kaputt
  • Ich vermeide .int oder .lan und mögliche Kollisionen mit öffentlichen TLDs in der Zukunft
  • Ich denke mir keine TLD aus und bleibe damit RFC-konform
  • Ich halte mich an die Empfehlung der ICANN
  • interne und externe Domain heißen nicht gleich und ich komme aus meinem internen Netz ohne Schmerzen auf meine externe Website
  • Da ich die DNS Records für die Domain “cabbages.com” kontrolliere, kann ich selbst sicherstellen, dass “intern.cabbages.com” niemals von extern auflösbar ist
  • Da ich die DNS Records für die Domain “cabbages.com” kontrolliere, kann ich selbst bei Bedarf weitere Subdomains wie “webmail.cabbages.com” erstellen, diese auf die öffentliche IP des Internetanschlusses meiner Organisation zeigen lassen und dann in meiner Firewall den Port 443 per NAT auf meinen internen Webmailer umbiegen. Dadurch verwenden interne wie externe Clients auch immer das selbe System und ich muss nicht mit schmerzhaften Dingen wie split-horizon-DNS anfangen.

Bei solchen Dingen kann man ja auch immer gerne nach Redmond schauen, aber leider sind die Empfehlungen von Microsoft zu dem Thema nicht konsistent. Während die TechNet-Leute mehrheitlich davon abraten, .local zu verwenden, mach(t)en Small Business Server und Windows Server Essentials das per default …

UCS versucht nun auch einen Mittelweg zu gehen und schlägt bei der Installation “cabbages.intranet” vor. Das ist ein weniger schlimmer Kompromiss, denn bislang ist .intranet noch nicht von der ICANN als offizielle TLD vorgesehen. Die Herausforderung an der Stelle ist einfach, dass UCS benutzerfreundlich halbwegs sinnvolle defaults vorschlagen muss, aber eben nicht vorab wissen kann, wie meine externe Internetdomain heißt und damit meinen Vorschlag von oben gar nicht alleine umsetzen kann. Da bin dann ich als Admin gefragt :slight_smile:

Schönen Gruß,
Michael Grandjean

@Grandjean Ohne riesigen Aufwand ist vermutlich nicht möglich, das nachträglich umzustellen oder? Ich wußte es leider damals nicht besser :wink: Für solche Fälle kann man dann wohl hauptsächlich hoffen, daß es nicht soweit kommt bzw. wenn, daß man dann schafft sich die entsprechende Second-Level-Domain zu registrieren. Oder man muß verschmerzen, daß man auf einen kleinen Teil des Internets nicht zugreifen kann.

Die Technet-Leute waren früher auch für .local haben sich dann aber geändert. Für SBS oder Essentials werden die ihre Empfehlungen aber nicht mehr ändern, da die eh fast aus dem Support raus sind.

Da ich aus der Microsftwelt komme hab ich bisher auch immer .local verwendet, seit letzten Jahr bekommen aber neue Installationen konsequent eine Subdomäne. Glücklicherweise habe ich bisher noch nie mDNS Probleme persönlich erlebt. Weder bei Kunden noch privat.

@SirTux: Ja, das nachträglich umzustellen ist sehr aufwendig, mit Sicherheit fehleranfällig und lohnt dann meistens einfach nicht.
Also wenn ich als interne Domain sowas habe wie “cabbages.int” (vll. für “intern”), dann komme ich eben nicht auf eine Website “http(s)://(*.)cabbages.int” (offizielle TLD für internationale Organisationen). Das ist meistens verschmerzbar.

@grandjean

danke für deine tipps. für mich noch mal als zusammenfassung:

ich habe bei der installation die domäne ucs.meinserver.de beannt. war das schon ein fehler?

dann hab ich bei ISP die NS einstellungen entsprechend eingestellt:

[ul]ucs.meinserver.de A 1.2.3.4

meinserver.de MX 10 ucs.meinserver.de
*.meinserver.de MX 10 ucs.meinserver.de --> werde ich löschen da offensichtlich unnötig

imap.meinserver.de CNAME ucs.meinserver.de
pop3.meinserver.de CNAME ucs.meinserver.de
smtp.meinserver.de CNAME ucs.meinserver.de[/ul]

was mir nicht gefällt, ist das die admin seite (ucs.meinserver.de/nextcloud bzw /webapp von aussen erreichbar sein. wie kann ich hier was ändern - also die admin seite von außen nicht erreichbar aber /nextcloud & /webapp?

da ich das system noch nicht nutze, kann ich es bei bedarf nochmal neu aufsetzen. und dann hofentlich richitg :slight_smile:

danke

frank

Wenn ucs.meinserver.de nur die Domain ist und nicht der FQDN des Servers (also ucs ist nicht der Hostname!) wäre das exakt so wie von Michael vorgeschlagen. Wenn ucs.meinserver.de der FQDN wäre, wäre das auch nicht unbedingt ein Beinbruch, nur wäre die Domain für anderes als Mail kaum bzw. nur mit größerem Aufwand zu gebrauchen.

ich möchte es nur für mail und nextclooud nutzen…

kann mir jemand sagen ob ich den zugriff auf die admin oberfläche z.b. auf das lokale netz (192.168.0.0/24) beschränken kann?

Das Thema hat wahrscheinlich nicht mehr viel mit Kopano an sich zu tun, es geht um die UMC, richtig? Wenn die Frage:

kann mir jemand sagen ob ich den zugriff auf die admin oberfläche z.b. auf das lokale netz (192.168.0.0/24) beschränken kann?

noch nicht beantwortet ist, bitte einen neuen Thread öffnen.

Mastodon