Hallo.
Endlich läuft der linuxmuster-Mailserver hier … und es hat mich viel Zeit und Nerven gekostet bis ich das Problem, das es hier gab, überhaupt benennen konnte. Damit andere nicht in die gleiche „Falle“ (?) stolpern, schreibe ich ein paar Infos hier auf …
Eigentlich hatte ich den Thread rund um den mailcow-Container schon hier begonnen, doch mittlerweile hat sich am Setup so viel geändert, dass ich lieber nochmal neu beginne.
Ich habe mich für den tabula-rasa-Schritt entschieden und habe sowohl den Mailcow-Container als auch die linuxmuster-Erweiterung nochmal komplett von vorne installiert. Beides lief glatt durch. Auch das automatische Einbinden der Mailkonten lief sofort erstaunlich gut. Es wurden sämtliche Postfächer synchronisiert – und zwar genau so, wie es im Feld „mail“ des v7-Servers steht. Erst danach gingen die Probleme los.
Da wir zu den wenigen (??) Schulen gehören, die
- eine DMZ auf der OPNSense eingerichtet haben und
- intern wie extern den gleichen FQDN verwenden ergeben sich vermutlich gerade dadurch gewisse Schwierigkeiten
Damit besser verständlich wird, wie das Setup bei uns aussieht, kommt hier zunächst ein Bild:
Eine Anfrage vom mailcow-Container soll so ablaufen: Aus der DMZ gelangt die LDAP-Anfrage zur Firewall, die dank eines Unbound-Eintrages und der zugehörigen Portweiterleitung den v7-Server direkt im LAN auf Port 636 erreichen kann. Da der mailcow-Container ja bereits alle Postfächer synchronisiert hat, funktionierte diese Verbindung offenbar korrekt.
Das Problem ergab sich, wenn ich mich mit meinem Login an SOGo anmelden wollte: Das dauerte dann immer ziemlich lange und ein Blick auf die OPNSense-Firewall-Logs zeigte mir dann, dass der mailcow-Server jedes Mal zum Hostnamen im Internet auflöst, anstatt direkt die ldap(s)://-Verbindung zum v7-Server aufzubauen. Er klopfte also immer beim falschen Host an.
Und genau hier lag das Problem, denn bisher war ich immer davon ausgegangen, dass alle docker-Container die DNS-Settings des Hosts (hier die VM in der DMZ) erben und somit die gleichen Einstellungen verwenden.
Auf dem Host in der DMZ kann ich problemlos per ldapsearch den linuxmuster-Server im LAN sowohl auf Port 636 als auch auf 389 erreichen. Aber der docker-Container konnte das offenbar nicht: Dort liefen die Anfragen jedes Mal über die WAN-Schnittstelle raus anstatt über die LAN-Schnittstelle zum linuxmuster-Server zu gelangen. Sehr lange hatte ich daher die OPNSense-Firewall auf der „Liste der Verdächtigen“, da es zunächst so nahe lag…
Aber auf der OPNSense waren bereits alle Regeln und alle Unbound-Einstellungen angelegt, so dass interne Anfragen auf Port 636 direkt zum linuxmuster-Server gelangen.
Da sie das nicht vom mailcow-Container aus taten, bin ich schlussendlich tiefer in das DNS-Setup des mailcow-Containers eingestiegen. Zunächst habe ich mir die „üblichen Verdächtigen“ vorgenommen und /etc/docker/daemon.json editiert. Das hat aber nicht geholfen. Neue Erkenntnisse gab es erst, als ich mit einer Bash im mailcow-dovecot-Container mit dig eine DNS-Anfrage auf die unterschiedlichen Server gemacht habe: Da wurde klar, dass der docker-Container offenbar auch weiterhin einen externen DNS-Server verwendet (vgl. auch die offizielle Doku!) – warum das so ist, ist mir zwar nicht klar, doch das docker-DNS-Problem wird auch im offiziellen Forum lang und breit diskutiert.
Die Lösung, wie man das schließlich umgehen kann, steht hier:
https://mailcow.github.io/mailcow-dockerized-docs/de/manual-guides/Unbound/u_e-unbound-fwd/
Es ist so, dass der mailcow-Container nochmal einen eigenen Unbound-Dienst mitbringt. Erst mit diesen Einstellungen wurde zuverlässig zum v7-Server aufgelöst und die Anmeldung an SOGo läuft endlich flott.
Sowohl das Senden als auch das Empfangen von eMail läuft jetzt – und als wäre das noch nicht genug, habe ich auch gleich noch ein Proxmox-Mail-Gateway spendiert (das hier sowieso schon als LXC-Container mit lief). Nun läuft der gesamte eMail-Traffic so wie man das hier in der zweiten Abbildung sieht.
Das ganze sieht jetzt hier so easy aus … war es aber definitiv nicht. Zwischendurch wollte ich den ganzen Kram schon in die Ecke werfen. Dank gilt an dieser Stelle übrigens auch noch Klaus (@garblixa ), den ich schon per PM diesbzgl angefunkt hatte. Am Ende sieht das dann immer so aus wie „Ja, hättest Du mal gleich die Doku gelesen, wäre das doch klar gewesen!“ … aber ganz so einfach war es dann leider doch nicht … aber wie auch immer: Vielleicht kann jemand mit einem ähnlichen Setup etwas mit diesen Tipps anfangen 
Natürlich gibt es aber noch ein neues Problem: da ich für die eMail-Adressen der Schüler eine Form @kurzer-name.de gewählt habe, werden Mailinglisten für Projekte im Moment noch nicht korrekt erzeugt. Die erhalten alle noch die Domain @langer-domain-name.de … das ist aber ein bekannter Bug, der schon hier im Forum diskutiert wurde.
Alle anderen Tests waren bisher aber erfolgreich – eMails kommen in beide Richtungen an.
Viele Grüße,
Michael
)