Gelöst force secure connection to partner

[JD168]

Hallo,

ein Partner nimmt nur noch E-Mails an, die über eine sichere Verbindung zusgestellt werden.
Sonst kommt "553 5.7.3 A secured connection (either via StartTLS or SMTPS) is required for this recipient."

Nun habe ich in den Partnereinstellungen die Transportsicherheit auf erforderlich gestellt und einen extra Sendekonnektor für die Zieldomäne erstellt.
Ausgehende E-Mails gehen auich über diesen KOnnektor, aber dennoch werden die E-Mails "nicht sicher" verschickt.
Was habe ich übersehen, wo liegt mein Gedankenfehler?

 

[869288141]

Hallo,
welche Version von NSP kommt aktuell bei dir zum Einsatz?

ein Partner nimmt nur noch E-Mails an, die über eine sichere Verbindung zugestellt werden.

wir reden von einer Transportverschlüsselung oder wirklich von verschlüsselten E-Mails? Sind zwei paar Stiefel. ich würde behaupten, wenn du keine Transportverschlüsselung machen würdest, hättest du ganz andere Probleme.

Der 1. Screenshot ist klar.
Der 2. Screenshot möchtest du das Verfahren wählen. Hast du mal SMTPS ausprobiert. Geht das auch nicht?
Der 3. Screenshot ist als die E-Mail über den neuen Konnektor gegangen ist oder üb den Standard?

Abgesehen davon, was steht den an der Gegenstelle für ein SMTP-Server, auch ein NSP?


Gruß,
Daniel

P.S. Wenn ich noch Cipher Suites mit *CBC* lese, läuft es mir den Rücken runter...

 

[Sören]

Abgesehen davon, was steht den an der Gegenstelle für ein SMTP-Server, auch ein NSP?

klingt zumindest so anhand des error code

ein Partner nimmt nur noch E-Mails an, die über eine sichere Verbindung zusgestellt werden

was ich mir vorstellen könnte: der Partner hat seinen Server so stark gehärtet, das der vlt. sogar TLS 1.3 oder TLS 1.2 mit GCM erfordert, euer Windows Server das aber nicht kann... eingerichtet hast du erstmal alles richtig.

du könntest mal mit https://www.checktls.com/ den Mail Test machen, dann siehst du, was der andere Server überhaupt anbietet und dann könntest du mal schauen, was euer Server überhaupt kann

 

[869288141]

was ich mir vorstellen könnte: der Partner hat seinen Server so stark gehärtet, das der vlt. sogar TLS 1.3 oder TLS 1.2 mit GCM erfordert, euer Windows Server das aber nicht kann... eingerichtet hast du erstmal alles richtig.

Was dann aber deine/unsere Theorie widersprechen würde, weil Windows Server kann eigentlich mit CGM umgehen.

 

[Fabian]

P.S. Wenn ich noch Cipher Suites mit *CBC* lese, läuft es mir den Rücken runter...

Hehe.... Hatte aber auch schon den Fall das der Zielserver bessere Standards "können sollte", jedoch auf den letzten, lausigsten CBC-Cipher runter gehandelt hat

Gegentest: Einmal von einem Freemailer z.B. Gmail schicken und die Header prüfen wie die beiden Parteien zusammen gekommen sind?

Hat es jemals funktioniert (in der Vergangenheit) oder noch nie?
Klappt der Versand eingehend, an dich?

LG
Fabian

PS. Meiner Recherche nach bietet das Ziel nur CCM, GCM, Poly etc. mit TLS 1.2/1.3 an.
=> Kein CBC

Wobei das ja das Problem noch nicht löst

 

[869288141]

Was dann aber deine/unsere Theorie widersprechen würde, weil Windows Server kann eigentlich mit CGM umgehen.

Die Gegenstelle ist kein NSP. Der Server hat eine IPv6 Adresse. Schöne Grüße an die Produktentwicklung.
Sowie ich das sehe ist das ne Mailcow.

PS. Meiner Recherche nach bietet das Ziel nur CCM, GCM, Poly etc. mit TLS 1.2/1.3 an.
=> Kein CBC

Recht hast du. Die Gegenstelle bietet folgende Konfiguration an:

TLSv1.3
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256


TLSv1.2
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256


SUPPORTED PROTOCOLS
TLSv1.2
TLSv1.3


DIFFIE-HELLMAN PARAMETER SIZE
Diffie-Hellman parameter size: 2048 bits


SUPPORTED ELLIPTIC CURVES
P-256 (prime256v1) (256 bits)
P-521 (secp521r1) (521 bits)
P-384 (secp384r1) (384 bits)
X25519 (253 bits)
X448 (448 bits)

Das sollte ein aktueller Windows Server (2019, 2022 und 2025) können. Setzt natürlich voraus, dass man die Konfiguration immer dem Stand der Technik anpasst.

D.h. der 4. Screenshot (sprich der letzte) bezieht sich auf die Kommunikation zwischen Mail-Server und NSP und nicht auf NSP zum Zielserver. Anderes kann ich mir das gerade nicht erklären.

 

[Sören]

D.h. der 4. Screenshot (sprich der letzte) bezieht sich auf die Kommunikation zwischen Mail-Server und NSP und nicht auf NSP zum Zielserver. Anderes kann ich mir das gerade nicht erklären.

falsch, steht ja auch im Screenshot das es um die Destination geht ^^

der interne Mailserver konnte die Mail abgeben und wie hier zu erkennen war, hat der nur CBC gemacht... daher liegt es aus meiner Sicht nahe, da die Destination kein CBC kann, der NSP schlicht kein GCM beherrscht. Entweder ist der Server sehr sehr alt oder man hat GCM abgedreht auf dem Server mit dem NSP.

 

[Fabian]

falsch, steht ja auch im Screenshot das es um die Destination geht ^^

der interne Mailserver konnte die Mail abgeben und wie hier zu erkennen war, hat der nur CBC gemacht... daher liegt es aus meiner Sicht nahe, da die Destination kein CBC kann, der NSP schlicht kein GCM beherrscht. Entweder ist der Server sehr sehr alt oder man hat GCM abgedreht auf dem Server mit dem NSP.

Sicher?

Es kann doch ein interner Server mit CBC an den NSP herantreten und dieser mit einem anderen Cipher den Zielserver verschicken!

Wäre mir neu das die Kette interner Client, NSP, Ziel alle den gleichen Cipher sprechen müssen ??

LG
Fabian

PS:
Wobei das natürlich die Theorie befeuern könnte, das schon der NSP nur CBC anbietet und das wäre des Rätsels Lösung.

Wollte nur aufzeigen, das der interne Client ggf. nur CBC kann... Etwas Kaffeesatzlesen.

@JD168 Kann dein NSP TLS 1.3 bzw. TLS 1.2 mit GCM, btw. welcher Windows Server kommt zum Einsatz (2019/2022/2025)?

Gibt es hierzu Nachweise in der Nachrichtenablaufverfolgung, erfolgreiche Beispiele?

I.d.R. sind Freemailer/ Microsoft ein guter Anhaltspunkt um das zu prüfen.

Sonst einmal die Datenbank anschauen

 

[Sören]

Es kann doch ein interner Server mit CBC an den NSP herantreten und dieser mit einem anderen Cipher den Zielserver verschicken!

Klar kann er das...aber in der Regel handelt der Client immer das Beste aus.... wenn hier das Beste CBC war, würde es erklären, warum der Server ausgehend nicht mit einem Server sprechen kann, der nur GCM und aufwärts kann.

Wäre mir neu das die Kette interner Client, NSP, Ziel alle den gleichen Cipher sprechen müssen ??

habe ich auch nicht behauptet ^^

 

[JD168]

Hallo,

vielen Dank fuer die Tips und Hinweise. Nach Anpassungen der Cipher klappte es weiterhin nicht.
Kurz: Nach Installation eines neuen 2022 Servers mit der NSP Version 15.5.0.1910 klappt nun der Versand direkt auf verschlüsseltem Weg.

Viele Grüße

 

[869288141]

vielen Dank fuer die Tips und Hinweise. Nach Anpassungen der Cipher klappte es weiterhin nicht.

Was für eine Windows Version ist bzw. war den in Verwendung?