E2010 Transport Cache (XSHADOW und XQDISCARD) und "Delayed SMTP Acknowledgement"

Diese Funktion ist erst ab Exchange 2010 verfügbar.

Exchange 2010 bringt eine neue Funktion mit, um einen Ausfall eines Hub/Transport-Servers zu erkennen und die Mails erneut zu senden.

Funktionsprinzip

Eine Mail durchläuft wie bisher den normalen Weg vom Mailbox Server über Hub-Server zu internen Empfängern oder über Gateways zu externen Postfächern:

Das Prinzip basiert nun darauf, dass ein System immer für die Zustellung verantwortlich ist und nur ein System der "Besitzer" der Nachricht ist. Die Station davor wirft aber die Mail nicht sofort weg,, sondern wartet auf eine Bestätigung, dass die nächste Station die Mail ihrerseits versendet hat. Es reicht also nicht aus, die Mail erfolgreich an die nächste Station zu senden, sondern sich zusätzlich zu vergewissern, dass die nächste Station die Mail ebenfalls zugestellt hat. Dazu hat Microsoft zwei neue SMTP-Verben (XSHADOW und XQDISCARD) eingeführt, so dass die Kommunikation über den normalen SMTP-Kanal erfolgt.

Fällt also eine Hub/Transport aus, dann sind zwar erst einmal die Mail alle verloren, die auf diesem Server temporär vorhanden waren, aber die vorherige Station hat die Mails ja noch und da die Bestätigung des ausgefallenen Servers Ausbleibt, wie dieser Server die Mail einfach noch einmal zum wieder hergestellten Server oder einen anderen Weg senden.

In Verbindung mit dem Einsatz von Database Availability Groups wird das Verfahren auch angewendet. Beim Versenden überträgt ein Mailboxserver die Mail immer zu einem HT auf einem anderen Server, selbst wenn auf dem gleichen Server auch ein HT läuft. Wenn eingehende Mails auf dem HT landen, auf dem auch die primäre Mailbox liegt, wird die Mail von dem HT erst zu einem anderen HT übertragen, der die Mail dann wieder in die Mailbox zurück schreibt. Das wird alles gemacht, dass die Mail immer auf zwei Systemen liegt und der Ausfall eines Servers keinen Mailverlust bedeutet.

Technisch kann es natürlich passieren, dass eine Mail damit doppelt am Empfänger ankommt. Das ist aber immer noch besser als eine "verlorene Mail" durch einen Defekt eines Übertragungssystem. Hinzu kommt. dass zumindest Exchange Server "doppelte Mails" auch erkennen und unterdrücken. Siehe auch Duplicate MessageID. ähnliche Funkionen haben wohl auch die ein oder anderen Mailserver.

Mailbox to Hub

Die erste Station ist natürlich der Versand von einem Client. Sie erstellen eine Mail mit Outlook, ActiveSync, OWA o.ä. Und liefern diese beim Exchange Server zum Versand ein. Die Mail liegt in ihrem "Postausgang" und der "Mail Submission Service" benachrichtig einen der Hub/Transport-Server, dass hier eine Mail zur Abholung wartet. Der angesprochene Hub-Transport holt sich die Mail aus dem Postausgang und übergibt ihn dem Routing. Die Mail selbst wird am Ende dann in den Ordner "gesendete Objekte" abgelegt.

Der Mailbox-Server prüft seinerseits nach einiger Zeit nach, ob der Hubtransport die Mail seinerseits schon weiter geleitet hat. Antwortet der Hubtransport nicht mehr auf mehrere Versuche, dann geht der Mailboxserver von einem Ausfall aus, und sendet die Mail erneut. Dazu bedient er sich einfach der Kopie in "Gesendete Objekte", die sie natürlich noch nicht gelöscht haben dürfen.

Hub2Hub und Hub2Edge

In größeren Umgebungen wird der Hub/Transport Server die Mail natürlich weiter geben. Das erfolgt anhand der bekannten Routingregeln zum nächsten Hub-Server oder Edge Server. Am Routing ändert sich nichts. Der nächste Hub-Server nimmt die Mails an.

Der sendende Server erkennt allerdings an dem Verb "XSHADOW", dass der nächste Server die Funktionalität Transportcache unterstützt. Also fragt immer mal wieder nach, ob der nächste Server die Mails vielleicht schon erfolgreich weiter gegeben hat. Dazu fragt der Server mittels dem SMTP-Verb "XQDISCARD" nach, welche Mails er denn aus seinem lokalen Cache entfernen kann. Der anderer Hub-Server antwortet auf diese Anfrage mit einer Liste der von ihm bereits erfolgreich versendeten Mails.

Hub2 Exchange 2007/2003

Es ist ja erlaubt, Exchange 2010 auch mit Exchange 2007 und sogar Exchange 2003 zu installieren. Damit kann es auch passieren, dass ein Exchange 2010 Hub zu einem "Downlevel"-Exchange Server die Nachrichten überträgt. Von dort bekommt er natürlich kein "XSHADOW" Verb. Entsprechend legt der Exchange 2010 Hub/Transport keine Shadow-Queue für diese Ziel an und übermittelt einfach die Mail. Fällt das nächste System aus, gibt es keinen Automatismus, um die Mail erneut zu senden. Das Verhalten entspricht dem Verhalten Aller Mailserver vor Exchange 2010.

Ich habe keine Informationen, dass eine XSHADOW und XQDISCARD für Exchange 2003 oder Exchange 2007 über ein Servicepack nachgerüstet wird.

Exchange 2 Foreign System

Irgendwann verlässt die Mail natürlich die gesicherte Exchange Organisation Richtung Internet oder zu einem Gateway welches nicht "XSHADOW" unterstützt. Der sendende Server baut auch hier keine Shadow-Queue auf.

Interessant wird es, wenn zwei Firmen miteinander kommunizieren, die beide Exchange 2010 als Gateway einsetzen. Dann funktioniert die Shadow-Queue sogar über Internet hinweg. Neben dem Internet kann das natürlich auch für größere Organisationen mit mehreren Exchange Organisationen wichtig sein, die über Federation oder interne Verbindungen miteinander verbunden sind.

Details zu Shadow Queue

Ehe ein Exchange 2010 überhaupt einen Transportcache anlegt, muss der nächste HOP ihm das XSHADOW-Verb anbieten. Der sendende HubTransport fordert diese Funktion dann nach erfolgter Authentifizierung per XSHADOW an. Nun weiß der empfangende Server, dass der Sender alle an ihn gesendeten Mails in seinem Transportcache weiter vorhält und immer wieder mit einem XQDISCARD nachfragen, welche Mails vom empfangenden Hubserver bereits weiter zugestellt wurden.

Die Mails, welche der sendende Transport Server noch vorhält, sind im QueueViewer zu sehen. Sie erkennen diese besondere Warteschlange am "Delivery Type" der Queue, welcher den Wert "Shadow Redundancy" hat.

Bild ist noch nicht passend zur Transport Cache Queue

Die Mails werden in dieser Queue nur solange vorgehalten, bis die Gegenseite auf das XQDISCARD ein "Versand erfolgt" zurück meldet. Die Arbeitsweise des Transport-Cache ist über die PowerShell zu steuern. Die Parameter sind aber überschaubar.

[PS] C:\>Get-TransportConfig | fl shad*

ShadowRedundancyEnabled          : True
ShadowHeartbeatTimeoutInterval   : 00:05:00
ShadowHeartbeatRetryCount        : 3
ShadowMessageAutoDiscardInterval : 2.00:00:00

Per Default fragt ein Hub-Server drei mal alle 5 Minuten nach. Wenn der nächste HOP in der Zeit nicht antwortet, wird von einem Ausfall ausgegangen und die Mail umgeroutet. Maximal hält ein Server die Nachrichten sieben Tage in der Queue.

Wer sich mit einem TELNET einfach zu einen Exchange 2010 Server verbindet und ein EHLO absetzt, wird auch hier das VSHADOW-Verb sehen:

Um jedoch ein "XSHADOW" auszuführen, muss sich der Server zwingend authentifiziert haben. Damit ist der Einsatz im Internet natürlich erst mal wieder eingeschränkt.

Um die damit möglichen Dubletten beim Empfänger zu verhindern, implementiert Microsoft schon seit längerem ein Verfahren (Siehe auch Duplicate MessageID), um doppelte Mails zu erkennen und die Kopien ohne weitere Rückmeldung zu löschen. Diese Erkennung wurde bei Exchange 2010 auf eine Woche angehoben.

Delayed SMTP Acknowledgement

Eine zweite Funktion, die in die gleiche Schiene passt ist das "Delayed SMTP Acknowledgement". Wenn ein "nicht Exchange Server" eine Mail per SMTP an Exchange zusetzen, dann kann dieser per SMTP zwar die ganze Mail an Exchange 2010 übermitteln, aber Exchange 2010 wartet noch mit dem "250 Queued für Delivered". Exchange 2010 sendet die Mail erst an den nächten Server oder ins Postfach. Erst wenn die Mail schon beim nächsten Hop angekommen ist, bekommt der externe Mailserver sein "250 Queued für delivery", auf das er gewartet hat.

Auch hier ist die Idee, dass die Mail im Falle eines Defekts der Hub/Transport-Rolle verloren geht. Fällt der erste Exchange Server nämlich aus, dann sendet der externe Server die Mail einfach noch mal. Er hat ja am Ende kein "250 Queued für delivery" bekommen. Sobald die Mail aber vom nächten Hop angenommen wurde, und der erste Exchange SMTP-Server dem Absender ein "250 Queued für delivery" gesendet hat, liegt die Mail nun immer noch auf dem ersten und dem nächsten Exchange Server vor. Der Ausfall eines Servers alleine ist also auch nicht kritisch.

Exchange 2007 Transport Dumpster

Diese Funktion darf NICHT mit dem Exchange 2007 Transport Dumpster verwechselt werden. Diese sorgt dafür, dass Mails vom Hub an einen Exchange Server CCR-Cluster nach einem verlustbehafteten Failover erneut zugestellt werden. Der Transport Cache bezieht sich auf ausgehende Mails vom Mailserver weg zu anderen Systemen.

Offene Fragen

  • Message Fork
    Was passiert mit einer Mail und zwei Empfängern die vom Hub 1 als eine Mail zum Edge geht und vom Edge dann zu zwei unterschiedlichen Servern weiter gegeben wird. !
  • DoS mit XQDISCARD
    Fraglich ist auch, wie viel "Zeit" die Anfrage eines "XQDISCARD" dauert und ob man dieses Verb wirklich zum "Internet" hin öffnen will. Nicht dass da ein DoS gegen Exchange möglich wäre.
  • VSHADOW Tricks
    Ich muss noch mal ausprobieren, wie ein Exchange 2010 Server reagiert, wenn ich ihm ein VSHADOW anzeige aber kein XQDISCARD beantworte. Glaubt Exchange dann es wäre ein Fehler und sendet die Mail immer wieder ?
    Auch wäre es sicher gemein, wenn ich an einen Server Mails übermittle aber nie mit XQDISCARD den Status abfrage um dort einen Speicherüberlauf zu provozieren oder zumindest Ressourcen zu binden (Update: Angeblich hält der Hub die Information maximal 2 Tage.
  • Exchange Hosted Filterung (EHS) / 3rd Party Spamschutz
    Offen ist auch, wie ein gehosteter Spamschutz mit der Situation umgeht. Bislang ist mir auch hier niemand bekannt (nicht mal Exchange Hosted Spamschutz), welche diese Funktion unterstützen.
  • Hub-Reboot und geplante Downtime
    Der Status muss natürlich auch einen geplanten Neustart eines Servers überstehen. So kann es sein, dass Hub1 eine Mail an Hub2 sendet und Hub2 diese schon an Hub3 gesendet hat, aber Hub1 hat diesen Status noch nicht per XQDISCARD abgefragt. Wird nun der Hub2 gebootet und kommt wieder hoch, dann sollte er natürlich den Status wieder wissen. Sonst wird Hub1 die Mails noch einmal senden.

Drittprodukte

Aktuell gibt es keine Berichte über Mailserver anderer Hersteller, die diese Befehle unterstützen.

Weitere Links