EXO Messageexpiration

Einige Verhalten von Exchange Online kann man schlecht testen, sondern nur in realen Kundenumgebungen erfahren. Hier hat Exchange Online einen kleinen Mailsturm ausgelöst, der aber an einem Fehler der Gegenseite lag.

Fehlerbild

Ein Anwender in Exchange Online hat eine etwas größere Mail mit einer 30 MB PowerPoint Anlage an mehrere Personen gesendet. Exchange Online war so konfiguriert, dass alle ausgehenden Mails über ein 3rd Party Mailrelay geroutet wurden. Diesmal hat der Kunde leider kein NoSpamProxy genutzt.

Allerdings hat zumindest ein Empfänger sich beim Absender beschwert, dass er die Mail immer und immer wieder bekommt, obwohl der Absender diese ja nur einmal versendet hat. Hier muss also irgendwo die Mail irrtümlich mit einem Fehler quittiert worden sein, so dass der absendende Server es erneut versucht während das empfangende System trotz Fehler die Mail als valide erkennt und weiter sendet.

Hinweis: Exchange hat eine Funktion Duplicate Message-ID, um solche "mehrfachmails" zu erkennen und zu unterdrücken. Wenn Mail die gleiche MessageID und Client Submission Time wie eine bereits verarbeitete Mail haben, werden diese unterdrückt.

EXO Message Tracking

Da der eigene Exchange Online Benutzer als Absender agierte, konnte ein Administrator dort sehr einfach eine Nachrichtenverfolgung starten und sehr schnell ist schon hier der Fehler offensichtlich geworden:

Es ist gut zu sehen, dass Exchange Online die Mail empfangen und dann eine Transportregel einen Disclaimer addiert und dann die Mail in die Ausgangswarteschlange gelegt wurde.

Hinweis: In Exchange Online können Sie als Administrator keine Mails in Warteschlangen sehen, denn es ist ja eine "Shared Umgebung" und ihre fertig verarbeitete Mails kann auf einem der tausenden Servern zum Versand liegen. Sie sehen aber auch, dass eine danach angelegte Transportregel zum Löschen dieser Mail auch nicht mehr greifen kann.

Siehe dazu auch die Seite Exchange Online Queue Monitoring

Ich kenne aktuell keinen Weg eine solche Mails in der Versandqueue in Exchange Online wieder anzuhalten.

Die Details zeigen dann schon deutlich dass Exchange Online mit der Übertragung der Mail wohl begonnen hat aber dann die Verbindung mit einem "Connection was closed abruptly" durch irgendetwas auf dem Transport abgebrochen wurde.

Ob hier nun die Gegenseite die Verbindung einfach geschlossen hat oder auf dem Übertragungsweg eine Firewall unzufrieden war, konnte nicht weiter analysiert werden. Für Exchange Online war die Mail auf jeden Fall nicht erfolgreich zugestellt und wurde wieder zum Versand zurückgestellt.

Smarthost

Entsprechend konnten wir nun auch auf der Gegenseite die Protokolle basierend auf dem Absender auswerten. Hier ist gut zu sehen, dass jede Mail von Exchange Online angenommen und weiter verarbeitet wurde. Für das vorgelagerte 3rd-Party-Produkt war es eine ganz gewöhnliche Mail, die erfolgreich aller 15 Minuten immer wieder eingeliefert wurde.

Leider ist nicht nicht erkenntlich, wer nun den "Connection was closed abruptly" verantwortlich ist. In dem Fall konnte Exchange Online irgendwann die Mail zustellen und bekam auch ein 250OK des Zielsystems und der Spuk hatte damit ein Ende.

Leider hat das Zielsystem irgendwann alle Mails angenommen und ich konnte damit nicht erkennen, wie lange Exchange Online eine erneute Zustellung immer wieder versucht.

Message Expiration

Die Frage stellt sich nun, wie lange und wie häufig Exchange temporär nicht zustellbare Mails erneut versucht. Ich habe dazu nur eine Quelle gefunden:

How long does a message remain in deferral and what is the retry interval?
Deferred messages remain in our queues for one day. Retry attempts are based on the errors that we receive from the destination email server. The first few deferrals are 15 minutes or less. The interval for subsequent retries increases to a maximum of 60 minutes. The interval duration expansion is dynamic, and considers multiple variables (queue size, internal message priority, etc.).
Quelle: https://learn.microsoft.com/is-is/microsoft-365/security/office-365-security/mail-flow-about?view=o365-worldwide#how-long-does-a-message-remain-in-deferral-and-what-is-the-retry-interval

In der Exchange Online PowerShell gibt es die Möglichkeit, zumindest die Expiration einzusehen und in Grenzen auch zu ändern.

PS C:\> (Get-TransportConfig).MessageExpiration
1.00:00:00

Exchange Online versucht die Mail bis zu einem Tag (24h) immer wieder zuzustellen. Das Intervall von 15 Minuten ist aktuell statisch. Ob sie die "MessageExpiration" nun auf z.B. 12h, 6h oder 3h reduzieren, ist individuell abzuwägen. Der Anwender sendet eine Mail und erwartet, dass diese umgehend zugestellt wird. Mit 24h bleibt er lange Zeit im Unklaren, wo die Mail gerade hängt. Wenn sie als Administrator die Zeit reduzieren, bekommt der Absender schneller eine Unzustellbarkeit und kann reagieren. Auf der anderen Seite kann dies auch stören, wenn die Mail nicht so dringend ist und nach Ablauf der Zeit der Absender wieder aktiv werden muss.

Set-TransportConfig -MessageExpiration 06:00:00

Ich würde die Zeit aber erst einmal nicht anpassen.

Exchange Messagetracking

Es gibt keinen Weg wie ich als Administrator mal schauen kann, welche ausgehende Mails noch nicht zugestellt sind. OnPremises hat ich ein "Get-Queue" aber in Exchange Online gibt es nur das Messagetracking mit dem ich natürlich z.B. alle Mails der letzten 24 Stunden erhalten und nach dem letzten Status prüfen könnte. In der Cloud gibt es tausende und mehr Transport Server, die sich die Arbeit teilen und nur ihre Abschlussmeldung an das Messagtracking senden und über den "Transport Cache" die Verfügbarkeit erreichen. Aber ganz ohne Diagnosemöglichkeit sind sie nicht.

Ich habe eine eigene SMTP-Domain "nosmtp.msxfaq.net" welche keinen Mailserver betreibt und daher Mails an diese Domain im Versand "hängen" bleiben. So kann ich das Verhalten von Mailservern, Spamfiltern etc. prüfen und Testmail an diese Domain blieb in Exchange Online natürlich mit einem "PENDING" liegen:

Die Details zeigen auch, dass die Mail noch nicht Exchange Online verlassen hat.

Interessant ist, dass Exchange anscheinende nachfolgende Versuche nicht gesondert protokolliert, wenn die Verbindung gar nicht erst aufgebaut werden kann.

Wenn etwas im Browser möglich ist, dann ist es auch per PowerShell möglich. Über Get-MessageTrace und einem Filter auf den Status=Pending liefert die Exchange PowerShell alle Mails, die noch in der Warteschlange sind.

Damit haben wir einen Weg, solche "hängenden Mails" schnell zu finden. Wenn wir dann noch die "Received"-Zeit mit einbeziehen oder beim der Abfrage gleich mit vorgeben, dann können Sie diesen Status sogar aktiv selbst überwachen. Eine Abfrage nach allen "Pending" Mails, die älter als 10 Minuten sind, wäre dann

(Get-MessageTrace `
   -Startdate (Get-date).adddays(-2) `
   -EndDate (get-date).addminutes(-10) `
   -Status Pending `
).count

Aktuell ist diese Information noch nicht über Microsoft Graph sondern über die Exchange Reporting API verfügbar. Wer mag, kann sich aber damit dann auch einen Sensor für seine lokale Überwachungslösung schreiben, um solche Probleme zu erfassen.

Siehe dazu auch Exchange Online Queue Monitoring

Testserie

In meinem Developer Tenant / Sandbox habe ich mit für weitere Analysen folgende Konfiguration aufgebaut:

Szenario

Gegenstelle ist nicht erreichbar

Gegenstelle nicht verifizierbar
Konfiguration

Dazu habe ich einen Partner Connector für eine Domain zu einem beliebigen Router im Internet eingerichte, der sicher keinen Port 25 offen hat aber vielleicht ein ICMP-not reachable sendet.

Dazu habe ich einen Partner Connector für eine Domain zu einem beliebigen Mailserver eingerichtet und den Namen im Zertifikat erzwungen.
Finale Fehlermeldung 
Reason: [
{LED=550 5.4.316 Message expired, connection refused};
{MSG=Socket error code 10061};
{FQDN=80.66.20.16};
{IP=80.66.20.16};
{LRT=11/16/2023 9:38:18 PM}]. 
OutboundProxyTargetIP: 80.66.20.16.
 
Reason: [
{LED=550 5.4.317 Message expired, cannot connect to remote server};
{MSG=SubjectMismatch};
{FQDN=msxfaq.de};
{IP=80.237.138.5};
{LRT=11/16/2023 5:33:59 AM}].
 OutboundProxyTargetIP: 80.237.138.5. OutboundProxyTargetHostName: msxfaq.de
Retries
Abstände der DEFER in Min

3-17-16-16-20-21-20-22-20-512-566-100-94-16

2-20-15-20-20-20-21-20-20-326
Fehler nach

1443 Minuten (24 Stunden)

484 Minuten (8 Stunden)

Das ist natürlich nur eine Momentaufnahme und keine Zusicherung einer zukünftigen Funktion. Zudem habe ich auch einige andere "Effekte" gesehen, die mich am Messagetracking zweifeln lassen. So habe ich am 18 Nov 2023 um 01:48 (nachts) eine Mail an einen nicht erreichbaren Host gesendet, die in Exchange Online einige Zeit auf Zustellung warten musste.

Als ich dann am 18. Nov 2023 gegen 12:10 mittags nachgeschaut habe, hatte die Mail zwar noch den Status "DEFER" aber die letzte Fehlermeldung war von 01:50. im "Queued messages report" war aber nichts zu sehen. Erst 12:58 und 13:00 wurden weitere Meldungen protokolliert.

Die Frage ist ja, wann eine Mail einen DEFER erleidet. Wenn die Gegenseite einen permanenten 5xx-Fehler sendet, dann erstellt Exchange direkt einen NDR. Nur wenn die Gegenseite nicht erreichbar ist oder einen temporären 4xx-Fehler meldet, stellt Exchange die Mails zurück. Microsoft schreibt dazu:

How does a message become deferred?
Messages are held when a connection to the destination server can't be made, and the destination server returns temporary errors. For example, connection time-out, connection refused, or other 400-series errors. 500-series (permanent) errors result in return of the message in a non-delivery report (also known as an NDR or bounce message).
Quelle: https://learn.microsoft.com/is-is/microsoft-365/security/office-365-security/mail-flow-about?view=o365-worldwide#how-does-a-message-become-deferred

Auch auf die Intervalle gibt es eine Antwort

How long does a message remain in deferral and what is the retry interval?
Deferred messages remain in our queues for one day. Retry attempts are based on the errors that we receive from the destination email server. The first few deferrals are 15 minutes or less. The interval for subsequent retries increases to a maximum of 60 minutes. The interval duration expansion is dynamic, and considers multiple variables (queue size, internal message priority, etc.).
https://learn.microsoft.com/is-is/microsoft-365/security/office-365-security/mail-flow-about?view=o365-worldwide#how-long-does-a-message-remain-in-deferral-and-what-is-the-retry-interval

Exchange Mai Flow Report

Es gibt im Exchange Admin Center die "Mail flow Reports" und darunter gibt es auch einen ""Queued messages report", über den Sie Mails finden, die längere Zeit nicht versendet wurden.


https://admin.exchange.microsoft.com/#/reports/mailflowreportsmain

Nehmen Sie diese Stunde nicht wörtlich. Damit ist gemeint, dass die Mail länger als eine Stunde in der Queue liegt, wenn sie zurückgestellt wurde. Je nach Fehler wird die Mail aber erst mehrfach versucht zuzustellen, ehe Sie in die Queues zurück geht. Es kann also 2h oder mehr dauern, bis der Report etwas anzeigt.

Das ist natürlich keine Neartime-Überwachung und keine Alarmierung.

Exchange Alert

Exchange Online kann Sie sogar per Mail informieren, wenn Mails in einer Warteschlange gestaut sind. Microsoft sendet diese Mails per Default an die die "Tenant Admins", wenn mehr als 2000 Mails über stunden aufgelaufen sind. Wie wenig sinnvoll das ist, können Sie sich selbst vorstellen. Meine Kunden und deren Mitarbeiter melden sich schon deutlich früher, wen eine Mail nicht innerhalb von Minuten angekommen ist.

Die Details zur Anzeige und Konfiguration finden Sie auf der Seite Exchange Online Queue Monitoring

Draus lernen

Bei diesem Fall sind alle mit einem blauen Auge davon gekommen, denn Exchange Online hat die Mail nur alle 15 Minuten erneut gesendet bis sie letztlich doch erfolgreich angenommen wurde. Im Worst Case hätte Exchange Online die Mail aber 4 * 15Min * 24Stunden = 96Mal versucht zuzustellen und jedes mal hier ca. 27MB/Mail oder ca. 2,592GB übertragen. Da kann man dann nur hoffen, dass der Administrator auf der Gegenseite das Problem mit seinem Server schnell korrigiert. Aber folgende Dinge nehme ich mit:

  • Kein Exchange Online Queue-Status
    Es gibt keinen Weg wie ich als Administrator mal schauen kann, welche ausgehende Mails aktuell noch nicht zugestellt sind. OnPremises konnte ich das mit einem "Get-Queue" abfragen aber in Exchange Online gibt es nur das Messagetracking mit dem ich natürlich z.B. alle Mails der letzten 24 Stunden erhalten und nach dem letzten Status prüfen könnte.
  • Transport-Regeln wirkungslos
    Wenn eine Mail das Exchange Routing durchlaufen hat, dann liegt Sie zum Versand bei den Transport-Servern. Ab da kann ich als Administrator in Exchange Online diese Mail nicht mehr anhalten oder mittels Transportregeln verarbeiten.
  • Dubletten Erkennung
    Das Zielsystem hat die gleiche Mail immer wieder komplett empfangen und hätte diese sehr einfach als Dublette erkennen können. Diese Funktion scheint nicht vorhanden zu sein, aber könnte sowohl den Zielempfänger von redundanten Mails und der Übertragung und Speicherung entlasten. Ein entsprechender Counter könnte aber auch dem Betreiber des Relay eine Kennzahl geben, um Probleme schneller zu erkennen. Denn doppelte Mails sollte es mit dem gleichen Envelope-RCPTTO eigentlich nicht geben. Exchange OnPremises und Exchange Online haben auf der Datenbank eine Dublettenerkennung aber nicht auf dem Transport.
    NoSpamProxy hat eine Dubletten-Erkennung auf dem Transport.

Auf das Verhalten von Exchange Online selbst haben sie aber bis auf den "Messageexpiration"-Wert keinen Einfluss. Sie könnten den Retry-Wert von 15 Min nicht ändern und auch keine Anzahl der maximalen Zustellversuche beeinflussen. Aber eigentlich sollte das anfangs genannte Szenario, bei der eine Verbindung nach kompletter Übertragung mit einem Fehler abgebrochen wird, eher die Ausnahme sein.

Weitere Links