Hi,
muss mich an das Thema auch mal "dranhängen".
Bei mir hakte es nun auch gewaltig.
Setup:
GVS mit zahlreichen Makros, die serialisierte Befehle ausführen. Abschluss ist immer eine "Quittung" per E-Mail.
Seit einigen Tagen sind Makros mit extremen Zeitversatz ausgeführt worden und der Bus war per App nicht erreichbar.
Fehler war, dass der E-Mail Versand in einen Timeout gelaufen ist.
Diese Einstellungen funktionierten seit rund 7 Jahren mit tausenden Mails.
Erster Verdacht: Windows steht irgendwo auf dem Schlauch, bzw. die Firewall blockt den SMTP Versand vom GVS Server Dienst.
Ergebnis: alles offen und der Mailversand mit SMTP Testtools funktioniert einwandfrei. Darüber hinaus stellte ich exakt den gleichen Fehler mit einer anderen GVS an einem anderen Standort fest.
Zweiter Versuch: Testweise Umstellung auf einen GMX-SMTP --> auch dort kein Versand, aber zumindest eine GNUTLS-Fehlermeldung, die aber auch nicht zu überwinden ist. Sämtliche Einstellungen (auch gem. GVS-Hilfe "durchprobiert" wie angegeben.
Dann mit Wireshark die Kommunikation auf der GVS mitgeschnitten beim Versuch wieder über den originären SMTP Server (1und1) zu senden: Bei der Aushandlung der Authentifizierung meldet der Server gegenüber - Status OK - und dann stellt die GVS die Kommunikation ein und läuft in den Timeout mit oben beschriebenem Verhalten.
Stand der Diagnose:
Bei der Kommunikation mit den ionos/1und1 Servern haben die GVS (unterschiedliche Maschinen) zeigleich Probleme bekommen. Vermutlich gab es eine Umstellung diverser Mailserver im Hinblick auf die Version der TLS Verschlüsselungen. Die Diagnosebene und /-möglichkeiten sind in der GVS leider extrem beschränkt, da keine SMTP Protokollierung ausgegeben wird. Zumindenst aber habe ich nichts dahingehend gefunden.
Mit den Bordmitteln habe ich mit beiden GVS den Mailversand nicht mehr etabliert bekommen!
Vermutung:
1und1 hat alte TLS Protokolle rausgeschmissen und und damit die GVS "ausgesperrt" - komischerweise kommt bei der Aushandlung kein Fehler. Wäre aber das naheliegendste, das zwei unterschiedliche Installationen an verschiedenen Orten, zeitgleich betroffen waren.
Warum nun bei den anderen das GNUTLS Problem auftaucht - ebenfalls bei beiden Installationen - erschliesst sich mir auch nicht.
Lösung:
Habe dann einen "internen hMailserver" aufgesetzt, der auf der Maschine die Mails vom GVS sauber entgegenimmt und dann als "Relay" fungiert und an beliebeige Mailserver mit aktuellsten Verschlüsselungsstandards herausgibt. Das funktioniert einwandfrei, schnell und zuverlässig.
Vorteil: erhöhte Resilienz bei Problemen mit externen Mailservern, falls Makros ausgelöst werden, die eine Mail auslösen. Diese geht dann ungeachtet des finalen Mailversands durch den hMailserver in eine Queue die bei Wiederverfügbarkeit entsprechend abgearbeitet wird und allem voran die GVS nicht weiter "ausbremst bis zum Timeout".
Wunsch @ LCN-Team: >> erhöhte Diagnosefähigkeiten und Auswahl der Verschlüsselungsoptionen (+vllt. Aktualisierung der TLS Standards?) beim SMTP Versand in GVS. Oder ein SMTP Relaydienst mitsamt Protokollierung integrieren. Erleichtert die Diagnose, erhöht Fehlersicherheit. Das nur mal Vorschlag :-)
Viele Grüße
Stephan
P.S: Sorry für den langen Text, aber vielleicht hilft es jemanden bei diesem echt "tricky" Problem.
muss mich an das Thema auch mal "dranhängen".
Bei mir hakte es nun auch gewaltig.
Setup:
GVS mit zahlreichen Makros, die serialisierte Befehle ausführen. Abschluss ist immer eine "Quittung" per E-Mail.
Seit einigen Tagen sind Makros mit extremen Zeitversatz ausgeführt worden und der Bus war per App nicht erreichbar.
Fehler war, dass der E-Mail Versand in einen Timeout gelaufen ist.
Diese Einstellungen funktionierten seit rund 7 Jahren mit tausenden Mails.
Erster Verdacht: Windows steht irgendwo auf dem Schlauch, bzw. die Firewall blockt den SMTP Versand vom GVS Server Dienst.
Ergebnis: alles offen und der Mailversand mit SMTP Testtools funktioniert einwandfrei. Darüber hinaus stellte ich exakt den gleichen Fehler mit einer anderen GVS an einem anderen Standort fest.
Zweiter Versuch: Testweise Umstellung auf einen GMX-SMTP --> auch dort kein Versand, aber zumindest eine GNUTLS-Fehlermeldung, die aber auch nicht zu überwinden ist. Sämtliche Einstellungen (auch gem. GVS-Hilfe "durchprobiert" wie angegeben.
Dann mit Wireshark die Kommunikation auf der GVS mitgeschnitten beim Versuch wieder über den originären SMTP Server (1und1) zu senden: Bei der Aushandlung der Authentifizierung meldet der Server gegenüber - Status OK - und dann stellt die GVS die Kommunikation ein und läuft in den Timeout mit oben beschriebenem Verhalten.
Stand der Diagnose:
Bei der Kommunikation mit den ionos/1und1 Servern haben die GVS (unterschiedliche Maschinen) zeigleich Probleme bekommen. Vermutlich gab es eine Umstellung diverser Mailserver im Hinblick auf die Version der TLS Verschlüsselungen. Die Diagnosebene und /-möglichkeiten sind in der GVS leider extrem beschränkt, da keine SMTP Protokollierung ausgegeben wird. Zumindenst aber habe ich nichts dahingehend gefunden.
Mit den Bordmitteln habe ich mit beiden GVS den Mailversand nicht mehr etabliert bekommen!
Vermutung:
1und1 hat alte TLS Protokolle rausgeschmissen und und damit die GVS "ausgesperrt" - komischerweise kommt bei der Aushandlung kein Fehler. Wäre aber das naheliegendste, das zwei unterschiedliche Installationen an verschiedenen Orten, zeitgleich betroffen waren.
Warum nun bei den anderen das GNUTLS Problem auftaucht - ebenfalls bei beiden Installationen - erschliesst sich mir auch nicht.
Lösung:
Habe dann einen "internen hMailserver" aufgesetzt, der auf der Maschine die Mails vom GVS sauber entgegenimmt und dann als "Relay" fungiert und an beliebeige Mailserver mit aktuellsten Verschlüsselungsstandards herausgibt. Das funktioniert einwandfrei, schnell und zuverlässig.
Vorteil: erhöhte Resilienz bei Problemen mit externen Mailservern, falls Makros ausgelöst werden, die eine Mail auslösen. Diese geht dann ungeachtet des finalen Mailversands durch den hMailserver in eine Queue die bei Wiederverfügbarkeit entsprechend abgearbeitet wird und allem voran die GVS nicht weiter "ausbremst bis zum Timeout".
Wunsch @ LCN-Team: >> erhöhte Diagnosefähigkeiten und Auswahl der Verschlüsselungsoptionen (+vllt. Aktualisierung der TLS Standards?) beim SMTP Versand in GVS. Oder ein SMTP Relaydienst mitsamt Protokollierung integrieren. Erleichtert die Diagnose, erhöht Fehlersicherheit. Das nur mal Vorschlag :-)
Viele Grüße
Stephan
P.S: Sorry für den langen Text, aber vielleicht hilft es jemanden bei diesem echt "tricky" Problem.