OPNsense Forum
International Forums => German - Deutsch => Topic started by: Emma2 on September 20, 2019, 11:03:02 am
-
Ich wieder...
bin nicht sicher, ob hier die richtige Stelle ist oder ob ich eher bei iRedMail nachfragen müsste, aber nach meinen bisher sehr guten Erfahrungen hier versuche ich es einfach mal... 8)
Ich habe nun intern hinter meiner opnSense ein komplettes iRedMail installiert.
Allerdings funktioniert längst noch nicht alles, und ich habe auch noch viele Wissenslücken:
- Wie ist das jetzt mit dem MX-Eintrag? Meine Domäne heißt mydom.de, der Server (bzw. die opnSense) ist auf einer dynamischen IP zu erreichen (ich weiß, dass das nicht gut ist, ist ja auch nur für die Tests, später nutze ich die feste IP!). In den MX-Eintrag von mydom.de habe ich deshalb eingetragen mydom.dyndns.org. Passt das?
- Ich kann senden (zumindest extern an meine "echte" externe Adresse). Ich kann NICHT senden an meine GMX-Adresse. Kann es sein, dass das an der dynamischen IP als Absender liegt? (Oder müsste die Mail dann "nur" in meinem GMX-Spam-Ordner landen?) Oder brauche ich zum Senden grundsätzlich ein Zertifikat? Wie bekomme ich denn ein LetsEncrypt-Zertifikat? So wie auch für meine Website? OT: Reicht das auf der opnSense, oder muss das Zertifikat auch "ins iRedMail"?
- Ich kann noch nicht empfangen, habe aber die Ports 25 und 587 bereits auf den Mailserver weitergeleitet. Reicht das etwa nicht? (Für meinen Exchange hier habe ich doch auch nicht mehr getan...)
- Für die Webmail kann ich mit HAProxy eine entsprechende Regel etc. einrichten, wie ich das hier auch für mein Exchange-OWA habe, nehme ich an?
Danke für Eure Tips! :-*
-
1) Korrekt
2) GMX blockt bestimmt dialup IP's, machen viele
3) Da müsstest du schauen ob extern der MX korrekt aufgelöst wird und dann weiter debuggen
4) Korrekt, sollte passen. Notfalls halt auch über port forward
-
Jau, danke, und ich bin jetzt schon wieder weiter:
Vermutlich war ich nur zu ungeduldig, und mein alter MX-Eintrag, der auf meine feste IP zeigt, war teilweise noch gecachet.
Auf der opnSense musste ich fürs reine Empfangen jetzt doch nichts mehr machen, Port-Forwarding 25 und 587 reicht erstmal. (Dabei gehe ich aber davon aus, dass ich noch kein Zertifikat habe... muss ich mal überprüfen. Kann ich, wenn ja wie, überprüfen, ob Mails sicher reinkommen oder unsicher?) ((MXTOOLBOX.COM sieht jedenfalls ganz gut aus.))
Die Weiterleitung für die Webmail werde ich wohl hinbekommen. Aber warum sollte ich ein Port-Forwarding brauchen? Das geht doch über HAProxy mit Hilfe de Hostnames, oder?
Was jetzt noch nicht geht:
1. Senden an GMX (weil die vermutlich die IP blocken - kann ich das verifizieren?).
2. Senden von meinem Exchange (aber das ist klar, ich Blödel, die Domäne steht ja noch auf dem Exchange...)
Ich teste weiter und werde berichten. Danke bis hier!
-
> In den MX-Eintrag von mydom.de habe ich deshalb eingetragen mydom.dyndns.org. Passt das?
Ist mydom.dyndns.org ein A Record oder wie bei vielen Dyn Diensten ein CNAME? Ein MX darf kein CNAME sein, das ist per RFC untersagt. Gute MTAs blocken sowas, daher sollte man das überprüfen.
> Zertifikat
Ja. Viele MTAs setzen inzwischen vorraus, dass der Sender gefälligst 2019 mit TLS arbeiten sollte (und zwar TLS 1.2+ und nichts kleineres). Damit sollte Postfix und Co entsprechend konfiguriert werden. Und ja das geht auch mit LetsEncrypt und man kann das auch automatisieren, aber ich denke das gehört dann nicht mehr wirklich zur Sense als Fragestellung.
> Auf der opnSense musste ich fürs reine Empfangen jetzt doch nichts mehr machen, Port-Forwarding 25 und 587 reicht erstmal. (Dabei gehe ich aber davon aus, dass ich noch kein Zertifikat habe... muss ich mal überprüfen. Kann ich, wenn ja wie, überprüfen, ob Mails sicher reinkommen oder unsicher?) ((MXTOOLBOX.COM sieht jedenfalls ganz gut aus.))
Würde Port 465 SMTPS ebenfalls weiterleiten. Wird zwar weniger weil viele auf STARTTLS und Submission auf 587 bzw. implizit auf 25 setzen, aber es gibt genug gute Server die das noch klassisch über 465 testen.
> 1. Senden an GMX (weil die vermutlich die IP blocken - kann ich das verifizieren?).
UIMM (United Internet - Mail & Media), die Kollegen drüben in der Brauerstraße bzw. EFS9/10 machen das wie recht viele. Sie blocken dynamische Einwahlbereiche ab, weil da der meiste "DummSpam" herkommt. Da man bei jeder Einwahl ne andere IP bekommt/bekam haben das viele Spammer genutzt. Somit sind dynamische IP Spaces sehr häufig auf blacklists. Prüfen? Klar - schau dir den Mailheader an den du zurückbekommst bzw. die Mailantwort im Log. Meistens ist es ein 5xx-er Errorcode mit entsprechendem Hinweis auf Blacklisting oder auf Dynamic IP.
Gruß
-
> Ist mydom.dyndns.org ein A Record oder wie bei vielen Dyn Diensten ein CNAME?
Ist natürlich auch beim Klassiker nur ein CNAME (nehme ich zumindest an, ja, bin sehr sicher).
Ist aber nicht schlimm, da dies ja sowieso nur meine Testlösung ist, und sobald alles läuft biege ich ja auf meine feste IP um.
> Zertifikat
Muss ich mir mal ansehen: eventuell nutzt iRedMail ohne mein Zutun schon ein Zertifikat (und eine Mail an POSTEO kam dort wohl auch ohne Warnung an). Prüfe ich.
> Port-Forwarding 25 und 587
Ok, ich leite also 485 zusätzlich noch weiter.
> 1. Senden an GMX
... ist ja nur so lange ein Problem, bis ich fertig getestet habe und umgezogen bin. Header sehe ich mir mal an.
Danke bis hier!
-
> Ok, ich leite also 485 zusätzlich noch weiter.
465/tcp bitte. Nicht 485 :)
> Muss ich mir mal ansehen: eventuell nutzt iRedMail ohne mein Zutun schon ein Zertifikat (und eine Mail an POSTEO kam dort wohl auch ohne Warnung an). Prüfe ich.
Soweit uns bekannt nutzt iRedMail nach der Installation (zumindest bei dem neuen fancy klick dich Dingens) jetzt eh ganz andere Wege, wird aber sehr wahrscheinlich nen self-signed (standard snakeoil) Zertifikat installieren damit der Installer/das Skript alles durchinstallieren kann. Ohne Zertifikat gehts da meist nicht.
Somit hast du zu 99% schon eines, was aber eben kein echtes ist. Hardcore TLS Server lehnen das ab, aber vielen ist es egal und sie sprechen TLS sobald man Ihnen was anbietet, egal was. Gerade weil lange Zeit viele selfsigned Certs in freier Wildbahn waren, ist das eher der lockere Ansatz. Sollte und kann man aber recht einfach beheben. acme.sh auf dem Host und ein wenig symlink magic tun da ihre Arbeit.
-
@Port:
Ürgh! Natürlich Vier-SECHS-Fünf, war aber ein Vertipper... eeehrlich!
@Zertifikat:
Ja, mangels fundierter Kenntnisse habe ich den Weg per Installer gewählt (kennte ich mich besser aus, hätte ich vermutlich Postfix, Dovecot & Co manuell installiert, aber da bin ich noch weit weg von). Ja, es gibt ein "Zertifikat", aber eben ein selbsterstelltes. Habe mich nur gewundert dass das durchging, denn posteo.de (http://posteo.de)kenne ich als sehr streng. Ich muss nochmal gucken, wie ich das bei meinem Exchange gemacht habe... die opnSense unterstützt ja die Zertifikatholung bei LetsEncrypt sehr komfortabel, dann mache ich das für iRedMail genauso. ("acme.sh" und "symlink magic" sagen mir nicht viel, aber ich denke das war diese Geschichte mit automatischer Antwort auf Zertifikatsverifizierung... oder so.)
@Nachbrenner:
Noch ein Wunsch, der aber vermutlich unerfüllt bleiben wird... kann ich das Problem mit der dynmischen IP irgendwie lösen? Wäre ja schön, wenn ich meine privaten Mails auf dem Server mit der DynIP lassen könnte und nur meine dienstlichen hier auf der festen IP verwalte... muss nicht unbedingt sein, wäre aber schön... und man darf ja wohl noch träumen... 8)
-
Du brauchst ein Mail Relay. Wenn du keinen Mailprovider hast, von dem dus nutzen kannst, wird das dann eher mau aussehen. Statische IP allein ist zudem auch kein Punkt, der rDNS etc. muss auch ordentlich stimmen, da lehnen MTAs auch gerne deshalb ab (wenn also DNS der IP nicht zum HELO passt, das der Mailserver sendet).
Hat schon seinen Grund, warum ich im privaten keine Lust mehr auf Mailserver selbst basteln habe. Ja ich könnte es, mir ist aber die Lebenszeit zu schade ;)
-
Hmm, ist wieder etwas komplizierter, als ich gehofft habe...
Wollte gerade "mal eben" den Webmail-Zugang einrichten und habe deshalb die Einstellungen, die ich hier für mein Exchange-OWA habe, in den entfernten HAProxy kopiert:
- Realer Server: "mailsrv" (seine interne IP), SSL an, keine Zertifikatsüberprüfung
- Backend-Pool: "mailpool" enthält "mailsrv"
- Bedingung "mail": Host enthält "mail.mydyndom.de"
- Regel: IF "mail" dann nutze den Pool "mailpool"
Wenn ich dann die Seite http://mail.mydyndom.de ansteuere, klappt das nicht.
Wenn ich stattdessen https://mail.mydyndom.de eingebe, warnt der Feuerfuchs mich wegen des Zertifikats - welches übrigens natürlich ein anderes ist, als wenn ich den Server intern mit https://interneadresse ansteuere...
Aber auch wenn ich die Warnung akzeptiere erhalte ich ein "503 Service Unavailable - No server is available to handle this request." Liegt das daran, dass nun zwei verschiedene Zertifikate verwendet werden? Oder route ich mich da intern noch falsch? Ich bin nicht sicher, aber 503 hat doch nichts mit Zertifikaten zu tun, oder?
Oder heißt Service unavailabe, dass auf meinem Mailserver etwas nicht läuft?
Wie bekomme ich die Kuh vom Eis? Extern in Zertifikat beantragen und dieses dann in den iRedMail eintragen?
-
> Ich bin nicht sicher, aber 503 hat doch nichts mit Zertifikaten zu tun, oder?
> Oder heißt Service unavailabe, dass auf meinem Mailserver etwas nicht läuft?
Schau in der Status Seite von HAproxy rein. Im Normalfall ist 503 die Rückmeldung vom Proxy wenn er bspw. kein Backend hat und damit nichts ausliefern kann. Kein Backend heißt ebenfalls meistens, dass das eingetragene Backend mit dem Check den du definiert hast nicht funktioniert. Vllt. weil irgendwas klemmt, Zertifikat, whatever. Mal testweise auf simplen Ping Check umstellen und schauen was dann ausgeliefert wird.
Dass ein anderes Zertifikat zurückkommt - Kunststück ;) Du wirst ja wahrscheinlich SSL Termination im Proxy an haben, also liefert der Proxy das Zert an den Client, nicht dein Backend. Also muss das SSL Cert in den Proxy. -> Darum kann das ja später auch via Acme bspw. funktionieren weil dann alles autonom ablaufen kann ohne den Exchange o.ä. mit zu involvieren.