MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

High Risk Delivery Pool mit Exchange Online

Microsoft veröffentlicht IP-Adressen, mit denen Exchange Online seine Mails in das Internet und zu lokalen Servern sendet. Das ist aber nur die halbe Wahrheit und eine Beschränkung in Firewalls auf diese Adressbereiche kann wichtige Mails blockieren

SMTP-IP-Adressen mit Exchange Online

Wenn Sie Mails zu Exchange Online senden wollen, dann können Sie per DNS einfach die Endpunkte ermitteln. "outlook.office.com" ist ein legitimer Punkt für alle Clients, die per Authentifizierung auf Exchange Online zugreifen, während Mailserver sich über den MX-Record finden. Die eigentliche Kommunikation erfolgt dann wieder über TCP/IP und entsprechende IP-Adressen und Ports. In Firewalls und IPS-Systemen werden daher gerne die IP-Adressen von Diensten zur Filterung und Account herangezogen. Microsoft veröffentlicht die Exchange Online Adressen auf ihrer Webseite


Quelle: Microsoft 365 URLs and IP address ranges https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide

Wer die Daten gerne automatisch abrufen möchte, kann auch  die REST-API nutzen. Hier ein Beispiel:

#JSON-Liste von Microsoft laden
$ips= Invoke-RestMethod https://endpoints.office.com/endpoints/Worldwide?ClientRequestId=b10c5ed1-bad1-445f-b386-b919946339a7 

# Regeln mit den IP-Adressen von Port 25 ausgeben
($ips | where {$_.tcpports -eq "25"}).ips

Wenn Sie nun aber in ihrer Firewall diese IP-Adressen und Port 25 für eine Server-zu-Server-Kommunikation freischalten, dann funktionieren viele aber leider nicht alle Mails und es fällt auch nicht einmal sofort auf.

Outbound Pool

Neben den offiziellen IP-Adressen nutzen die Exchange Server zum Versand auch noch andere IP-Adressen, die in keiner Liste öffentlich sind. Das Verhalten ist von Microsoft auch dokumentiert.

To prevent our IP addresses from being blocked, all outbound messages from Microsoft 365 datacenter servers that are determined to be spam are sent through the high-risk delivery pool.
Quelle: Outbound delivery pools
https://learn.Microsoft.com/en-us/defender-office-365/outbound-spam-high-risk-delivery-pool-about

Da die Gegenseite auch mit IP-Blocklisten und Reputationen/Klassifizierungen arbeitet, möchte Microsoft sicherstellt, dass gewisse Nachrichten nicht die Hauptadressen nutzen. Das Risiko besteht einfach, dass eine schlechte Mails dazu führen kann, dass die IP-Adresse dann auf Blocklisten landet und damit Exchange Online über diese Adresse keine Mails mehr senden kann. Das wirkt sich dann auch auf alle Tenants in der Region aus. Microsoft unterscheidet dabei nach:

  • High-risk delivery pool
    Wenn eine ausgehende Mail "vermutlich" als Spam bewertet wird, dann routet Microsoft diese Mail über einen anderen IP-Pool, bei dem es nicht so schlimm wäre, wenn er mal auf einer Blockliste auftaucht. Die Mails über diesen Pool haben eine niedrige Qualität. Darunter fallen auch NDRs/Bounce-Messages. Diese haben oft einen "Null-Absender" (Mail From: <>).
  • Relay Pool
    Eigene IP-Bereiche werden für den Versand von Mails vorgehalten, die nicht von Exchange direkt kommen, sondern über eine Relay-Funktion durch Exchange Online durchlaufen. Das kann Exchange Online zu 100% erkennen, z.B. wenn eine Mail über einen Kontakt oder Verteiler mit externen Empfängern weitergeleitet wird. Wenn eine Mail aber von einer eigenen Domain des Tenants kommt oder eingehend einen SPF:PASS erreicht hat, dann wird die Mail nicht über den Relaypool gesendet.

    Allerdings kann Exchange dann EXO SRS - Sender Rewriting Scheme (SRS) einsetzen.

Allen Pools gemeinsam ist dass Microsoft die IP-Ranges nicht veröffentlicht.


Outbound delivery pools - Relay Pools
https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-high-risk-delivery-pool-about#relay-pool

Das macht es natürlich unmöglich, diese IP-Adressen auf z.B. einem lokalen Exchange Server einzuschließen. Wer einen Exchange Hybrid-Server lokal betreibt und hinter Exchange Online Protection verstecken will, möchte aber gerne an der Firewall eine Filterung nach Quell-IP erzwingen. Das ist der einfachste und sichere Schutz gegen einen unerlaubten Hybrid Hintereingang.

Wenn die IP-Adresse als Kriterium entfällt, dann bleiben nur noch zwei andere Bedingungen, die erfüllt sein müssen:

  • Zertifikat von Exchange Online (mail.protection.outlook.com)
    Exchange Online versucht immer eine SMTP-Verbindung mit MTLS auszuhandeln. Wenn der eigene Mailserver oder die Firewall den Handshake unterstützt, könnten Sie so erkennen, ob das einliefernde Server wirklich Exchange Online ist.
  • X-OriginatorOrg enthält eine eigene Domain
    Wenn es Exchange Online ist, dann enthält der Header das Feld X-OriginatorOrg mit einer Domain des Tenants. So können Sie zuverlässig erkennen, von welchem Tenant diese Mails kommen

Es müssen beide Bedingungen erfüllt sein. Exchange OnPremises nutzt beim Hybrid Connector diese Logik ebenfalls (Siehe Hybrid Mail Routing) über die folgende Einstellung beim Receive Connector

TlsDomainCapabilities      : {mail.protection.outlook.com:AcceptCloudServicesMail}

Allerdings gibt es keinen Schalter, mit dem ich den Receive Connector so einstellen kann, dass er nur noch diese Verbindung annimmt.

Es gibt meines Wissens keine Möglichkeit, als Administrator einen bestimmten Pool vorzuschreiben. Das wäre auch unlogisch, da auch Spammer sich gerne einem Microsoft 365 Tenant bedienen.

OutboundIpPool und OutboundIpPoolName

Natürlich wollte ich wissen, welche Pools es gibt und wie ich deren Verwendung erkennen kann. Der Empfänger kann natürlich die einliefernde IP-Adresse gegen die XML-Datei oder SPF-Einträge prüfen. Aber auch der Versand durch Exchange Online hinterlässt seine Spuren. Laut Microsoft wird der verwendete Pool im Messagetracking protokolliert, wenn die Mail versendet wurde. Auch über das Defender Portal ist der Wert einsehbar, wenn Sie die Mail erst einmal gefunden und die CSV-Datei mit den  Details heruntergeladen haben.


Ermitteln, welcher ausgehende Pool verwendet wurde
https://learn.microsoft.com/de-de/defender-office-365/outbound-spam-high-risk-delivery-pool-about#find-out-which-outbound-pool-was-used

Da sich GUIs auch schnell wieder ändern, nutze ich lieber die Exchange Online PowerShell

Get-MessageTraceV2 `
   -SenderAddress "user1@msxfaq.de" `
   -StartDate (Get-Date).AddDays(-1) `
   -EndDate (Get-Date) `
| Get-MessageTraceDetailv2 `
| fl data

Leider liefern die neuen "V2-Commandets das Feld "OutrboundPoolName" nicht mehr als fertiges Property, sondern nur im Data-Bereich als Teil einer XML-Information:

Ich hätte ja gerne die Anfragen gefiltert aber leider ist der Event "Extern Senden" zum einen lokalisiert und ich habe keine passende englische Version für den Filter "-event" gefunden.

Daher muss ich wohl alle DATA-Bereiche mal schnell entweder per XML-Parser durchsuchen. Dabei muss ich etwas aufpassen, denn einfach beim ";" zu trennen funktioniert nicht, wenn danach das XML-Tag geschlossen wird. 

;S:OutboundIpPool=1102;S:OutboundIpPoolName=RegularOutboundPool" /> 

Also hole ich mir lieber das BLOB per XML und parse dann den String

Get-MessageTracev2 `
   -Status Delivered `
   -ResultSize 10 `
| ForEach-Object {
   $details = Get-MessageTraceDetailV2 `
               -Messagetraceid $_.messagetraceid `
               -RecipientAddress $_.RecipientAddress
   Foreach ($detail in ($details.data)) {
      $customdatalist = ([xml]$detail).root.MEP | Where-Object {$_.Name -eq "CustomData" }
      ForEach ($customdata in $customdatalist) {
            $blob = $customdata.Blob
            if ($blob -match "OutboundIpPool=") {
               [PSCustomObject]@{
                  OutboundIpPool = ($blob.Split(";S:") -match "OutboundIpPool=").split("=")[1]
                  OutboundIpPoolName = ($blob.Split(";S:") -match "OutboundIpPoolName=").split("=")[1]
               }
            }
      }
   }
} `
| Format-Table -Autosize

Auf meinem Tenant habe ich folgende ausgehende Mails gesehen:

 

Bislang habe ich folgende Werte und Beschreibungen gefunden:

Nummer Name Beschreibung
1022
1023
1024

HighRiskRelayOutboundPool

Diese Mails sind aus Sicht von Exchange Online ein Risiko für die Empfänger aber auch Exchange als Versender, da solche Mails sehr wahrscheinlich als Spam erkannt würden und die ausliefernde IP-Adresse vielleicht auf eine Blockliste landet. Oft haben die Mails die SPF/DKIM/DAMRC-Prüfung nicht bestanden, es fehlen MX/ReverseDNS-Einträge, es wurden NDRs erstellt oder der Spamfilter hat die Mail mit einem SCL>5 eingestuft.

1102

RegularOutboundPool

Der normale Pool, welche Exchange zum Versand von Mails ins Internet und zu Hybrid Servern nutzt. Die Absender sind in der Regel verifiziert.

1501

HighRiskOutboundPool

Solche Mails wurden vermutlich von extern empfangen und durch Exchange Online dann weitergereicht. Meist haben die Mails beim Empfang den SPF-Check nicht bestanden oder werden als "riskant" eingestuft

1701

LowRiskOutboundPool

Auch diese Mails wurden nicht "verifiziert" aber sind nicht als Spam erkannt worden.

Wenn Sie auf einem lokalen Exchange Server  eingehend die IP-Adressen aus dem Messagetracking extrahieren wollen, dann hilft dieser Code. Sie können natürlich bei "Get-MessageTrackingLog" auch noch mit Sender und Recpients arbeiten, um sich auf die relevanten Mails zu beschränken.

Get-MessageTrackingLog `
   -EventId Receive `
   -Source SMTP `
   -Resultsize 10 `
| Foreach-Object {
    [PSCustomObject]@{
        Sender                 = $_.Sender
        ProxiedClientIPAddress = ($_.eventdata | where-Object {$_.key -eq "ProxiedClientIPAddress"}).value
        MessageSubject         = $_.MessageSubject
    }
} | group ProxiedClientIPAddress

Hinweis:
Das funktioniert natürlich nur, wenn ihr erster Exchange OnPremises Server auch die reale öffentliche IP-Adresse sieht. Ansonsten müssen Sie in die Logs ihres Loadbalancers oder der Firewall schauen.

Header: X-Forefront-Antispam-Report

Neben dem Messagetracking kann der Empfänger im Header der Mail erkennen, welchen Pool Exchange Online genutzt hat. Natürlich könnte er auch die "Received"-Zeilen auswerten und die IP-Adressen der Zwischenstationen analysieren. Aber gerade von Tenant zu Tenant ist es nicht immer einfach den Übergang zu ermitteln. Wenn Sie den Header in den Message Header Analyzer eintragen, sehen Sie sehr schön die verschiedenen Header:

Das Feld wurde hier mit "-untrusted" angehängt, da die Mail mein Exchange Online verlassen hat und auf dem Weg ins Postfach alles verändert werden könnte. Hier interessiert der Wert hinter "SFP"

Testserie

Welche Pools Exchange Online beim Versand nutzt, habe ich über eine kleine Testserie ausprobiert. Dazu habe ich einen Exchange Tenant genutzt, der mit einem lokalen Exchange Server eine Hybrid-Vertrauensstellung hatte. So konnte ich Mails von einem lokalen Exchange Server mit Postfach aber auch anonym über Exchange Online ins Internet senden. Über Kontakte und Verteiler in Exchange Online konnte ich auch von extern über Exchange Online eine Mails wieder nach Exchange Online senden. Als Gegenstelle habe ich einfach ein IMAP4-Postfach bei einem Webhosting-Provider genutzt und im SMTP-Header die einliefernde IP-Adresse ermittelt. Der Wert "SFP" ist aus dem Header "X-Forefront-Antispam-Report".

 

 

 

 

Szenario  Beschreibung  Relay Ziel Source IP SFP OutboundIpPoolName

1

OnPremises Postfach via Hybrid nach extern

Ein lokales Exchange SE-Postfach sendet eine Mail über Exchange Online Protection ins Internet. Hier ist also interessant, mit welcher Source-IP mein Exchange Tenant die Mails ausliefert.

entfällt

Internet

 
2a01:111:f403:c20b::1

1102

RegularOutboundPool

2

OnPremises SMTP ExternalSecured

Dann habe ich lokal auf dem Exchange über einen "ExternalSecured" Connector eine Mail mit externer Domain eingeliefert. Das ist ein Sonderfall, bei dem ich den Absender mit Exchange Online fälschen kann. Siehe EXO Absender fälschen. Hier das SPF einen Fail geliefert.

 

entfällt 

Internet

 
52.103.175.7

1023

HighRiskRelayOutboundPool

3

Internet mit SPF PASS

Eine Mail aus dem Internet an einen Kontakt wird von Exchange Online an das Ziel weitergeleitet aber der Envelope-Absender wird mittels EXO SRS - Sender Rewriting Scheme (SRS) umgeschrieben.

Kontakt

Internet

 
52.101.169.118

1102

RegularOutboundPool

4

Internet mit SPF Fail

Eine Mail aus dem Internet an einen Kontakt wird von Exchange Online an das Ziel weitergeleitet. Der Absender hat aber die SPF-Prüfung nicht bestanden und ein SPF:FAIL provoziert. Für Exchange Online ist das ein Malus und sollte nicht über die "guten IP-Adressen" versendet werden.

Kontakt 

Internet

 
52.103.176.22

1023

HighRiskRelayOutboundPool

5 

Internet an EXO remote Mailbox nach Intern

Was passiert, wenn ich aus dem Internet eine Mail an eine RemoteMailbox sende, die dann die Mail zum lokalen Exchange Server weiter leitet, wenn der SPF-Eintrag ein Fail hat?

Remote Mailbox

OnPremises

 
40.93.78.49

NA

Ich habe keinen SFP-Eintrag gefunden.

6

Internet über Kontakt interne Subdomain

Der letzte Test ist eine Weiterleitung an einen internen Server über eine Subdomain. So können Sie z.B. support@msxfaq.de an "support@otrs.msxfaq.de" umleiten und mit einem Outbound Connector zum lokalen Exchange senden, der diese Mail dann an ein nachgeordnetes System sendet.

Hier muss ich noch etwas genauer unterscheiden, ob die Domain auch im Tenant eingetragen ist und wie der SPF-Status des Absenders ist

Kontakt 

OnPremises

 

 

 

Ich hätte erwartet, dass die "unsichereren Pools" häufiger zum Einsatz kommen. Aber anscheinend waren meine Testmails für Exchange Online nicht "verspammt" genug, so dass er diese über einen anderen Pool geroutet hätte. Nur die Mail mit einem SPF:FAIL und die von intern als Relay versandte Mail mit einem fremden Absender wurde über den "HighRiskRelayOutboundPool" geleitet.

SPF mit HighRiskRelayOutboundPool

Bei den Tests ist mir aber aufgefallen, dass die beiden IP-Adressen, die bei einer Klassifizierung als "HighRiskRelayOutboundPool" aber durchaus im regulärem Bereich der Exchange Online Adresse lagen.

52.103.175.7
52.103.176.22

Der veröffentlichte Bereich 52.100.0.0/14 reicht von 52.100.0.0 - 52.103.255.255 und enthält damit auch diese Adressen. der SPF-Record liefert aber andere Einträge. Microsoft bittet seine Kunden darum, folgenden SPF-Eintrag vorzunehmen bzw. einen vorhandenen Eintrag entsprechend zu erweitern.

v=spf1 include:spf.protection.outlook.com -all

Eine Abfrage lieferte bei mir folgende Adressen:  (umgebrochen)

C:\> nslookup -q=TXT spf.protection.outlook.com
spf.protection.outlook.com      text =

        "v=spf1 ip4:40.92.0.0/15 
                ip4:40.107.0.0/16  
                ip4:52.100.0.0/15  
                ip4:52.102.0.0/16  
                ip4:52.103.0.0/17  
                ip4:104.47.0.0/17  
                ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49  
                ip6:2a01:111:f403:8000::/51  
                ip6:2a01:111:f403:c000::/51 vip6:2a01:111:f403:f000::/52  
                -all"

Hier sehen wir einen anderen Ausschnitt aus der 52.100.0.0-Bereich.  52.100.0.0/15 enthält nur 52.100.0.0-52.101.255.255 oder anders geschrieben.

52.100.  0.0 - 255.255  SPF 
52.101.  0.0 - 255.255  SPF
52.102.  0.0 - 255.255  SPF
52.103.  0.0 - 127.255  SPF
52.103.127.0 - 255.255  KEIN SPF

Die beiden IP-Adressen, die von Exchange Online als "HighRiskRelayOutboundPool" verwendet wurden, sind also nicht über SPF als vertrauenswürdig klassifiziert worden, aber dennoch Teil der offiziellen Exchange Online IP-Range.

Ich weiß natürlich nicht, welche anderen Bereiche Microsoft noch für HighRiskRelayOutboundPool freigegeben hat. Ich bin sicher, dass auch in 40.x und 104x nicht alle Netzwerke im SPF enthalten sind, die von Exchange Online genutzt werden.

Da Microsoft aber die IP-Range des HighRiskRelayOutboundPool nicht explizit aufführt und diese auch nicht über eine SPF-Anfrage ermittelt werden können, könnte Exchange Online auch andere Adressen verwenden. Wer in seiner lokalen Firewall daher die Erreichbarkeit von Exchange OnPremises über Port 25 einschränkt, sollte die "Pending"-Messages in Exchange Online im Auge behalten.

Weitere Links