6
Djigzo bzw Ciphermail eMail Gateway Postfix verweigert Annahme von eMails
Wir bieten unserer Kundschaft seit mehreren Jahren E-Mail Verschlüsselung an. Da sich sowohl PGP als auch S/MIME einfach nicht durchsetzen gibt es eine leider nur sehr überschaubare Anzahl von ~25 Empfängern an die wir derzeit auch nur verschlüsselte PDFs verschicken. In sofern betreiben wir derzeit nur verschlüsselten Versand. Die PDF Variante hat sich dennoch als Einstieg und aus anderen Gründen bewährt. Auch wenn der Aufwand hier noch in keinem Verhältnis steht.
Vor geraumer Zeit sind wir dann von unserer veralteten, meiner Meinung nach schlechteren und sehr sehr teuren Gateway Lösung auf das Djigzo E-Mail Gateway umgestiegen (mittlerweise wurde es in Ciphermail umbenannt). Ich bin damit eigentlich hoch zufrieden und fand es immer ein gelungenes Produkt, auch wenn es leider keine große Verbreitung findet und ich keine Community kenne. Es werden zwar mittlerweile Supportverträge angeboten aber da wir noch keinen haben kann ich nicht sagen wie diese gestrickt sind.
Und nun zum eigentlichen Problem:
Mein Gateway steht zwischen Exchange (2003) und E-Mail Server des Providers. Eingehende sowie ausgehende E-Mails laufen über das Gateway. Vor dem Auftritt des Fehlers lief alles Problemlos. Ab Zeitpunkt X hört das Gateway, im Besonderen der MTA (mail transfer agent) des Postfix Dienstes auf, E-Mails des Providers entgegen zu nehmen. Log:
Feb 4 12:35:01 djigzo postfix/smtpd[3268]: connect from unknown[<provider-ip>]
Feb 4 12:35:01 djigzo postfix/smtpd[3268]: lost connection after CONNECT from unknown[<provider-ip>]
Feb 4 12:35:01 djigzo postfix/smtpd[3268]: disconnect from unknown[<provider-ip>]
Das tritt nicht sporadisch auf sondern ab Zeitpunkt X immer. Der MTA nimmt weitere E-Mails des internen Exchange an und leitet sie an den externen Provider, ohne jegliche Abbrüche.
Lt. Aussage Provider wurde nichts am E-Mail System verändert. Des Weiteren soll das Gateway zwar die Verbindung einleiten und sich zur Annahme der E-Mail bereit erklären, beim Aufbau der Datenverbindung die E-Mail dann aber abweisen.
An unserem System wurde etwas ganz anderes geändert. Es existiert neben der produktiven Umgebung eine neue Testdomäne (unterschiedliche FQDN und unterschiedliche NetBIOS Namen) und ein Exchange 2013 Testsystem, da wir umsteigen möchten. Der Fehler im Gateway tritt auf, seit ich die IP des neuen Exchange auf die Liste der vertrauenswürdigen Quellen (in der Gateway Konfiguration) gesetzt habe. Es wurden noch keine E-Mails oder dergleichen verschickt, lediglich diese eine IP aufgenommen. Ziel- und Quellserver des E-Mail Verkehrs wurden nicht verändert. Ich beschreibe diesen Umstand auch nur, weil ich absolut keine Erklärung für das Verhalten des MTA habe, nicht weil ich glaube, dass irgendeine Beeinflussung des Gateways durch den neuen Exchange statt gefunden hat.
Um den Fehler beizukommen habe ich bereits die Testsysteme abgeschaltet und das Gateway aus einer Sicherung vor der Einrichtung dieser Systeme zurück gesichert, jedoch tritt der Fehler sofort in gleicher Form auf. Leitet der Provider die E-Mails direkt an unseren produktiven Exchange, nimmt dieser sie klaglos an. Nur mein Gateway versagt mir die Annahme der Mails des Providers, nicht der des Exchange.
Alle E-Mails wurden zwischenzeitlich zugestellt. Setze ich die ursprüngliche Konfiguration ein, finden erst bei Versand einer Testmail neue Verbindungsaufbauversuche statt. Es sollte also nicht an einer "problematischen" Mail liegen.
Ich bin wirklich Ratlos.
Vor geraumer Zeit sind wir dann von unserer veralteten, meiner Meinung nach schlechteren und sehr sehr teuren Gateway Lösung auf das Djigzo E-Mail Gateway umgestiegen (mittlerweise wurde es in Ciphermail umbenannt). Ich bin damit eigentlich hoch zufrieden und fand es immer ein gelungenes Produkt, auch wenn es leider keine große Verbreitung findet und ich keine Community kenne. Es werden zwar mittlerweile Supportverträge angeboten aber da wir noch keinen haben kann ich nicht sagen wie diese gestrickt sind.
Und nun zum eigentlichen Problem:
Mein Gateway steht zwischen Exchange (2003) und E-Mail Server des Providers. Eingehende sowie ausgehende E-Mails laufen über das Gateway. Vor dem Auftritt des Fehlers lief alles Problemlos. Ab Zeitpunkt X hört das Gateway, im Besonderen der MTA (mail transfer agent) des Postfix Dienstes auf, E-Mails des Providers entgegen zu nehmen. Log:
Feb 4 12:35:01 djigzo postfix/smtpd[3268]: connect from unknown[<provider-ip>]
Feb 4 12:35:01 djigzo postfix/smtpd[3268]: lost connection after CONNECT from unknown[<provider-ip>]
Feb 4 12:35:01 djigzo postfix/smtpd[3268]: disconnect from unknown[<provider-ip>]
Das tritt nicht sporadisch auf sondern ab Zeitpunkt X immer. Der MTA nimmt weitere E-Mails des internen Exchange an und leitet sie an den externen Provider, ohne jegliche Abbrüche.
Lt. Aussage Provider wurde nichts am E-Mail System verändert. Des Weiteren soll das Gateway zwar die Verbindung einleiten und sich zur Annahme der E-Mail bereit erklären, beim Aufbau der Datenverbindung die E-Mail dann aber abweisen.
An unserem System wurde etwas ganz anderes geändert. Es existiert neben der produktiven Umgebung eine neue Testdomäne (unterschiedliche FQDN und unterschiedliche NetBIOS Namen) und ein Exchange 2013 Testsystem, da wir umsteigen möchten. Der Fehler im Gateway tritt auf, seit ich die IP des neuen Exchange auf die Liste der vertrauenswürdigen Quellen (in der Gateway Konfiguration) gesetzt habe. Es wurden noch keine E-Mails oder dergleichen verschickt, lediglich diese eine IP aufgenommen. Ziel- und Quellserver des E-Mail Verkehrs wurden nicht verändert. Ich beschreibe diesen Umstand auch nur, weil ich absolut keine Erklärung für das Verhalten des MTA habe, nicht weil ich glaube, dass irgendeine Beeinflussung des Gateways durch den neuen Exchange statt gefunden hat.
Um den Fehler beizukommen habe ich bereits die Testsysteme abgeschaltet und das Gateway aus einer Sicherung vor der Einrichtung dieser Systeme zurück gesichert, jedoch tritt der Fehler sofort in gleicher Form auf. Leitet der Provider die E-Mails direkt an unseren produktiven Exchange, nimmt dieser sie klaglos an. Nur mein Gateway versagt mir die Annahme der Mails des Providers, nicht der des Exchange.
Alle E-Mails wurden zwischenzeitlich zugestellt. Setze ich die ursprüngliche Konfiguration ein, finden erst bei Versand einer Testmail neue Verbindungsaufbauversuche statt. Es sollte also nicht an einer "problematischen" Mail liegen.
Ich bin wirklich Ratlos.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 262424
Url: https://administrator.de/forum/djigzo-bzw-ciphermail-email-gateway-postfix-verweigert-annahme-von-emails-262424.html
Ausgedruckt am: 28.03.2025 um 08:03 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
Postfix ist normalerweise sehr auskunftsfreudig bei Problemen. Kannst du mal ein "grep" nach error, panic etc. in den /var/log/mail.* Dateien machen?
Ist das die VM Appliance die du verwendest?
Gruß
Andi
Postfix ist normalerweise sehr auskunftsfreudig bei Problemen. Kannst du mal ein "grep" nach error, panic etc. in den /var/log/mail.* Dateien machen?
Ist das die VM Appliance die du verwendest?
Gruß
Andi
Ja, ist die VM Appliance.
Also der Log Auszug Oben ist aus dem Webinterface des Gateways. In var/log/mail.log steht aber exakt das Selbe. Das Log-Level steht auf Info, ich bin mir nicht sicher ob Trace oder Debug als Log-Level mehr liefern würden. Habe damit expirimentiert aber keine neuen Informationen gewonnen. Das wird aber auch in ~500 Module untergliedert und meine Linux Mail Server Kenntnisse sind doch irgendwie bescheiden. An denen habe ich versucht mehr Informationen zu loggen:
mitm.application.djigzo.ws.impl.PostfixConfigManagerWSImpl
mitm.application.djigzo.ws.impl.PostfixLogManagerWSImpl
mitm.application.djigzo.ws.impl.PostfixSpoolManagerWSImpl
PS: Weder error noch panic kommen in der Log vor.
Also der Log Auszug Oben ist aus dem Webinterface des Gateways. In var/log/mail.log steht aber exakt das Selbe. Das Log-Level steht auf Info, ich bin mir nicht sicher ob Trace oder Debug als Log-Level mehr liefern würden. Habe damit expirimentiert aber keine neuen Informationen gewonnen. Das wird aber auch in ~500 Module untergliedert und meine Linux Mail Server Kenntnisse sind doch irgendwie bescheiden. An denen habe ich versucht mehr Informationen zu loggen:
mitm.application.djigzo.ws.impl.PostfixConfigManagerWSImpl
mitm.application.djigzo.ws.impl.PostfixLogManagerWSImpl
mitm.application.djigzo.ws.impl.PostfixSpoolManagerWSImpl
PS: Weder error noch panic kommen in der Log vor.
Hallo,
dh. also kein Shell Zugang...
Die Log Information ist je nach Distribution auf mail.info, mail.err etc. verteilt, deshalb such ich lieber direkt
Desweiteren sollte man/Frau sich auch um die Updates kümmern, besonders bei Sicherheits-Software. Wenn das gezeigte tatsächlich alles ist wo du dran kommst, wäre es wahrscheinlich sinnvoller jemanden zu beauftragen der sich damit auskennt z.b. von hier http://www.in-put.de/software/index.html .
Die Appliance ist meines Wissen nach nicht so eingestellt das man sie "produktiv" ohne weiteren Wartungsaufwand betreiben kann. Nach der Postfix Ausgabe zu urteilen gibt es schon in einer sehr frühen Phase Probleme, d.h. es sollte irgendwo ein panic,fatal,error zu finden sein.
BTW: Wir haben Ciphermail für ca. 60 Benutzer im Einsatz und korrekt eingestellt funktioniert es wirklich zuverlässig.
Gruß
Andi
dh. also kein Shell Zugang...
Die Log Information ist je nach Distribution auf mail.info, mail.err etc. verteilt, deshalb such ich lieber direkt
Desweiteren sollte man/Frau sich auch um die Updates kümmern, besonders bei Sicherheits-Software. Wenn das gezeigte tatsächlich alles ist wo du dran kommst, wäre es wahrscheinlich sinnvoller jemanden zu beauftragen der sich damit auskennt z.b. von hier http://www.in-put.de/software/index.html .
Die Appliance ist meines Wissen nach nicht so eingestellt das man sie "produktiv" ohne weiteren Wartungsaufwand betreiben kann. Nach der Postfix Ausgabe zu urteilen gibt es schon in einer sehr frühen Phase Probleme, d.h. es sollte irgendwo ein panic,fatal,error zu finden sein.
BTW: Wir haben Ciphermail für ca. 60 Benutzer im Einsatz und korrekt eingestellt funktioniert es wirklich zuverlässig.
Gruß
Andi
Also ich gucke mir die Logs über Fast-SCP an. Ich habe noch eine mail.err die ist allerdings leer. Auch in den anderen Logs kann ich nichts zu error und panic finden.
Bisher hat es bei uns auch sehr gut Out-of-the-Box gearbeitet. Darf ich fragen ob ihr einen Supportvertrag für das Gateway habt und was der ca. kostet?
Ich werde auf jedenfall die neuste VM aufsetzten, damit muss ich aber aus Zeitgründen noch warten. Derzeit ist ja nur der Maileingang betroffen und wir haben leider niemanden der uns verschlüsselte Mails schickt.
Bisher hat es bei uns auch sehr gut Out-of-the-Box gearbeitet. Darf ich fragen ob ihr einen Supportvertrag für das Gateway habt und was der ca. kostet?
Ich werde auf jedenfall die neuste VM aufsetzten, damit muss ich aber aus Zeitgründen noch warten. Derzeit ist ja nur der Maileingang betroffen und wir haben leider niemanden der uns verschlüsselte Mails schickt.
Hallo,
also im Zweifelsfall nehm ich tcpdump auf Port 25 und schau mir genau an was passiert...
Da noch nicht mal TLS ausgehandelt wird sollte das kein Problem sein, womöglich ist das auch genau der Punkt das euer Provider per TLS einliefern will und das Postfix auf der Djigzo VM nicht entsprechend eingerichtet ist.
Wir haben zur Zeit keinen Supportvertrag, was aber daran liegt das wir ausreichend Kompetenz in Linux/E-Mail/DNS/PKI haben und auch die Zeit uns darum zu kümmern.
Wie gesagt vielleicht einfach mal Anfragen, geht auch direkt bei https://www.ciphermail.com/support.html.
Gruß
Andi
also im Zweifelsfall nehm ich tcpdump auf Port 25 und schau mir genau an was passiert...
Da noch nicht mal TLS ausgehandelt wird sollte das kein Problem sein, womöglich ist das auch genau der Punkt das euer Provider per TLS einliefern will und das Postfix auf der Djigzo VM nicht entsprechend eingerichtet ist.
Wir haben zur Zeit keinen Supportvertrag, was aber daran liegt das wir ausreichend Kompetenz in Linux/E-Mail/DNS/PKI haben und auch die Zeit uns darum zu kümmern.
Wie gesagt vielleicht einfach mal Anfragen, geht auch direkt bei https://www.ciphermail.com/support.html.
Gruß
Andi
Also die Zeit mich zu kümmern bekomme ich auch, bei mir scheitert es etwas an Linux Kenntnissen. Bei akzeptablen Kosten wäre sicherlich auch einen Supportvertrag eine gute Wahl aber der derzeitigen Zahl von ca. 25 E-Mail Adressen an die verschlüsselt wird muss sich das schon in einem Rahmen bewegen.
TLS wird denke ich nicht das Problem sein. Im Moment glaube ich dem Provider das er nichts verändert hat, TLS wurde bisher nicht vorausgesetzt. Macht auch bei der Art von Provider kein Sinn, die E-Mails laufen schon über VPN rein.
Bevor ich jetzt mit TCP-Dumps anfange werde ich das Ding neu aufsetzen, der Aufwand ist sehr überschaubar. Ich bin aber erstmal im Urlaub, davor werde ich mich da nicht mehr rein hängen
TLS wird denke ich nicht das Problem sein. Im Moment glaube ich dem Provider das er nichts verändert hat, TLS wurde bisher nicht vorausgesetzt. Macht auch bei der Art von Provider kein Sinn, die E-Mails laufen schon über VPN rein.
Bevor ich jetzt mit TCP-Dumps anfange werde ich das Ding neu aufsetzen, der Aufwand ist sehr überschaubar. Ich bin aber erstmal im Urlaub, davor werde ich mich da nicht mehr rein hängen
