Gelöst MS365-Distribution-Lists von extern nach extern via NSP

[Fabian_FD]

Hallo Zusammen,

bei uns ist die Anforderung aufgekommen, dass MS365-Verteilerlisten (effektiv e-Mail Weiterleitungen) von extern nach extern funktionieren müssen und über den NSP geroutet werden sollen (eingehend wie ausgehend).

Hintergrund: Es gibt Personen welche eine e-Mail-Adresse bei uns vorname.nachname@firma.com erhalten, die E-Mails jedoch auf ein externes (privates) Postfach z.B. privat@gmail.com zugestellt werden müssen. Wenn nun unsere (cloud) HR-Lösung von hr-info@hrsystem.com an vorname.nachname@firma.com eine Mail verschickt, wird diese korrekt an MS365 weitergeleitet. Dort wird die Verteilerliste abgearbeitet und die e-Mail wird mit unverändertem Absender an privat@gmail.com gesendet.

Der Message Trace in MS365 zeigt dann an, dass der NSP die Mail ablehnt (5.4.4 Unable to relay).

Der Office365-Eintrag im Routing lässt in der Konfiguration nicht zu, dass beliebige Absender erlaubt sind (was hier notwendig wäre). Tatsächlich wird dieses Szenario in der Doku "vermieden" in dem man der Transportregel in MS365 verbietet über den NSP zu versenden, wenn die Mail über dessen IP empfangen wurde (Punkt 7 https://docs.nospamproxy.com/Server...NoSpamProxy/Eine-Transportregel-erstellen.htm).

Gibt's dafür eine Lösung oder muss bei so einer external-to-external Lösung der Mailversand zwingend direkt über MS365 laufen, ohne NSP als Smarthost dazwischen haben zu können?

viele Grüße
Fabian

 

[JanJäschke]

das geht nur mit vielen Hürden die absichtlich da sind.
Ich kann nur dringlichst davon abraten Verteilerkasten so zu verwenden. Nicht ohne Grund möchte MS dies selbst abschaffen.
Ihr holt euch mehr Ärger ins Haus als das es Nutzen hat.

Die einzigste korrekte Lösung lautet: SRS
O365 kann es und in der Regel gibt es keinen Grund dies nicht zu aktiviere.
Damit habt ihr einen sauberen Absender aus eurer Domäne heraus und das Empfänger System kann an den korrekten externen Absender antworten

 

[Fabian_FD]

Ja, dass es zu Problemen mit SPF und sonstwas kommen kann ist mir klar. Tatsächlich ist external-to-external recht neu und SRS hört sich erstmal sehr gut an.

Vielen Dank für den Tip!

 

[JanJäschke]

Gerne
Berichte gerne für die anderen was deine Erfahrung ergibt.

 

[Fabian]

Guten Abend Fabian,

ich habe das Routing in EXO selbst angelegt (Annahme du hast es via dem Skript/ der Doku angelegt?) und habe folglich diese Restriktion mit der Ausnahme der Quell-IP in der Nachrichtenflussregel nicht - das wäre für mich eine Lösung, einfach die Ausnahme entfernen bzw. die Regel an deinen Bedarf anpassen.

Bei mir war es der Hintergrund den Inhaltsfilter für den internen E-Mailfluss einzubinden... Noch ein X-Header gegen eine Endlosschleife und läuft

LG
Fabian

 

[Fabian_FD]

Guten Abend Fabian,

tatsächlich hatte ich die IP-Limitierung bereits entfernt, da ich ansonsten ja garkeinen Mailflow dieser "Weiterleitungsnachrichten" über den NSP-Outbound Connector hinbekommen würde. Ich habe mir zu SRS gerade den tollen Artikel auf MSXFAQ https://www.msxfaq.de/cloud/exchangeonline/transport/exo_srs.htm durchgelesen, der weiter unten exakt mein Problem beschreibt. SRS sollte eigentlich standarmäßig für Verteiler aktiv sein, tatsächlich führt MS aber einen SPF-Check durch und nur wenn der validiert wird SRS verwendet.

Da ich den Inbound IP-Skip im Enhanced Filtering noch nicht aktiv hatte, ist der SPF-Check natürlich automatisch für alle vom NSP eingelieferten Mails gefailed und damit war SRS nicht aktiv. Die goldene Lösung scheint das insgesamt aber auch noch nicht zu sein, da es ja auch Absender ohne SPF geben könnte...

Aktuell tendiere ich daher zu einem "geht technisch nicht wirklich sinnvoll anders" und lasse die mail direkt MS365 ins Internet...

In jedem Fall mal wieder vielen Dank an Frank Carius für den wirklich ausführliche MSXFAQ-Artikel dazu!

Edit: jetzt lese ich auch gerade noch https://techcommunity.microsoft.com/blog/exchange/sender-rewriting-scheme-upcoming-changes/2632829 und sehe dass man SRS wohl für company connectors enforcen kann...

viele Grüße

Fabian

 

[Fabian_FD]

So noch ein kurzes Update bevor ich mich in den Feierabend verabschiede ;-)

via Exchange-Online Powershell:

Set-OutboundConnector -Identity "<name des connectors>" -SenderRewritingEnabled $true

konnte ich recht schmerzfrei SRS auf dem Connector zum NSP aktivieren, ein Test war sofort erfolgreich.
Ein Update diesbezüglich in der Office365 Doku bzw. den Power-Shell-Scripten wäre für den einen oder anderen Neukunden sicherlich hilfreich ;-)

 

[Fabian_FD]

Hallo zusammen,

eine kleine Ergänzung habe ich noch:
Das Aktivieren von SRS auf dem Outbound-Connector zur eigenen Firma ändert nicht grundsätzlich wann SRS von EXO verwendet wird, sprich die Regeln zur SPF-Prüfung etc. bleiben alle gültig.

Meine ersten Tests waren insofern erfolgreich, als dass die verwendeten "externen" Domains alle unter meinen Kontrolle waren und auch den NSP als SPF gesetzt hatten. Echte Mails von außen schlugen in einem ersten Test noch fehl, weil aufgrund der fehlenden SPF-Validierung SRS nicht angewandt wurde -> Relay Denied.

Eigentlich hatte ich unter security.microsoft.com in den "Enhanced Filtering for Connector" Einstellungen "Automatically detect and skip the last IP-Adress" aktiv, das hat aber einfach keine Wirkung gezeigt (lässt sich schön im Header nachvollziehen). Die Option "Skip these IP-Adresses..." und dort dann die NSP IP eingetragen hat schließlich zum finalen Erfolg geführt.

Bleibt natürlich das Rest-Risiko dass Versender ohne SPF dann abgewiesen werden... das ist aber für unseren Anwendungsfall hier egal.