Nach Umstellung auf neuen TCP Proxy keine Zustellung ausgehender Mails mehr

[BenKr]

Hallo zusammen,

Setup:
- 2 NoSpamProxy-Server in HA-Konfiguration in Azure
- Nutzung des TCP Proxy über Konfigurationsdatei
- Ports sind nach außen offen (443, Port 25 wird bekanntermaßen von Azure blockiert)

Ich habe gemäß der Dokumentation versucht, den TCP Proxy auf die neue Variante umzustellen. Das Entfernen aus der Konfigurationsdatei klappt ebenso wie das Absetzen der PowerShell-Befehle.
Sobald ich dies tue, stoppt jedoch die Zustellung externer Mails, sie stehen im Message Tracking dann alle mit dem Status "Delivery Pending". Sobald ich wieder auf die alte Variante zurückschwenke, läuft die Zustellung nach und nach wieder an. Es wirkt so, als könnten die NSP-Server den TCP Proxy nicht erreichen.

Haben wir noch irgendwas beim Setup vergessen oder hat jemand eine Idee, was das sein könnte?

VG
Ben

 

[869288141]

Hallo Ben,

Sobald ich dies tue, stoppt jedoch die Zustellung externer Mails, sie stehen im Message Tracking dann alle mit dem Status "Delivery Pending".

hast du

• Punkt 1 ( Root CA Zertifikat ablegen)
• Punkt 3 (Servername auf outboundproxy.nospamproxy.com ändern)

aus der verlinkten Dokumentation auch durchgeführt?

Es wirkt so, als könnten die NSP-Server den TCP Proxy nicht erreichen.

Kannst du ganz simpel mit dem Powershell cmdlet Test-Netconnection von beiden VMs verifizieren. Klappt das?


Gruß,
Daniel

 

[BenKr]

Hi Daniel,

ja, alle Schritte gemäß Anleitung wurden durchgeführt und geprüft.

Der PowerShell-Test schlägt fehl (TcpTestSucceeded: False). Wir haben jedoch keinerlei Beschränkungen für ausgehenden Netzwerkverkehr auf diesen VM. Es könnte aber auch sein, dass der TCP Proxy nicht auf solche Anfragen reagiert, da die Verbindung mW von NoSpamProxy getunnelt wird (vielleicht sind da noch andere Mechanismen beteiligt?).

VG
Ben

 

[869288141]

Hallo Ben,

Der PowerShell-Test schlägt fehl (TcpTestSucceeded: False).

aus deiner Rückmeldung geht leider nicht hervor, welchen FQDN du verwendet hast. Nachstehend ein Beispiel, damit wir alle vom Gleichen sprechen.

Test-NetConnection -ComputerName "proxy.nospamproxy.com" -Port 443

ComputerName     : proxy.nospamproxy.com
RemoteAddress    : 3.126.187.89
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.87.78
TcpTestSucceeded : True

Wenn das bei dir nicht funktioniert, blockiert ein Proxy/Firewall den Request. Weil ein TCP Handshake muss funktionieren.

Gruß,
Daniel

 

[BenKr]

Hi,
ich habe den Namen outboundproxy.nospamproxy.com verwendet.

Dann probiere ich es Morgen nochmal mit proxy.nospamproxy.com.

Allerdings ist dieser Eintrag aktuell in der Konfigurationsdatei gesetzt (= alte Konfigurationsvariante). Daher nehme ich an, dass die Verbindung an sich eigentlich passt.

Was ist denn technisch der Unterschied zwischen der Konfiguration in der config-Datei und dem Connector?

VG
Ben

 

[869288141]

Hallo Ben,

Allerdings ist dieser Eintrag aktuell in der Konfigurationsdatei gesetzt (= alte Konfigurationsvariante). Daher nehme ich an, dass die Verbindung an sich eigentlich passt.

das sehe ich von hier aus nicht. Du kannst es aber natürlich gerne ausprobieren. Das Ergebnis kennen wir vermutlich beide schon.
Ich würde an deiner Stelle nun einen Support Case erstellen. Ich bin mit meinem Ideen am Ende.


Gruß,
Daniel

 

[BenKr]

Hi,
ich habe es ausprobiert. Erwartungsgemäß klappt hier der Verbindungsaufbau.
Dann bemühe ich mal den Support, danke Dir für Deine Unterstützung! Ergebnis gibt es hier, wenn eines vorliegt.

VG
Ben

 

[JanJäschke]

Hey,

Probier mal ob die IP direkt geht.
Hatten jetzt erst einen Kunden wo die Azure Firewall die IP nicht erlaubt hat aber den DNS Namen.
Da unterscheidet sich irgendwie unsere Implementierung weshalb das Verhslten für Azure dann unterschiedlich ist, frag mich nicht was genau da im Azure passiert
Nach dem er aber IPs und Namen des TCP Proxy (proxy.nospamproxy.com) freigegeben hat ging’s ^^

 

[BenKr]

Hi,
alles klar. Nach Logik frage ich bei Microsoft nicht mehr. ;-)

Ich bin allerdings etwas irritiert. Aktuell haben wir ausgehend keinerlei Beschränkungen. Ich kann auch über Port 443 problemlos eine Verbindung über den DNS-Namen aufbauen.

Was genau soll ich ausprobieren bzw. in NSP einstellen?

VG
Ben

 

[Plexi]

Kurzer Hinweis: Den gleichen Fall habe ich bereits im Juli 2025 dem NSP Support geschildert (Ticket NAW-85456-Y5G0B2), da hieß es dann nur das wird voraussichtlich mit Version 16 behoben.

• internal Backlog Item 45604

Ist also nach meinem Verständnis bereits in Arbeit.
Solange der *alte* TCP-Proxy nicht vorher abgeschaltet wird, ist alles gut.

 

[869288141]

Hallo Plexi,

Solange der *alte* TCP-Proxy nicht vorher abgeschaltet wird, ist alles gut.

Soweit ich Ben weiter oben verstanden habe, bleibt der DNS-FQDN unverändert. Geändert wird lediglich die Art der Konfiguration.


Gruß,
Daniel

 

[869288141]

Hallo Ben,

alles klar. Nach Logik frage ich bei Microsoft nicht mehr. ;-)

wer in die Cloud geht, muss die Schmerzen auch aushalten können.

Was genau soll ich ausprobieren bzw. in NSP einstellen?

Wenn ich Jan richtig verstanden habe, solltest du den FQDN proxy.nospamproxy.com durch die IP-Adresse 3.126.187.89 ersetzen und es dann noch einmal versuchen.


Gruß,
Daniel

 

[869288141]

Hallo Jan,

Nach dem er aber IPs und Namen des TCP Proxy (proxy.nospamproxy.com) freigegeben hat ging’s ^^

Hast du bzw. der Kunde im Ticket zufällig dokumentiert, was genau zu tun ist? Das könnte man dann auch in eure Doku ergänzen.


Gruß,
Daniel

 

[BenKr]

Hallo zusammen,

Soweit ich Ben weiter oben verstanden habe, bleibt der DNS-FQDN unverändert. Geändert wird lediglich die Art der Konfiguration.

ja, das sehe ich auch so.

Ich habe jetzt einen Support Case offen und dort auch den Hinweis von Plexi weitergegeben. Wir sind gerade dabei, die Konfiguration der Connectors zu prüfen, ggf. fehlt da noch irgendein Wert. Wenn es wieder ein Update gibt, gebe ich Bescheid!

VG
Ben

 

[869288141]

Hallo Ben,
gibt es inzwischen Neuigkeiten zu der Problematik?


Gruß,
Daniel

 

[BenKr]

Hi,
der Support hat sich den Inhalt der SQL-Tabellen geben lassen, in denen die Konfiguration des Inbound-Connectors angegeben ist. Ich warte noch auf weitere Rückmeldung.

VG
Ben

 

[BenKr]

Hallo zusammen,

mittlerweile habe ich ein Feedback - ich habe den Eintrag in SQL wie folgt aktualisiert:
UPDATE Configuration.InboundSendConnector
SET
SerializedConfiguration = '{ "$type": "Office365InboundSendConnectorConfiguration", "identityMode": "None", "cost": 50, "id": 0, "name": "Office 365", "tcpProxyMode":"UseCustom", "tcpProxyHost":"proxy.nospamproxy.com", "tcpProxyPort":443}'
WHERE
Id = 1;

Wir müssen jetzt noch schauen, dass wir ein Wartungsfenster planen, in dem wir nochmal eine Umstellung des Proxys vornehmen. Ich melde mich dann nochmal, sobald wir das durchgeführt haben.

VG
Ben

 

[BenKr]

Hallo zusammen.

ich habe heute nochmal einen Versuch durchgeführt, das Ergebnis ist unverändert. Nach Umstellung können Mails nicht mehr zugestellt werden. Mal sehen, wie es weitergeht.

VG
Ben

 

[869288141]

Guten Abend Ben,

mittlerweile habe ich ein Feedback - ich habe den Eintrag in SQL wie folgt aktualisiert:

möchtest du zum Vergleich auch die bisherige bzw. vorherige Konfiguration nennen? Würde mich interessieren, welche Werte genau angepasst wurden.

Gruß,
Daniel

 

[BenKr]

Hi,
so war der Eintrag vorher:

ID: 1    {"$type":"Office365InboundSendConnectorConfiguration","identityMode":"None","cost":50,"id":0,"name":"Office 365"}


VG Ben