Hallo,
ich habe heute unsere RC100 von 11.5.5 (wo alles tadellos lief) auf die 11.6.1 upgedatet.
Leider musste ich feststellen, dass der Mailversand danach nicht mehr funktionierte. Der interne Queue von der FW ist immer voller gelaufen.
Wir versenden über einen Smarthost und normales SMTP (Port 25).
Die Fehlermeldung im Log (Adressen sind anonymisiert):
2016-01-22T17:51:44+01:00 sm-mta [8149]: u0MGpgRn008141: to=<xxxxxxx@t-online.de>, delay=00:00:02, xdelay=00:00:01, mailer=relay, pri=123047, relay=mail.xxxxxxxxxxxxx.de. [88.888.88.48], dsn=4.0.0, stat=Deferred: Temporary AUTH failure
Das Problem scheint definitiv an der 11.6.1 zu liegen, da es nach einem Fallback auf 11.5.5 sofort wieder funktioniert.
Hat das Problem noch jemand und vor allem ist das Problem Securepoint bekannt?
VG Timm
Smarthost funktioniert nicht mehr nach Update auf 11.6.1
Moderator: Securepoint
Hallo,
komisch, jetzt funktioniert der Versand!!!
Der SMTP Server braucht aber gar kein TLS? Vor 11.6 war da kein Haken drin und es hat immer funktioniert. Bug?
Bei TLS hab ich die Zertifikate auf <default> gelassen, ich schätze es wird ohnehin keine Verschlüsselung stattfinden, oder?
Trotzdem herzlichen Dank, so kann ich die 11.6 laufen lassen.
VG Timm
komisch, jetzt funktioniert der Versand!!!
Der SMTP Server braucht aber gar kein TLS? Vor 11.6 war da kein Haken drin und es hat immer funktioniert. Bug?
Bei TLS hab ich die Zertifikate auf <default> gelassen, ich schätze es wird ohnehin keine Verschlüsselung stattfinden, oder?
Trotzdem herzlichen Dank, so kann ich die 11.6 laufen lassen.
VG Timm
Hallo,
in der 11.5.5 hat sich da der Mailrelay Agent anders verhalten.
Dort hat diese Option, das STARTTLS nur Server seitig an der UTM aktiviert. Der SMTP Client hat STARTTLS verwendet.
In der 11.6 ist diese Option Global (für SMTP Server und Client).
Gruß
Kenneth
in der 11.5.5 hat sich da der Mailrelay Agent anders verhalten.
Dort hat diese Option, das STARTTLS nur Server seitig an der UTM aktiviert. Der SMTP Client hat STARTTLS verwendet.
In der 11.6 ist diese Option Global (für SMTP Server und Client).
Gruß
Kenneth
Hallo,
habe genau das selbe Problem. Nur kann ich es nicht lösen, indem ich den Hacken setze, weil dann der Interne Server der Firewall nichts mehr zustellen kann, dieser unterstützt kein TLS.
Also lasse ich den Hacken weg, kann ich mich am externen Relay nicht anmelden, machen ich den Hacken rein, kann der interne Server der Firewall nicht mehr übergeben. Was nun?
habe genau das selbe Problem. Nur kann ich es nicht lösen, indem ich den Hacken setze, weil dann der Interne Server der Firewall nichts mehr zustellen kann, dieser unterstützt kein TLS.
Also lasse ich den Hacken weg, kann ich mich am externen Relay nicht anmelden, machen ich den Hacken rein, kann der interne Server der Firewall nicht mehr übergeben. Was nun?
Hallo Dietmar,
das sollte an sich keine Probleme machen.
das STARTTLS wird von der Firewall nicht erzwungen sondern Optional angeboten.
Wenn der Server kein STARTTLS kennt, wird dieser unverschlüsselt weiter senden
Gruß
Kenneth
das sollte an sich keine Probleme machen.
das STARTTLS wird von der Firewall nicht erzwungen sondern Optional angeboten.
Wenn der Server kein STARTTLS kennt, wird dieser unverschlüsselt weiter senden
Gruß
Kenneth
Hallo Kenneth,
habe es mehrfach ausgetestet. Wenn ich die TLS Verschlüsselung nicht aktiviere, dann kann ich die Mails nicht an den securesmtprelay von t-online übergeben, im Firewall Protokoll steht was von authentication failure, klar, der t-online Relay möchte die Verschlüsselung.
Wenn ich aber nun den Hacken bei TLS Verschlüsselung setze, funktioniert die Verbindung zum t-online Relay problemlos, aber der interne Mailserver kann die Mails nicht an die Firewall übergeben, sondern bringt einen Fehler, dass die Gegenstelle (also die Securepoint) TLS Verschlüsselung fordert.
Ich komme aus der Zwickmühle nicht raus. Mit der alten Version klappt es, da habe ich den Hacken bei der Verschlüsselung eben nicht gesetzt und er verwendet diese nach außenhin zum T-Online Relay trotzdem, aber fordert diese nicht vom internen Mailserver. Genau dieser Umstand war hier übrigens der Grund, eine Securepoint zu installieren, und zwischen den Mailserver und das T-Online Relay zu hängen.
Danke
Dietmar
habe es mehrfach ausgetestet. Wenn ich die TLS Verschlüsselung nicht aktiviere, dann kann ich die Mails nicht an den securesmtprelay von t-online übergeben, im Firewall Protokoll steht was von authentication failure, klar, der t-online Relay möchte die Verschlüsselung.
Wenn ich aber nun den Hacken bei TLS Verschlüsselung setze, funktioniert die Verbindung zum t-online Relay problemlos, aber der interne Mailserver kann die Mails nicht an die Firewall übergeben, sondern bringt einen Fehler, dass die Gegenstelle (also die Securepoint) TLS Verschlüsselung fordert.
Ich komme aus der Zwickmühle nicht raus. Mit der alten Version klappt es, da habe ich den Hacken bei der Verschlüsselung eben nicht gesetzt und er verwendet diese nach außenhin zum T-Online Relay trotzdem, aber fordert diese nicht vom internen Mailserver. Genau dieser Umstand war hier übrigens der Grund, eine Securepoint zu installieren, und zwischen den Mailserver und das T-Online Relay zu hängen.
Danke
Dietmar
Die UTM erzwingt keine Verschlüsselung. Sie bietet es an. Der Client kann sich dann entscheiden, ob er TLS verwenden möchte oder nicht. Aber wenn er es verwendet, muss es mit einer aktuellen Cipher-Suite erfolgen. Steht da ein Exchange aus dem Jahre 1873, der leider nur RC4 und das nur über SSL2 beherrscht: Schade. Dann wäre der korrekte Ort zur Behebung des Problems aber der Exchange.