NSP in Azure mit Postfächern in Exchange Online

[plorch1711]

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

 

[JanJäschke]

Hey

Ich starte mal mit dem link zur Doku:

Microsoft 365 als Relayhost freigeben

docs.nospamproxy.com

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

Manual setup

docs.nospamproxy.com

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

 

[Fabian]

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.


LG
Fabian

 

[plorch1711]

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

 

[JanJäschke]

Hallo Pascal,

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

LG
Jan

 

[plorch1711]

Hallo zusammen,

danke schon mal an alle Helfer


Das wäre der Plan:

 

[869288141]

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

 

[Sakul]

Logischer und einfacher erscheinen mir diese Wege. Was spricht dagegen?

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

 

[plorch1711]

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.

 

[Sakul]

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.

 

[plorch1711]

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.

Hi,
das ist eine Azure VM

 

[Fabian]

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

 

[plorch1711]

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