Hallo zusammen, ich steh grad richtig auf der Leitung. Ich habe einen Mailcow-Server eingerichtet, der soweit auch wirklich hervorragend funktioniert. Ich bin auf keiner Blacklist, Microsoft-, T-online- und alle anderen problematischen E-Mail-Adressen erreiche ich und lande auf keiner Spam-Liste. Jetzt hab ich aber einen Absender - die KiTa von meinem Sohn - der mir keine Mails schicken kann. Die Kindergartenleitung erhält jedes Mal, wenn sie mir eine Mail sendet folgende Fehlermeldung: > generierender Server: mail.ebocloud.de > {mein.mailcow.server} Remote Server returned ' ' Ich hab beide Mailserver getestet (internet.nl): auf beiden ist StartTLS verfügbar. Einziger Unterschied: der KiTa-Server hat wohl eine veraltete cipher suite. Aber kann das der Grund sein? Hat vielleicht jemand einen Wink für mich, wonach ich suchen bzw. was ich einstellen kann?

Die vom KiTa-Server verwendete Cipher Suite ist TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256. Diese war bei mir im Traefik nicht hinterlegt. Ich hab's mal ergänzt. Mal sehen, ob es was bringt. ..

Hast Du bei Dir evtl. etwas unter den TLS-Richtlinien eingetragen, das eine TLS-Verbindung erzwingt? Falls der andere Server das dann nicht kann, kommt keine Verbindung zustande. `Email -> Konfiguration -> TLS-Richtlinien` oder `Email -> Konfiguration -> Mailboxen -> entsprechende Mailbox -> bearbeiten -> Verschlüsselungsrichtlinie`

So, weitere Erkenntisse: An der Cipher-Suite lag es wohl nicht. Mails kann ich von der KiTa weiterhin nicht empfangen. @"jimmy_jummy"#p10081 Ja, in der Tat hab ich da was... 1. `E-Mail -> Konfiguration -> TLS-Richtlinien` Hier hab ich genau für diese KiTa schon eine Richtlinie erstellt und zwar: ``` Ziel: {Domain der E-Mail-Adresse} Richtlinie: may Parameter: leer ``` Das `may` weicht ja meine bisherige strenge TLS-Einstellung für diese eine Domain ja schon auf. Ich füg hier jetzt einfach spaßeshalber noch den E-Mail-Server von denen hinzu. Vielleicht bringt es ja was... (Also zweiter Eintrag, nur nicht als Ziel die Mail-Domain sondern der E-Mail-Server lt. mxtoolbox) 2. `Email -> Konfiguration -> Mailboxen -> entsprechende Mailbox -> bearbeiten -> Verschlüsselungsrichtlinie` Hier hab ich nichts verändert. TLS ein-/ausgehend erzwingen ist deaktiviert. Fehlt bei 1. eventuell ein entsprechender Parameter? Oder wenn `may` nicht funktioniert, sollte ich das ganze wohl auf `none` setzen? Aber der KiTa-Server (se-rust.de) unterstützt lt. den gängigen Online-Checkern eigentlich mindestens TLSv1.2. Hab jetzt auch schon Rspamd eingestellt und den E-Mail-Server sowie deren Mail-Domain auf die Whitelisten gesetzt. Bin jetzt langsam echt am Verzweifeln...

Könntest Du nicht testweise einfach mal alles unter TLS-Richtlinien rausnehmen und gucken, ob die Mails dann durchgehen? Ehrlichgesagt habe ich diese Funktion noch nie benutzt. Daher weiß ich nicht sicher, was hier genau einzustellen wäre.

@"jimmy_jummy"#p10084 Rausnehmen würde bedeuten, dass ich denen auch nicht mehr schreiben kann. Daher hatte ich das ganze mal auf "may" gesetzt. Ich hab mir jetzt auch mal die Beschreibung angeschaut: > Opportunistic TLS. [...] When opportunistic TLS handshakes fail, Postfix retries the connection with TLS disabled. This allows mail delivery to sites with non-interoperable TLS implementations. Das verstehe ich jetzt so, dass wenn beim Senden der TLS-Handshake nicht funktioniert, dass die E-Mail-Übertragung ohne TLS-Verschlüsselung stattfindet. Ich glaub, ich setz die beiden Einträge (E-Mail-Server und Maildomain) einfach mal auf `none`. Dann sollte es für diese Domain(s) definitiv deaktiviert sein. Ich würde beim Rest nämlich schon ganz gerne die Option "TLS erzwingen" aktivieren wollen.

@"theMooMichel"#p10085 Verstehe. Lass uns dann mal wissen, ob es geklappt hat. Wäre ggf. interessant für später. Danke.

@"jimmy_jummy"#p10086 Es hat alles nichts gebracht. Die Mails werden einfach nicht zugestellt. Wir haben es jetzt mal an eine alternative Mailadresse (mailbox.org) schicken lassen, da funktioniert es. Ich werd jetzt mal schauen, dass ich meinen Server so gut es geht dem "Heinlein-Server" anpasse und versuche es dann noch einmal.

Ich hab mir mal die Postfix Logs angeschaut zu der Zeit, in der die KiTa versucht hatte, eine Mail an mich zu senden. Dabei sind mir besonders diese Warnungen ins Auge gestochen. Diese "warnings"... sind die auf meiner Seite oder liegen die beim Mailserver des Senders? ``` 02.08.2023, 10:49:15 info disconnect from mail.ebocloud.de[62.214.191.210] ehlo=1 starttls=0/1 commands=1/2 02.08.2023, 10:49:15 info lost connection after STARTTLS from mail.ebocloud.de[62.214.191.210] 02.08.2023, 10:49:15 info SSL_accept error from mail.ebocloud.de[62.214.191.210]: -1 02.08.2023, 10:49:15 info TLS SNI mail.meinMailserver.tld from mail.ebocloud.de[62.214.191.210] not matched, using default chain 02.08.2023, 10:49:15 info connect from mail.ebocloud.de[62.214.191.210] 02.08.2023, 10:49:15 warning warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:../ssl/statem/statem_srvr.c:1685: 02.08.2023, 10:49:15 warning warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:../ssl/statem/statem_srvr.c:1685: 02.08.2023, 10:49:15 warning warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2283: 02.08.2023, 10:49:15 warning warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2283: 02.08.2023, 10:49:14 info PASS NEW [62.214.191.210]:53384 02.08.2023, 10:49:11 info Look up 62.214.191.210 on whitelist, result 200 DUNNO 02.08.2023, 10:49:11 info CONNECT from [62.214.191.210]:53384 to [172.22.1.253]:25 ```

Also, ich bin nicht wirklich der SSL Experte, aber für mich sieht es so aus, als wenn `mail.ebocloud.de` eine veraltete SSL-Version verwendet und deshalb kein Mailaustausch zustande kommt. Ich würde testweise bei Dir eine neue Mailbox anlegen und diese OHNE jegliche Verschlüsselungsrichtlinien belassen. Dann eine Mail von der Kita schicken lassen und schauen, ob diese ankommt. Einfach nur um auszuschließen, dass es an der Mailcow liegt. Falls keine Mail ankommt, dann liegt es INHO an diesem Outlook Gedöns, weil die mit zu alten Protokollen versuchen zu senden.

@"jimmy_jummy"#p10103 Ich hab jetzt noch etwas mit OpenSSL "gespielt" und verschiedenes getestet. Irgendwie scheinen mir die Ergebnisse deren Mail-Server nicht so ganz schlüssig. Daher hab ich jetzt einfach mal eine Mail an deren Postmaster geschickt. Mal sehen, ob da was zurückkommt.

Mail von einem Absender kann an meine Mailkuh nicht zugestellt werden

Robox

Ja nur die OPNSense.

esackbauer

Damit funktioniert greylisting und all die anderen antispam Dinge nicht sauber wenn du einfach ein NAT Portforwarding Port auf der OPNSense richtung Mailcow machst.
Das wäre jetzt meine Erklärung und vermutlich der Grund warum der Mailserver nicht oder nur sehr langsam reagiert.
Solche Konstruktionen sind nicht geeignet für Mailserver. Besser wäre die mailcow gleich ganz bei Hetzner zu hosten.

Robox

Habe den meinen Mailserver gerate selbst noch mal getestet und konnte keine Probleme der Geschwindigkeit feststellen.

Und das an der OPNSense liegt, kann ich mir nicht vorstellen. Heute zutage kommt man doch überhaupt nicht ohne Firewall mehr aus und damit ist immer NAT Portforwarding verbunden.

Habe gerade ein TLS Report von Google bekommen, vielleicht hilft der das Problem einzugrenzen.

googlecomheiko-kistlerde17235936001723679999001.json

13kB

DocFraggle

Ich bekomme bei Dir diesen Fehler:

Certificate #1 of 1 (sent by MX):
Cert is unsigned
Cert VALIDATION ERROR(S): unable to get local issuer certificate
This may help: What Is An Intermediate Certificate
So email is encrypted but the recipient domain is not verified

Hast Du evtl das ICA Zertifikat in Deiner Chain auf der OPNSense vergessen?

Getestet hier: https://www.checktls.com/TestReceiver

Robox

Ich lasse die SLL-Zertifikate in der OPNSense mit Hilfe ACME erstelle und auf Mail Server direkt kopieren und importieren.

Dabei werden 4 Dateien übertragen, cert.pem, ca.pem, fullchain.pem, und key.pem, die 1 zu 1 importiere.
Muss ich da eine Datei umbenenn oder noch eine weitere Datei manuell übertragen.

Laut Anleitung von docs.mailcow.email werden nur die key.pem und cert.pem, benötigt.

DocFraggle

Kommt auf Dein Setup an. Wenn Deine OPNSense bei Hetzner alles terminiert dann geht’s ja um das Zertifikat dort, wenn die das nur durchleitet dann um das bei Dir Zuhause

Edit: ich habe gerade bei meiner mailcow in die cert.pem geschaut, da ist das ICA Zertifikat mit drin. Schau mal bei Dir nach

Robox

In meiner cert.pem ist nur Zertifikat hinterlegte

[unknown] habe denn SSL fehlen so eben gefixt musste fullchain.pem in cert.pem umbenennen
jetzt bin ich mal gespannt, ob sich mein Problem damit gelöste ist.

[unknown]

danke für die Hilfe und Denkanstöße, das Problem ist gelöst

DocFraggle

Ja, jetzt ist der SSL Fehler weg

« Previous Page