• Bewerte uns auf OMR Reviews: Klick

  • 25Reports geht live, schaut es euch an: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagetracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

  • Zertifikate vom Deutschen Forschungsnetz beziehen (Harica CA)? Klick

NSP in Azure mit Postfächern in Exchange Online

plorch1711

Member
Registriert
7 Oktober 2025
Beiträge
11
Reaktionspunkte
4
Hallo zusammen,

wir wollen unseren Mailflow etwas umbauen und haben folgendes Zielbild:

MX -> EOP -> NSP -> Mailbox (Exchange Online)

Generell sollen also alle Mails zuerst zu ExchangeOnline. Dort wird mittels TransportRule und Connector entschieden, ob die Mails zu NSP geroutet werden oder direkt zugestellt werden (dies wird anhand der Empfängerdomain entschieden). Transportrule und Connector zum NSP stehen bereits und ich setzte einen zusätzlichen Header, um Mails, die bereits durch den NSP geroutet wurden nicht erneut auf diesen Weg zu schicken.

Ich benötige jetzt aber Hilfe, wie ich die Mails vom NSP zurück zum Exchange Online Route. Welche Connector muss ich im NSP entsprechend erstellen? Meiner Meinung nach, müsste dies ein Default Connector werden, der * -> Exchange Online sendet.

Danke vorab
Pascal

P.S. wenn ihr eine bessere / einfachere Lösung seht, nehme ich das gerne auch :-)
 
Hey 👋

Ich starte mal mit dem link zur Doku:

In der Cloud Doku haben wir das Parallele Routing für Encryption Only erklärt, das kannst du eig so adaptieren :)

Da du im Protection Bereich den Thread eröffnet hast möchte ich jedoch fragen warum erst EXO und dann NSP?
Du wirst nicht alle Reputationsfilter im NSP sauber nutzen können.
In der Konfiguration würdest du das parallele routing nutzen und dort bekommst du vom NSP einen X-Header den du nutzen musst.

Da ich grade in Urlaub bin wird es mit Screenshots was schwerer ^^

LG
Jan
 
Hallo Pascal,

wir haben das Routing wie folgt:

MX -> NSP -> EXO (Standard für eingehende E-Mails von extern)
sowie
EXO -> NSP -> EXO (interner Traffic welches zwecks E-Mailanhangskontrolle zu NSP geht)

Auch via X-Header und Ausnahme wie du es beschrieben hast,
Wir haben hierfür den Office 365 Konnektor eingerichtet (benötigen wir ja standardmäßig für MX -> NSP -> EXO) und das funktioniert 1A.

Wenn du kein Zert passendes Zertifikat hast, kannst du auch die Lösung von NSP verwenden/ nur auf die IP im Konnektor bei EXO filtern - je nach Anspruch.

Ein Zert will er aber unbedingt am Office 365 Konnektor haben!

Nicht wundern das Direkt oder "Via Office 365" nicht ausgewählt ist, kam erst im Nachgang per Update.
Hier am besten an die Anleitung von Jan halten.
1772814658396.png

LG
Fabian
 
Hi Fabian,

danke für die Info :-)

Die Konfiguration ist erst einmal mein Testsystem und steht neben dem aktuellen ON-Prem NSP.
Weißt du ob es zu Problemen kommen könnte, wenn ich zwei NSP Office 365 Connectoren habe?

VG
Pascal
 
Hallo Pascal,

Solange du die Domänen sauber zuordnest ist das kein Thema ;)

LG
Jan
 
Hallo Pascal,
Generell sollen also alle Mails zuerst zu ExchangeOnline. Dort wird mittels TransportRule und Connector entschieden, ob die Mails zu NSP geroutet werden oder direkt zugestellt werden (dies wird anhand der Empfängerdomain entschieden).
Ich lese hier bislang still mit und frage mich seit dem ersten Tag, warum du dich für genau dieses Design entschieden hast und welche Anforderungen dahinterstehen. Könntest du kurz erläutern, was die Überlegungen dabei waren? Das würde mich und sicher auch andere Mitleser brennend interessieren.


Gruß,
Daniel
 
Logischer und einfacher erscheinen mir diese Wege. Was spricht dagegen?

1. eingehend: MX -> NSP > ExO (+ ggf. Hybrid)
2. ausgehend: ExO -> NSP
 
Hallo Pascal,

Ich lese hier bislang still mit und frage mich seit dem ersten Tag, warum du dich für genau dieses Design entschieden hast und welche Anforderungen dahinterstehen. Könntest du kurz erläutern, was die Überlegungen dabei waren? Das würde mich und sicher auch andere Mitleser brennend interessieren.


Gruß,
Daniel
HI Daniel,

gerne. Ich bin auch für jede Optimierung offen.

Die grundlegende Idee ist, dass all unsere MX Records direkt auf Exchange Online zeigen.
Wir müssen unseren zentralen Netzwerk Standort umbauen und der bisher in der DMZ stehende On-Prem NSP muss abgelöst werden. Wir haben auch keine Möglichkeit einen neuen an diesen Standort zu bringen.

Ich Stand daraufhin vor den beiden Optionen:
  1. NSP als VM in Azure und MX -> Azure Firewall
  2. Direkt MX auf Exchange Online und dann eine einarmige Anbindung des NSP
VG
Pascal

P.S. Option 1 habe ich nicht weiter verfolgt, da ich mehrere IPs an der Azure FW nutze und ein sauberer RDNS durch das automatische IP Round-Robin (ausgehend an der Azure FW) mir da einen Strich durch die Rechnung macht.
 
Wäre als Alternative zu Option 1 nicht NoSpamProxyCloud das Richtige?

Und bei Option 2 frage ich mich, wo der "einarmig" angebundene NSP läuft? Der muss doch auch in Eurer DMZ stehen, um von ExO aus erreichbar zu sein.
 
NSP-Cloud ist je nach gewünschten Funktionsumfang/ Konfigurationsmöglichkeiten keine Option.
Was eine Möglichkeit wäre, wäre der private Stack (NSP-Server betrieben bei NSP selbst).

LG
Fabian
 
HI Fabian,

die Vorgabe ist leider durch die beiden Optionen:
  1. NSP als VM in Azure und MX -> Azure Firewall
  2. Direkt MX auf Exchange Online und dann eine einarmige Anbindung des NSP
vorgegeben.

VG
Pascal
 
Hallo Pascal,

nachdem der Hintergrund deines Routings nun geklärt ist würde ich auf dein ursprüngliches anliegen zurück kommen wollen:
Hallo zusammen,

danke schon mal an alle Helfer
:)

Das wäre der Plan:
Anhang anzeigen 2236

Sieht für mich so weit gut aus - nichts desto trotz einmal testen mit eingeschränkten Nutzerkreis (ETR).
Wie bereits zuvor beschrieben, benötigst du für den Versand an dein "Exchange Online" den Office 365 Connector, für den Empfang beim NSP reicht der reguläre eingehende Konnektor.

Wie von Jan bereits hingewiesen funktionieren mancher Test z.B. Reputationsfilter nicht mehr/ liefern im schlimmsten Falle falsche Ergebnisse - wenn dies in Kauf genommen wird, dann am besten deaktivieren:

1773300115197.pngFür mich ist der größte Fallstrick die Endlosschleife, wenn du die X-Header nicht setzen würdest bzw. die Umleitung dahingehend unterbrichst, aber das hast du ja skizziert.

LG
Fabian
 
Hi Fabian, hi Jan,

da es hier in erster Linie um die Teststellung geht, werde ich es einfach mal für eine Testdomain umsetzen und dann hier die Ergebnisse präsentieren.

VG
Pascal

P.S. war mir gar nicht bewusst, dass dieses Design so ungewöhnlich ist. Bei einem anderen deutschen Hersteller, mit dem ich sonst unterwegs war, gibt es dafür sogar eine Anleitung.
 
Hallo Pascal,
P.S. war mir gar nicht bewusst, dass dieses Design so ungewöhnlich ist. Bei einem anderen deutschen Hersteller, mit dem ich sonst unterwegs war, gibt es dafür sogar eine Anleitung.
Nur weil mein Nachbar jedes Mal gegen die Einbahnstraße fährt, muss ich das nicht auch tun. Deine Aussage ist zunächst einmal sehr pauschal formuliert. Um sie sinnvoll bewerten und vergleichen zu können, wäre es hilfreich zu wissen, auf welche konkreten Produkte oder Szenarien du dich beziehst.

Ein Beispiel, das ich in diesem Zusammenhang gerne bei meinen Studenten verwende, ist die Frage nach dem Unterschied zwischen einem SMTP Proxy und einem SMTP Relay. Wer die richtige Antwort kennt, kann sich ein Eis holen. 🙂

die Vorgabe ist leider durch die beiden Optionen:
  1. NSP als VM in Azure und MX -> Azure Firewall
  2. Direkt MX auf Exchange Online und dann eine einarmige Anbindung des NSP
vorgegeben.
Ich würde Option 1 bevorzugen. Damit kannst du alle aktuellen und zukünftigen Features von NSP vollumfänglich nutzen und das Produkt kann seine Stärken vollständig ausspielen. Allerdings hat das Ganze einen Haken: Port 25/TCP in Azure ist praktisch eine kleine Raketenwissenschaft. Daher wirst du voraussichtlich auf einen TCP-Proxy zurückgreifen müssen.

Abgesehen davon würde mich noch interessieren, woher diese Vorgabe eigentlich kommt, vom Kunden, vom Management deines Arbeitgebers oder von einem Dienstleister bzw. Consultant, der euch beratend zur Seite steht?! Keine Sorge, ich frage nicht aus Neugier, sondern weil der Kontext manchmal hilft, die Entscheidung besser zu verstehen. 😉

Gruß,
Daniel
 
Ich habe mit meinem Kollegen auch darüber gesprochen und werde das dem Azubi auch noch fragen :devilish:
Meine Argumentation wäre:

Ein Proxy (=Stellvertreter) kann den Verkehr filtern und Entscheidungen anhand eines Regelwerkes treffen, ob die Informationen durchgehen oder nicht.
Ein Relay hingegen ist einfach nur eine simple Weiterleitung z.B. ein Mailrelay welcher E-Mails annimmt und weiterleitet.

Ich bin gespannt, was Daniel hierzu sagt.

Diesen Merksatz/ diese Geschichte aus der Ausbildung habe ich noch im Kopf: "Du bist der Erziehungsberechtigte auf der Party von 10 jugendlichen, welche beim Pizzaservice bestellen wollen. Die Bestellung lautet: 10 Pizzen und 2 Flasche Wein. Du entscheidest aber das die Partygäste zu jung für den Wein sind und streichst kurzerhand diese Bestellposten raus. Du rufst beim Pizzaservice an, die Pizzeria spricht mit dir als Proxy. Als es klingelt, übernimmst du die Pizzen an der Haustüre und bezahlst den Lieferboten. Dieser kann sich nun denken, dass du wohl keine 10 Pizzen alleine essen wirst, sieht den Rest der Partygäste aber nicht."

Somit bist du die der Stellvertreter (aka Proxy) der Partygäste, filterst die Bestellung und der Serviceanbieter (der Lieferdienst) sieht die anderen Partygäste nicht.

LG
Fabian
 
Hi Daniel,

danke für deinen Beitrag. Die Optionen 1&2 sind gesetzt durch unsere Gesamtstrategie der IT und der GF.

Wie du bereits schreibst, ist das mit Port 25 in Azure leider grausam und nicht final umzusetzen, daher ist Option 2 ins Spiel gekommen.

Ein ähnliches Produkt, dass so funktioniert ist zum Beispiel Zertificon Z1 (ich weiß, dass dies nahezu ausschließlich für SMIME/PGP genutzt werden kann und nicht vergleichbar mit den Funktionen des NSP ist). Hier kann ebenfalls so implementiert werden MX->EXOnline->Zertificon->Mailbox

ICh werde euch berichten, was dabei herausgekommen ist.

VG
Pascal
 
Zurück
Oben