Unzustellbarkeitsnachrichten werden von NSP zu Exchange Online nicht mehr zugestellt

[BenKr]

Hallo zusammen,

zunächst zur technischen Konstellation:
- 2 NSP-Server als Basis auf virtuellen Maschinen in Azure
- Ausgehender E-Mail-Versand über TCP Proxy
- E-Mail-System: Exchange Online, Connector mit Transportregel, welche alle ausgehenden Mails über NSP leitet
- KEIN eingehender Connector

Dann die Problematik:
Wenn ich aus Exchange Online eine E-Mail an einen nicht existierenden Empfänger versende, haben wir bislang immer ordnungsgemäß einen NDR vom NSP zurückbekommen. Seit mindestens letzter Woche werden die vom NSP an Exchange Online zurückkommenden Mails jedoch mit folgender Fehlermeldung abgewiesen:

Fehler: ‎550 5.7.509 Access denied, sending domain <Domäne> does not pass DMARC verification and has a DMARC policy of reject‎

Ich habe nun einen eingehenden Connector konfiguriert, der Mails vom TCP Proxy annimmt. Allerdings habe ich hier die IP-Adressen hinterlegt, da ich nicht sehen kann, welches Zertifikat der TCP Proxy verwendet, um sich zu authentifizieren. Das würde ich gern noch auf das Zertifikat umstellen.

Frage 1: Ist das Konstrukt so richtig, dass ich eingehend auch einen Connector bauen muss, damit Nachrichten vom NSP nicht als Spoofing erkannt werden? Oder sollte ich hier noch etwas anderes/zusätzliches konfigurieren (z.B. Mandantenzulassungs-/Sperrliste, Erweiterte Filterung, etc.)?
Frage 2: Welches Zertifikat verwendet der TCP Proxy, damit ich den Connector noch darauf umstellen kann?

Vielen Dank schon mal und viele Grüße!

Ben

 

[StefanCink]

Hallo Ben,
der TCP Proxy nutzt kein eigenes Zertifikat. Der Name ist tatsächlich Programm und es wird auf TCP-Level geroutet. Anders ausgedrückt: Alles was auf den unteren Schichten, inkl. der Applikationsschicht, ausgetauscht wird, sehen wir nicht, wenn es verschlüsselt ist. O365 sieht demzufolge das Zertifikat, das im NoSpamProxy beim Konnektor als Client-ID hinterlegt ist. Und auf das sollte der Eingehende Konnektor in O365 lauschen.
Gruß Stefan

 

[BenKr]

Hi,
ah, Danke für die Erklärung, das macht Sinn.
Was dann keinen Sinn macht: ich habe zwischenzeitlich herausgefunden, dass wir doch schon einen eingehenden Connector konfiguriert hatten, der auf das Zertifikat lauscht, das im NSP hinterlegt ist.
Das funktioniert aber nun nicht mehr - aus Gründen.

Ist Dir irgendwas bekannt, dass Microsoft etwas diesbezüglich umgestellt hat?

VG
Ben

 

[StefanCink]

Hm, aktuell nicht. Ich weiß nur, dass das Zertifikat im nächsten Jahr vermutlich nicht mehr funktionieren wird, weil die Eigenschaft "Client Authentication" noch beinhaltet. Aber das sollte jetzt noch nicht der Grund sein.
Gruß Stefan

 

[MichiH]

Moin Ben,

Du hast nicht zufällig ein frisch (ab ca. Mitte Oktober) ausgestelltes SSL Zertifikat von Sectigo im Einsatz? Die haben die Client EKU, die eigentlich erst im nächsten Jahr wegfallen sollte, schon jetzt aus den neu ausgestellten Zertifikaten rausgenommen.

 

[869288141]

Hallo zusammen,

Du hast nicht zufällig ein frisch (ab ca. Mitte Oktober) ausgestelltes SSL Zertifikat von Sectigo im Einsatz?

andere CAs wie DigiCert oder ssl.com haben die entsprechenden Änderungen ebenfalls bereits umgesetzt. Hintergrund ist der Stichtag 15.06.2026. Der ist keine 6 Monate mehr entfernt.

Aus wirtschaftlicher Sicht ergibt es daher wenig Sinn, heute noch Zertifikate mit TLS Web Client Authentication auszustellen. Als Kunde könnte man gegenüber der CA durchaus argumentieren, dass die Leistung nicht vollständig bzw. nicht mehr sinnvoll erbracht wird.


Gruß,
Daniel