Exchange Online als Outbound Relay

Diese Seite behandelt den Fall, dass sie ihre On-Premises Mailserver hinter Exchange Online verstecken und ausgehend Mails von ihren lokalen Mailservern oder Mailversendern über Exchange Online in das Internet gehen. Diese Konstellation gibt es mit Exchange Hybrid ebenso wie Firmen, die quasi nur Exchange Online Protection nutzen.

Die Seite entstand aufgrund einer Änderung in Exchange Online, welcher Mitte Jun 2023 veröffentlicht und am 1. Nov 2023 aktiv werden soll.

Relay Szenarien

Wenn Sie Mails von ihrer Domain an Empfänger im Internet senden wollen, dann kann dies ihr Mailserver selbst direkt tun oder sie bedienen sich eines Dienstleisters. Oft verlagern Firmen den Versand über einen Service, welcher auch den Empfang organisiert. Beim Empfang ist ein Spamfilter, Phishing-Schutz und Malware-Filter eigentlich zwingend erforderlich und der Exchange Edge Server ist hier wirklich keine Alternative. Daher gibt es verschiedene Produkt wie z.B. NoSpamProxy u.a., die sie selbst betreiben oder als Cloud-Service einkaufen können. Der MX-Record verweist auf den Service und nur die erwünschten Mails werden an die internen Server zugestellt.

Damit die internen Server ausgehend gar nicht erst mit beliebigen Server im Internet kommunizieren müssen und der Spamfilter auch ausgehend eingreifen kann, senden die meisten Firmen ihre ausgehenden Mails ebenfalls über einen Dienstleister. Oft wird die Funktion mit dem Anhängen eines "Disclaimers", Verschlüsselung per SMIME/PGP, Signierung mittels DKIM und natürlich Spamfilterung verbunden. Schließlich müssen Sie heute schon etwas tun, damit ihre guten Mails auch in der Welt nicht als Spam aussortiert werden.

Microsoft verkauft mit Exchange Online Protection ebenfalls einen Spamfilter "aus der Cloud", der aber auch im Exchange Hybrid-Mode integriert ist und so müssen sie auch hier damit rechnen, dass in lokaler Exchange Server seine Mails ins Internet nicht direkt sondern über Exchange Online versenden soll. Es kann aber auch WebServer und andere Prozesse geben, die ebenfalls Mails mit ihrer Domain versenden.

Wenn ihre Server eindeutig per IP-Adresse oder SMTP-Transportzertifikat identifizierbar sind, dann kann der vorgelagerte Spamfilter z.B. alle Mails von diesen Servern als "Trusted" behandeln. Aber was machen Sie, wenn das Relay ihnen nicht exklusiv gehört, sondern von vielen Kunden genutzt wird und auch mehrere Kunden können den gleichen Maildienstleister nutzen. Nun muss der Spamfilter unterscheiden, von welchem Kunden die Mail kommt und wohin sie geht. Wenn Sie nun vorschnell sich beim Ziel an der "RCPT TO"-Adresse (RFC8532 P1-Envelope) orientieren oder das Ziel anhand der Envelope-Zieladresse (RCPT TO) festmachen, dann denken Sie bitte daran, dass Unzustellbarkeitsquittungen meist mit einem "MAIL FROM:<>" gesendet werden. Auch die Empfänger Adresse im Envelope und Header können abweichen, z.B.: bei Weiterleitungen und Sender Rewriting Scheme (SRS) ist auch noch zu beachten.

Exchange Originating oder Incoming

Wir konzentrieren uns nun aber erst einmal auf Exchange Online bzw. Exchange Online Protection. Exchange Online ist ein "Multi Tenant System" und jede Verbindung per SMTP kommt erst einmal aus dem "Internet". Exchange trennt die eingehenden Verbindungen nicht anhand unterschiedlicher Zieladressen, sondern bestimmt die Richtung anhand verschiedener Kriterien und konfigurierten Konnectoren. Dazu gibt es zwei Richtungen:

  • Originating
    Eine so klassifizierte Mail gilt als "von ihrer eigenen Firma kommend". Der Absender hat also eine Exchange Online Mailbox oder kommt über einen Weg an, so dass Exchange diese Mail als "von intern" ansieht. Die Klassifizierung ist sehr kritisch, denn niemals sollte ein fremder Absender diesen Status erreichen und als "intern" eingestuft werden. Solche Mails werden von Exchange Online dann auch problemlos nach extern gesendet
  • Incoming
    Alle anderen Mails werden anhand der Ziel-Adresse einem Tenant als eingehend zugeordnet und entsprechend behandelt.

Denken Sie daran, dass eine Mail von einem Benutzer in Tenant1 an einen Benutzer in Tenant2  auf dem Weg vom Postfach zum Internet den Status "Originating Tenant1" hat und beim Empfang im Tenant2 als "Incoming" klassifiziert wird. Eine als "Originating" klassifizierte Mails muss immer von einem "authentifizierten Benutzer" oder über einen passenden Connector kommen. Bei den Connectoren kennt Exchange Online auch zwei unterschiedliche "Inbound Connectors". Die "OutboundConnector"-Versionen sind für den Versand ins Internet als Relay nicht weiter relevant.

  • Inbound On-Premises
    Die Mails kommen von einem Mailserver der eigenen Organisation und bekommen daher den Status "originating"
  • Inbound Partner
    Die Mail kommen von einem befreundeten Unternehmen, bei dem z.B. Transportverschlüsselung erzwingt.

Microsoft beschreibt in einem Blog-Artikel recht ausführlich, wann eine Mail als "Originating" eingestuft wird:

Es ist durchaus in Ordnung, wenn Sie den Text mehrfach lesen, ehe Sie die feinen Unterschiede alle verinnerlicht haben.


Office 365 Message Attribution
https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Exchange Online schaut zuerst nach der TLS-Domain aus dem Handshake, um einen "InboundConnector" vom Typ "On-Premises" zu finden und wenn das nicht eindeutig ist, dann filtert er auf die Accepted Domains. Da eine Firma nie ein Zertifikat für eine fremde Domain erhalten sollte, kann so eine saubere Zuordnung erfolgen.

Wenn eine Suche anhand des Zertifikats nicht erfolgreich ist, dann wird die SourceIP-Adresse genutzt. Diese ist aber nicht zwingend eindeutig, denn schließlich kann jeder Administrator mit der gleichen Source IP-Adresse anlegen. In dem Fall nutzt Exchange aber noch die "MAIL FROM"-Domain des Envelope, um den Tenant zu finden. Das funktioniert soweit super, wenn ihr On-Premises Mailserver eine Mail versendet und dabei die "MAIL FROM"-Domain aus ihrem Namensbereich kommt. Hier kommt also nicht die RCP TO-Adresse zur Anwendung. Das erschließt sich nicht immer sofort. Denken Sie etwas drüber nach.

Was in den meisten Fällen funktioniert, kann aber in einigen Fällen versagen, z.B. wenn Sie Mails mit "fremden Domains" oder Subdomains versenden, die nicht als Domain im Tenant hinterlegt sind oder eine Mail weitergeleitet wird oder ihr Mailserver nur die Header-From-Adresse umschreibt aber als Envelope-FROM eine andere Adresse oder "<>" bei einem NDR nutzt.

Um eine sichere Funktion zu erreichen, sollten ihre eigenen Mailserver immer per TLS über Exchange Online versenden und sich mit einem Zertifikat ausweisen, welches zu ihren "Accepted Domains" passt.

Microsoft Change 1. Nov 2023

Für Microsoft als Hoster ist es natürlich risikoreich, einen Relaydienst für Absender bereit zu stellen, der die Absender nicht sicher identifizieren kann. Dann wäre ein Missbrauch auf Kosten von Microsoft möglich. Ein Provider wird alles tun, damit die eigenen Server und IP-Adressen nicht blockiert werden, da dann auch andere legitime und zahlende Kunden betroffen sind. Daher hat Microsoft im Juni 2023 eine kleine aber wichtige Änderung angekündigt, die am 1. Nov 2023 aktiv werden soll.

Bislang musste einen Mail über einen OnPrem-Connector ankommen und zusätzlich die folgenden Bedingungen erfüllen:

Bedingung1: 
   TLS-Zertifikat ist Teil der Accepted Domains
oder
   Envelope-MAILFROM-Absenderdomain ist Teil der Accepted Domains  (P1, Envelope)
oder
 Header-FROM-Absenderdomain  ist Teil der Accepted Domains (P2, Header)

UND 
  SenderIP oder TLS-Zertifikat  ist Teil der Accepted Domains

Zum 1. Nov 2023 wird Microsoft das Kriterium "P2" entfernen, so dass dann folgende Logik aktiv ist.

Bedingung1: 
   TLS-Zertifikat ist Teil der Accepted Domains
oder
   Envelope-MAILFROM-Absenderdomain ist Teil der Accepted Domains  (P1, Envelope)
oder
 Header-FROM-Absenderdomain  ist Teil der Accepted Domains (P2, Header)

UND 
  SenderIP oder TLS-Zertifikat  ist Teil der Accepted Domains

Ich bin noch nicht ganz dahinter gekommen, warum diese Änderung nun erfolgt, denn als "böse Person" sind die neuen Bedingungen nicht schwerer als die alten Bedingungen. Ich hole mir einen Test/Dev-Tenant, registriere eine Domain , addiere einen Connector und hinterlege eine Source-IP eines ebenso gekaperten Systems und sende die Mails mit dem passenden Envelope MAIL-FROM dieser Domain. Den "Header-From" brauche ich gar nicht und wenn ich eine Phishing-Mail versenden möchte, dann würde ich im "Header-From" ja eine für den Empfänger vertraute Adresse verwenden.

OK und Fail

Schauen wir uns mal ein paar übliche Beispiele an, und wie sich die Änderung auswirkt, wenn Sie bisher einen On-Premises-Connector hatten, der die Mails als "Originating" anhand des Zertifikats oder Source-IP und MAIL FROM klassifiziert hat.

Szenario Vor 1. Nov 2023 Nach 1. Nov 2023 Beschreibung

Exchange On-Premises sendet Mails per TLS mit Firmenzertifikat über Exchange Online ins Internet

OK

OK

Die Mail wird ins Internet als Relay weiter gesendet, da das Zertifikat passt.

Sendmail, Postfix o.ä.  On-Premises sendet Mails per TLS mit Firmenzertifikat über Exchange Online ins Internet

OK

OK

Die Mail wird ins Internet als Relay weiter gesendet, da das Zertifikat passt.

3rd Party Mailservice in der Cloud sendet Mails per TLS mit Providerzertifikat über Exchange Online ins Internet

OK

Prüfen

Sie können den Provider über die IP-Adresse als "On-Premises" klassifizieren, wenn als Absender eine Adresse ihrer Domain als "MAIL FROM" genutzt wird. eintragen aber der Provider muss auch im Envelope die MAIL FROM-Adresse ihrer Domain verwenden. Alternativ kann der Dienstleister die Mails selbst versenden. Denken Sie dabei aber SPF, DKIM, DMARC.

Drucker im LAN (Scan2 Mail) sendet per SMTP ohne TLS an den Tenant

OK

OK

 Kein Problem, da kein Relay. Sie sollten aber per "Inbound-Connector" und vielleicht EXO Enhanced Filtering verhindern, dass die Mail als Spam klassifiziert wird.

PowerShell-Script sendet ohne TLS eine Mail an einen externen Dienstleister

OK

Prüfen

Die IP-Adresse mag passen aber stellen Sie sicher, dass auch der Envelope-Mail From eine Adresse aus ihren Domains hat.

Eine Mail an den OnPremises-Server wird mit einem NDR quittiert. Der "Absender" eines NDR ist "NULL"  oder "<>", so dass die Regel "P1-MailFrom" nicht triggert.

OK

Prüfen

Funktioniert nur, wenn Exchange Online einen Inbound-OnPremises-Connector hat, der anhand des Zertifikats angewendet wird.

Das sind natürlich nur ein paar Fälle und aktuell gibt es wohl keinen Report oder Alert, wenn eine Mail eingeliefert wird, die nach dem 1. Nov 2023 nicht mehr weitergeleitet würde.

Vorbereitung

Alles Schimpfen hilft aber nicht, denn die Änderung wird wohl kommen und wir sollten mehrere Aktionen anstoßen.

Diese Prüfungen sind nur für Mails relevant, bei denen ein Absender außerhalb von Exchange Online eine Mail über Exchange Online an Empfänger bei anderen Firmen, also im Internet, senden. Dies ist nicht erforderlich, wenn der Absender ein Exchange Online Postfach per Outlook, OWA oder SMTP AUTH nutzt oder der Zielempfänger im Tenant ist.

  • Authentifizierung per TLS-Zertifikat aus einer "Accepted Domain"
    Wenn alle einliefernden Systeme sich mit einem TLS-Zertifikat per SMTP authentifizieren, dann ist die Zustellung an den Tenant als auch über den Tenant ins Internet gesichert. Das wäre auch meine Empfehlung, sofern dies möglich ist.
  • Alternativer Versand mit IP und Envelope From
    Alle anderen Systeme sollten darauf geprüft werden, welche Absenderadresse sie im SMTP-Dialog verwenden. Nur wenn Sie eine Adresse aus einer "Accepted Domain" verwenden und es einen "Inbound On-Premises"-Connector mit der IP-Adresse gibt, dann wird die Mail auch weiter verteilt.
  • Aufbau eines eigenen Relays
    Wenn Sie im LAN viele Systeme haben, die TLS nicht können und deren Absender nicht korrigierbar ist, dann kann ein lokales SMTP-Relay helfen, welches die Mails intern annimmt und dann per TLS an Exchange Online weiterleitet. Das bedeutet allerdings den Betrieb eines entsprechenden Servers mit Zertifikat und eine Konfigurationsänderung an allen Systemen, die Mails bislang an Exchange Online direkt senden.
  • Überwachung der NDRs ab 1. Nov 2023
    Sie sollten spätestens bei der Aktivierung einen Blick auf ihre Transport-Statistiken werfen, ob die Anzahl der NDRs hochgeht. Allerdings können Sie dies nicht in Exchange Online sehen, da Microsoft die Mails die Mail "ablehnen" will. Sie müssten daher die Systeme überwachen, die eine Zustellung an Exchange Online versuchen und dort prüfen, ob die Mails in Warteschlangen stehen bleiben oder einfache Skripte einen Fehler melden.

Weitere Links