Informationsspeichertreiber des SMTP-Diensts

Letztes Änderungsdatum des Themas: 2005-06-21

Das erweiterte Warteschlangenmodul gibt ein MailMsg-Objekt (ein im Speicher enthaltenes Nachrichtenobjekt, das eine schnelle Verarbeitung ermöglicht) von Ereignissenke zu Ereignissenke weiter. Das MailMsg-Objekt besteht aus einem Nachrichtenübertragungsumschlag und einem Zeiger auf die eigentliche physische Nachricht, wenn sich die Nachricht im NTFS im Verzeichnis \Queue befindet. Wenn sich die Nachricht im Exchange-Informationsspeicher befindet, verweist der Zeiger auf den RFC 822-Inhalt der Nachricht und somit auf eine temporäre Datei in der Streamingdatenbank. Beachten Sie, dass Ereignissenken bei MAPI-Nachrichten nicht direkt funktionieren und dass Änderungen an einer MAPI-Nachricht während der Nachrichtenverarbeitung im Transportsubsystem nicht erhalten bleiben. Komponenten wie das Kategorisierungsmodul verwenden den Nachrichtenzeiger vorwiegend zum Auslesen von Daten aus dem Nachrichteninhalt. Das erweiterte Warteschlangenmodul verwendet den Nachrichtenzeiger zudem zur Löschung von Nachrichten, wenn diese angefordert wird.

Anmerkung:
Der MailMsg-Eigenschaftenstream ist der wichtigste Mechanismus, der von Transportkomponenten für permanente Änderungen an einer Nachricht verwendet wird. Der MailMsg-Eigenschaftenstream bleibt auch beim Neustart von Diensten erhalten.

Um das MailMsg-Objekt für eine empfangene Nachricht im Speicher zu erstellen und mit der eigentlichen Nachricht zu arbeiten, verwendet das erweiterte Warteschlangenmodul die folgenden Informationsspeichertreiber:

• NTFS-Informationsspeichertreiber   Dieser Informationsspeichertreiber ist in der Datei NTFSDrv.dll implementiert, die sich im Ordner \Windows\System32\Inetsrv befindet. Dies ist der in Windows Server 2003 enthaltene grundlegende Informationsspeichertreiber. Er bietet eine dauerhafte Speicherung des Inhalts eines MailMsg-Objekts und stellt im Dateisystem Eigenschaften für Nachrichtenübertragungsumschläge bereit.
• Exchange-Informationsspeichertreiber   Dieser Informationsspeichertreiber ist in der Datei Drviis.dll implementiert, die sich im Ordner \Programme\Exchsrvr\bin befindet. Dieser Treiber wird von Exchange Server 2003 implementiert, um die permanente Speicherung des Inhalts eines MailMsg-Objekts zu gewährleisten und Eigenschaften des Übermittlungsumschlags im Exchange-Informationsspeicher bereitzustellen. Der Informationsspeichertreiber übernimmt auch die lokale Nachrichtenübermittlung.

Anmerkung:
Änderungen am Inhalt der Nachricht sind nicht immer permanenter Natur. Bei Nachrichten, die durch den Exchange-Informationsspeichertreiber gesichert wurden, gehen die Änderungen verloren, da der Exchange-Informationsspeicher nur mit einer temporären Kopie der Nachrichten arbeitet.

NTFS-Informationsspeichertreiber

Der SMTP-Dienst speichert eingehende Nachrichten auf einer Festplatte, bevor er die Übertragung bestätigt und die SMTP-Verbindung mit dem Remotehost trennt. Wenn Nachrichten über das SMTP-Protokollmodul eintreffen, werden die Daten als NTFS-Datei (EML-Datei) in den Ordner \Queue des Dateisystems geschrieben. Dieser Ordner befindet sich im Verzeichnis \Mailroot des virtuellen SMTP-Servers. Der Pfad zum Verzeichnis \Mailroot des standardmäßigen virtuellen SMTP-Servers lautet: \Programme\Exchsrvr\Mailroot\Vsi 1. Wenn Sie im Exchange-System-Manager zusätzliche virtuelle SMTP-Server erstellen, werden im Verzeichnis \Mailroot entsprechend der Nummer des virtuellen SMTP-Servers zusätzliche \Vsi x-Ordner erstellt. Alle \Vsi x-Verzeichnisse befinden sich unter \Programme\Exchsrvr\Mailroot und werden der Reihe nach benannt (also \Vsi 1, \Vsi 2 usw.).

Anmerkung:

Das Setupprogramm von Exchange Server 2003 verschiebt das Verzeichnis \Mailroot des SMTP-Diensts von \Inetpub\Mailroot nach \Programme\Exchsrvr\Mailroot. Die vorherige Ordnerstruktur wird nicht gelöscht. Nachrichten in den ehemaligen Ordnern \Pickup und \Queue werden jedoch nicht übermittelt. Damit diese Nachrichten gesendet werden, müssen Sie sie manuell in den aktuellen \Pickup-Ordner des virtuellen SMTP-Servers verschieben.

Jeder \Vsx-Ordner enthält drei oder vier Unterordner, die für die folgenden Zwecke vorgesehen sind:

• \Badmail   In diesem Ordner werden unzustellbare Nachrichten gespeichert. Durch eine unzustellbare Nachricht wird das erweiterte Warteschlangenmodul aufgefordert, die Nachricht zusammen mit einem Unzustellbarkeitsbericht an den Absender zurückzusenden. Wenn der Unzustellbarkeitsbericht nicht übermittelt werden kann, wird die Nachricht im Ordner \Badmail in drei separaten Dateien gespeichert.

• \Pickup   Dieser Ordner bietet eine alternative Methode zum Senden von E-Mail-Nachrichten. In diesen Ordner können Sie zur Übermittlung Nachrichten in Form von Textdateien stellen, die nach RFC 822 formatiert sind. Der Inetinfo-Prozess verwendet einen Thread der asynchronen Threadwarteschlange zur Überwachung des \Pickup-Verzeichnisses jedes virtuellen SMTP-Servers. Dieser Thread empfängt unverzüglich Nachrichten aus dem Ordner \Pickup, erstellt eine neue Datei im Verzeichnis \Queue, analysiert danach den Inhalt der Datei im Verzeichnis \Pickup und schreibt die Daten in die Datei im Verzeichnis \Queue. Beachten Sie, dass der Inhalt während dieses Prozesses unter Umständen geändert wird. Die Header „x-sender“ und „x-receiver“ werden z. B. nicht in die Datei geschrieben, die sich im Verzeichnis \Queue befindet.
  Das folgende ist ein Beispiel für eine Internettextnachricht mit erweiterten Headerinformationen für Empfänger und Absender. Der Header „x-receiver“ kennzeichnet einen einzelnen Empfänger. Wenn Sie mehrere Empfänger eintragen möchten, fügen Sie für jeden Empfänger den Header „x-receiver“ hinzu. Der Header muss am Anfang der Textdatei stehen, wobei der Header „x-sender“ als erstes aufgeführt sein muss. Nach RFC 822 muss sich zwischen den Headerinformationen und dem Nachrichtentext eine Leerzeile befinden.
  Der Dateiname des Nachrichtenobjekts ist nicht wichtig. Der SMTP-Dienst verwendet seine eigene Logik zur Benennung der Nachrichtendatei im Verzeichnis \Queue und hängt die Dateinamenerweiterung .eml an, z. B. NTFS_7224ae2001c4125c0000001b.eml.
  x-sender: Ted@contoso.com
x-receiver: Birgit@fabrikam.com
From: Ted@contoso.com
To: Birgit@fabrikam.com
Subject: RFC 822 Pickup Message

  This message is passed to the SMTP service through the \Pickup directory.

  Anmerkung:
  Sie sollten die Textnachrichten in einem anderen Ordner des Dateisystems erstellen und die Nachrichten anschließend in den Ordner \Pickup verschieben. Um Konflikte mit dem überwachenden SMTP-Dienst zu vermeiden, erstellen Sie die Dateien nicht direkt im Ordner \Pickup.

• \Queue   Dieser Ordner enthält alle über SMTP empfangenen Nachrichten, die zurzeit auf die Übertragung an ein Remoteziel per SMTP warten. Dieses Verzeichnis enthält jedoch keine Nachrichten, die während der Verarbeitung im SMTP-Transportsubsystem über den Exchange-Informationsspeicher empfangen wurden. Wenn eine Verbindung belegt oder derzeit nicht verfügbar ist, können sich in diesem Ordner Nachrichten anhäufen.

  Anmerkung:

  Das erweiterte Warteschlangenmodul versucht, im Ordner \Queue enthaltene Nachrichten in festgelegten Intervallen erneut zu senden. Sie können diese Intervalle im Exchange-System-Manager in den Eigenschaften für virtuelle SMTP-Server auf der Registerkarte Übermittlung konfigurieren. Der Inhalt des Ordners \Queue wird jedoch nicht in Intervallen erfasst. Der Inhalt des Ordners \Queue wird nur erfasst, wenn Sie einen Dienst starten oder wenn Sie einen virtuellen SMTP-Server neu starten.

• \Filter   Dieser Ordner ist in der Standardeinstellung nicht vorhanden. Er wird automatisch erstellt, sobald die erste Nachricht gefiltert wird, nachdem Sie auf einem bestimmten virtuellen Server die Nachrichtenfilterung aktiviert haben. Wählen Sie zur Aktivierung der Nachrichtenfilterung im Exchange-System-Manager die Eigenschaften des virtuellen SMTP-Servers aus, wählen Sie die Registerkarte Allgemein aus, und klicken Sie auf Erweitert.

  Anmerkung:
  Darüber hinaus gibt es den Ordner \Windows\NTDS\Drop, den der SMTP-Dienst auf Domänencontrollern zur Übermittlung standortübergreifender Replikationsnachrichten an Active Directory verwendet. Der Ordner \Drop wird nicht zur Übermittlung von Exchange-Nachrichten verwendet.

Verschieben des Mailrootverzeichnisses

In Exchange Server 2003 können Sie die Ordner \Badmail und \Queue mit Exchange-System-Manager an einen anderen Ort im Dateisystem verschieben (dies geschieht in den Eigenschaften des virtuellen SMTP-Servers auf der Registerkarte Nachrichten). Die Ordner \Badmail und \Queue sind die wichtigsten Ordner für die Nachrichtenverarbeitung in Exchange, da es sich um die Hauptordner des SMTP-Diensts handelt. Es ist auch möglich, den Ordner \Pickup zu verschieben. Dazu müssen Sie in Active Directory mit ADSI-Bearbeitung (AdsiEdit.msc) msExchSmtpPickupDirectory für das virtuelle SMTP-Serverobjekt festlegen. Der Metabase-Aktualisierungsdienst überträgt die Konfigurationseinstellungen in die IIS-Metabase, wie weiter oben in diesem Abschnitt erläutert wurde.

Verschieben Sie das Verzeichnis \Mailroot nicht auf eine FAT-Partition, da FAT-Partitionen keine alternativen Datenströme für ein Dateiobjekt unterstützen und für sie außerdem weitere Einschränkungen gelten. FAT16-Partitionen unterstützen beispielsweise maximal 65.535 Dateien. Auf einem stark ausgelasteten Bridgeheadserver kann dies ein Problem darstellen. Wenn sich eine Warteschlange zu füllen beginnt, können Einträge gelöscht werden, damit neue Dateien erstellt werden können. Dieser Prozess ist jedoch kompliziert, da für jede Nachricht drei Dateien benötigt werden. Da alternative Datenströme auf einer FAT-Partition nicht verfügbar sind, muss der NTFS-Informationsspeichertreiber für jede Nachricht drei unterschiedliche Dateien erstellen anstatt lediglich eine Datei mit zwei alternativen Datenströmen. Die Leistung von FAT auf großen Datenträgern ist schlecht, da nur eine minimale Fehlertoleranz gegeben ist und nach einem unerwarteten Systemhalt keine Möglichkeit zur Wiederherstellung besteht. Das Verschieben des Verzeichnisses \Mailroot auf ein leistungsstarkes Datenträgersubsystem wie RAID (Redundant Array of Independent Disks) wirkt sich unter Umständen positiv auf die Leistung aus. RAID 0+1 mit acht bis zehn Datenträgern ist bereits eine gute Lösung für eine Nachrichtenübermittlung mit hohem Datenaufkommen. Ein RAID-Controller mit einem Zwischenspeicher von mehr als 64 MB trägt ebenfalls zur Leistungssteigerung bei.

Anmerkung:
Alle vom SMTP-Protokollmodul verarbeiteten Nachrichten werden auf Datenträger geschrieben und dann in ein MailMsg-Objekt eingelesen.

Exchange-Informationsspeichertreiber

Der Exchange-Informationsspeichertreiber löst ein interessantes Problem in der Übermittlungsarchitektur von Exchange Server 2003. Im Inetinfo-Prozess werden die Threads des erweiterten Warteschlangenmoduls ausgeführt, es werden jedoch nicht alle Nachrichten über das SMTP-Protokollmodul empfangen. Wie aus der folgenden Abbildung hervorgeht und in Nachrichtenroutingarchitektur erläutert wurde, werden Nachrichten von MAPI-Clients wie Outlook und vom Exchange-MTA durch den Microsoft Exchange-Informationsspeicherdienst an das SMTP-Transportsubsystem übergeben. Da diese Nachrichten nicht über das SMTP-Protokollmodul empfangen werden, müssen sie auf eine andere Weise an das erweiterte Warteschlangenmodul weitergeleitet werden. Dieses alternative Verfahren wird vom Exchange-Informationsspeichertreiber übernommen.

Darüber hinaus verlassen Nachrichten einen Server, auf dem Exchange Server 2003 ausgeführt wird, eventuell nicht über das SMTP-Protokollmodul. Eine Nachricht wird beispielsweise an einen Empfänger mit einem Postfach im lokalen Exchange-Informationsspeicher adressiert. In diesem Fall wird die Nachricht durch den Exchange-Informationsspeichertreiber übermittelt. Nachrichten für Remoteempfänger, die über den Exchange-MTA erreicht werden, müssen ebenfalls in den Exchange-Informationsspeicher übertragen werden, da sich die Warteschlange des Exchange-MTA für ausgehende Nachrichten im Exchange-Informationsspeicher befindet. Der Exchange-MTA steuert die Nachrichtenübertragung an Exchange 5.5-Server in der lokalen Routinggruppe, an Exchange-Remote-MTAs und an Nicht-Exchange-X.400-MTAs mithilfe eines X.400-Connectors bzw. an ein Nicht-Exchange-Messagingsystem mithilfe eines MAPI-basierten Messagingconnectors. Weitere Informationen zu Exchange-MTA finden Sie unter X.400-Transportarchitektur.

Architektur des Exchange-Informationsspeichertreibers

Es ist wichtig zu wissen, dass der Exchange-Informationsspeicher (Store.exe) und der IIS Inetinfo-Prozess (Inetinfo.exe) separate Prozesse des Betriebssystems sind, wie aus der folgenden Abbildung hervorgeht. Die virtuellen Adressräume separater Prozesse werden nicht direkt gemeinsam genutzt, sodass Inetinfo.exe nicht auf die Daten im virtuellen Adressraum von Store.exe zugreifen kann und umgekehrt. Um eine MAPI-Nachricht in die Vorübermittlungswarteschlange des erweiterten Warteschlangenmoduls aufzunehmen, muss der Exchange-Informationsspeichertreiber einen Funktionsaufruf vom virtuellen Adressraum von Store.exe zum virtuellen Adressraum des Inetinfo-Prozesses weitergeben. Außerdem muss der Exchange-Informationsspeichertreiber bei der lokalen Übermittlung einer Nachricht an ein Empfängerpostfach oder an die Nachrichtenwarteschlange des Exchange-MTA einen Funktionsaufruf in die andere Richtung weitergeben, also vom IIS-Inetinfo-Prozess zum Exchange-Informationsspeicher.

Die Ereignissenke des Exchange-Informationsspeichertreibers ermöglicht die Prozesskommunikation zwischen dem Exchange-Informationsspeicher und Inetinfo mithilfe der drei folgenden Hauptkomponenten. Diese Komponenten bilden zusammen den Exchange-Informationsspeichertreiber.

• Drviis.dll   Diese DLL wird im Inetinfo-Prozess ausgeführt und kommuniziert über SMTP StoreDriver COM-Ereignisse mit dem erweiterten Warteschlangenmodul.

• Epoxy.dll   Diese DLL implementiert den Exchange Inter-Process Communications Layer (ExIPC – Exchange-Prozesskommunikationsschicht) zwischen IIS und dem Exchange-Informationsspeicher. IIS und der Exchange-Informationsspeicher verwenden diese Kommunikationsschicht für den schnellen Austausch von Daten direkt über Prozessgrenzen. Dies geschieht über den gemeinsam genutzten Speicher, der von dieser DLL in den virtuellen Adressraum beider Prozesse geladen wird.
  Das Modell für den gemeinsam genutzten Speicher von Epoxy.dll beruht auf dem SMQ-Modell (Shared Memory Circular Queue). Das bedeutet, dass einzelne Umlaufwarteschlangen fester Größe auf der Epoxy.dll-Schicht für die Datenübertragung in beide Richtungen verwendet werden. Die Epoxy.dll-Schicht umfasst eine Bindungseinrichtung, die es dem Informationsspeichertreiber ermöglicht, eine beliebige Anzahl von Umlaufwarteschlangen zwischen IIS und dem Exchange-Informationsspeicher zu erstellen und zu verbinden. Zu dieser Bindungseinrichtung gehört ein zentraler Warteschlangen-Manager, der die Warteschlangen überwacht, die über diesen Prozess miteinander kommunizieren. Diese Bindungseinrichtung wird auch zum Lösen von Warteschlangenbindungen und zum Bereinigen von Warteschlangen verwendet.

  Anmerkung:

  Epoxy.dll verwendet lokale Remoteprozeduraufrufe (LRPCs, Local Remote Procedure Calls) und einen gemeinsam genutzten Speicherheap für die Übergabe von Daten zwischen IIS und dem Exchange-Informationsspeicher. Der gemeinsam genutzte Speicher funktioniert nur bei Prozessen, die auf demselben Computer ausgeführt werden. Wenn Epoxy.dll verwendet wird, ist die Kommunikation zwischen Remoteprozessen wie in einem reinen RPC-Szenario nicht möglich.

• ExSMTP.dll   Diese DLL wird im Exchange-Informationsspeicherprozess ausgeführt und implementiert den Protokollstub für die Kommunikation mit dem Exchange-Informationsspeicher über EPOXY und mit der Inetinfo-Schnittstelle von Drviis.dll.

Installierbares Dateisystem von Exchange

Zur Minimierung der Unterschiede zwischen dem Exchange-Informationsspeichertreiber und dem NTFS-Informationsspeichertreiber, der in Windows Server 2003 enthalten ist, implementiert Exchange Server 2003 ein Microsoft Win32-Dateisystem mithilfe der Streamingdatenbanken (.stm) im Exchange-Informationsspeicher. Die STM-Datei eines Exchange-Informationsspeichers enthält Internetnachrichten in ihrem jeweiligen Format (unformatierter Text, MIME oder UUEncode), während in der entsprechenden EDB-Datei Nachrichten im MAPI-Format gespeichert sind. Die STM-Datei der Streamingdatenbank enthält keine Verzeichnisstruktur. Die Strukturen des Exchange-Informationsspeicher werden in der EDB-Datei in Nachrichtentabellen verwaltet. Weitere Informationen zur Architektur und zum Design von Messagingdatenbanken finden Sie unter Architektur des Exchange-Informationsspeicherdiensts.

Das installierbare Dateisystem von Exchange besteht aus den folgenden Hauptkomponenten (siehe folgende Abbildung):

• Exifs.sys   Dies ist ein Kernelmodustreiber, mit dem der Exchange-Informationsspeichertreiber Elemente aus Messagingdatenbanken lesen bzw. Elemente in diese Datenbanken schreiben kann. Dieser Treiber enthält die Win32-Datei-API für den Exchange-Informationsspeicher.
• Exwin32.dll   Dies ist eine Erweiterung des Exchange-Informationsspeichers, die im Prozess Store.exe ausgeführt wird und Exifs.sys-Anforderungen für Vorgänge auf Dateiebene (wie Erstellen, Öffnen, Umbenennen, Übergeben, Löschen usw.) verarbeitet. Beachten Sie, dass es sich hierbei um eine Benutzermoduskomponente handelt, die für Operationen im Win32-Dateisystem verwendet wird. Die Win32-Dateien werden nicht vom SMTP-Transportsubsystem verwendet.
• Ifsproxy.dll   Dies ist ein Benutzermoduswrapper für Exwin32.dll, der eine unkomplizierte Schnittstelle für Win32-Dateisystemaufrufe zur Verfügung stellt. Ifsproxy.dll spielt zudem eine entscheidende Rolle bei der Zuordnung von freiem Speicherplatz in der STM-Datei. ExIFS fordert bei der Zuordnung von freiem Speicherplatz in einer Datenbank Speicherplatz von ESE an. Wenn der Exchange-Informationsspeichertreiber z. B. ein neues Element im Exchange-Informationsspeicher erstellt, um eine Nachricht lokal zu übermitteln, fordert ExIFS Speicherplatz von ESE an.

ExIFS unterstützt zwei verschiedene Dateizugriffsmodi.

• Win32   Dieser Modus beruht auf Dateinamen und dient dazu, den Exchange-Informationsspeicher im Dateisystem ähnlich darzustellen wie ein Festplattenlaufwerk. Das Betriebssystem ordnet den Dateinamespace \\.\backofficestorage dem installierbaren Dateisystem von Exchange zu. Dieser Namespace ermöglicht den Zugriff auf alle privaten und öffentlichen Datenbanken. Das Format lautet file://./backofficestorage/Domänenname, beispielsweise file://./backofficestorage/fabrikam.com.

  Anmerkung:
  Hinweis   Win32-Dateien werden vorwiegend vom HTTP-DAV-Protokoll sowie von den APIs EXOLEDB und CDOEX verwendet.

• EA   EA ist das Akronym für Extended Attributes (erweiterte Attribute), die in einer speziellen Eigenschaft jeder Nachricht gespeichert werden. ExIFS kopiert die erweiterten Attribute in eine speicherinterne Struktur, die so genannte Scatterliste (SLIST). Bei der Scatterliste handelt es sich eigentlich um ein BLOB (Binary Large Object), das zum Öffnen eines Nachrichtenelements verwendet werden kann. EA-Dateien sind für die interne Verwendung durch das Exchange-Transportsubsytem vorgesehen und können von Benutzern nicht durch eine der dokumentierten APIs bzw. eines der dokumentierten Protokolle angezeigt werden. Ein EA-Pfad kann folgendermaßen dargestellt werden: \;E:\Ted\$705260a-46c4-454d-b0dd-96b9c605364\369b6c05-0256-46c7-fad3-54ffa867d089-0000001e.

  Anmerkung:
  Hinweis   Die Komponenten im SMTP-Transportsubsystem verwenden zum Öffnen von Dateien im ExIFS ausschließlich erweiterte Attribute.

Übertragung ausgehender Nachrichten

Der Exchange-Informationsspeichertreiber führt an einer ausgehenden Nachricht die folgenden Schritte aus, um sie an die Vorübermittlungswarteschlange des erweiterten Warteschlangenmoduls zu übergeben.

1. Wenn ein Benutzer von Outlook eine Nachricht sendet, wird sie in den Postausgang des Benutzerpostfachs gestellt und zur Übermittlung gekennzeichnet.

2. Der Exchange-Informationsspeicher stellt die Nachricht in seinen internen SendQ-Ordner und ruft den Exchange-Informationsspeichertreiber auf, die Nachricht an IIS zu übertragen.

3. ExSMTP.dll ermittelt die Ordner-ID (FID, Folder Identifier) und die Nachrichten-ID (MID, Message Identifier) der Nachricht und liest die übermittlungsrelevanten Nachrichteneigenschaften (Absender- sowie Empfängeradresse und ob Übermittlungsberichte angefordert werden). ExSMTP.dll formatiert diese Eigenschaften in einen Eigenschaftenstream für das MailMsg-Objekt um. ExSMTP.dll fügt die FID und MID der Nachricht hinzu, sodass der Nachrichteninhalt später gegebenenfalls von Drviis.dll im Inetinfo-Prozess abgerufen werden kann. Durch die FID wird der Nachrichtenordner im Exchange-Informationsspeicher, der die Nachricht enthält, eindeutig bestimmt. Durch die MID erhält die Nachricht selbst eine eindeutige Kennung.

   Anmerkung:

   Hinweis   Der Nachrichtenumschlag enthält nicht den Nachrichteninhalt. Die Informationen im Nachrichtenumschlag werden von Epoxy.dll an Inetinfo übergeben. ExIFS.sys dient dazu, bei Bedarf den Nachrichteninhalt bereitzustellen. Ein Zugriff auf den Inhalt der Nachricht ist unter Umständen niemals erforderlich, wenn es sich um eine Übermittlung zwischen lokalen Adressen oder um eine Übermittlung von einer lokalen Adresse an einen Exchange-MTA handelt. Der RFC 822-Inhalt muss nur bei der Übermittlung an Empfänger in anderen Postfachspeichern, bei ausgehender SMTP-Übermittlung oder bei Ereignissenken erzeugt werden, die den Inhalt während eines Übermittlungsereignisses anfordern.

4. ExSMTP.dll übergibt mittels einer Umlaufwarteschlange für den gemeinsamen Speicher einen Zeiger auf den gemeinsam genutzten Speicherabschnitt an Drviis.dll. Wie aus Abbildung 6.13 hervorgeht, verweist der Zeiger auf den Abschnitt des zugeordneten gemeinsamen Speichers, der den Eigenschaftenstream des Umschlags, die Ordner-ID und die Nachrichten-ID enthält.
   

   Anmerkung:
   Hinweis   Speicher für den Code und den Stapel wird nicht nur während der Laufzeit durch das Betriebssystem zugeordnet, sondern Speicher wird auch dynamisch durch einen Heap zugeordnet und freigegeben.

5. Der Zeiger wird auf der Inetinfo-Seite von Drviis.dll aus der Speicherumlaufwarteschlange entfernt. Der Zeiger verweist auf den gemeinsamen Speicher, der den Eigenschaftenstream des Umschlags, die Ordner-ID und die Nachrichten-ID enthält.

6. Drviis.dll liest mithilfe des Speicherzeigers den Eigenschaftenstream aus dem gemeinsamen Speicher in ein MailMsg-Objekt. Wie bereits weiter oben in diesem Kapitel erwähnt, besteht das MailMsg-Objekt aus einem Nachrichtenübertragungsumschlag, der die Informationen zum Weiterleiten der Nachricht zum nächsten Hop enthält, sowie aus einem Zeiger auf die eigentliche physische Nachricht. An diesem Punkt enthält das MailMsg-Objekt die Informationen des Nachrichtenübertragungsumschlags, da sich sämtliche Eigenschaften des MailMsg-Objekts in dem gemeinsam genutzten Speicherblock befinden, der von ExSMTP.dll erstellt wurde.

7. Drviis.dll stellt das MailMsg-Objekt in die Vorübermittlungswarteschlange. Die Nachricht kann nun vom Transportsubsystem verarbeitet werden.

8. Das erweiterte Warteschlangenmodul löst seine Übermittlungs- und Systemereignisse aus, um das Basis- und das Exchange-Kategorisierungsmodul, das Routingmodul und weitere registrierte Ereignissenken aufzurufen und die Nachricht zu verarbeiten. Die meisten Übermittlungsschritte werden mithilfe des Nachrichtenübertragungsumschlags ausgeführt. Der Nachrichteninhalt wird erst dann geöffnet, wenn dies explizit erforderlich ist. Dies geschieht z. B., wenn das Exchange-Kategorisierungsmodul den Inhalt konvertieren muss. Muss die Nachricht per SMTP zum nächsten Hop übertragen werden, muss das SMTP-Protokollmodul auf den Nachrichteninhalt im RFC 822-Format zugreifen.

   Anmerkung:
   Hinweis   Bei lokaler Übermittlung von MAPI-Nachrichten (die ohne Inhaltskonvertierung von demselben Server gesendet und empfangen werden) wird der Inhalt nie von den SMTP-Transportkomponenten geöffnet (es sei denn, Sie haben benutzerdefinierte Ereignissenken installiert, die den RFC 822-Nachrichteninhalt zu lesen versuchen, beispielsweise eine Archivsenke).

9. Wenn der Nachrichteninhalt von einer Komponente im Transportsubsystem durch Aufrufen der Methode ReadContent oder WriteContent des MailMsg-Objekts geöffnet wird, erfolgt der Zugriff auf den Nachrichteninhalt wie auf eine Datei; dies lässt sich mit dem Zugriff auf Nachrichtenelemente im Ordner \Queue des Dateisystems vergleichen (z. B. bei Nachrichten, die per SMTP gesendet werden müssen). Werden Nachrichten durch den Exchange-Informationsspeicher übermittelt, werden ExIFS-Dateien anstelle von NTFS-Dateien verwendet.

10. Für Nachrichten im Exchange-Informationsspeicher ruft MailMsg die Bibliothek Drviis.dll auf, um eine gewöhnliche Dateizugriffsnummer zu öffnen. Der Nachrichteninhalt wird im RFC 822-Format angefordert. Bei kategorisierten Nachrichten enthält der Eigenschaftenstream eventuell auch einige zusätzliche ausgehende Konvertierungswerte, mit denen beim Abrufen des Inhalts ein bestimmtes Format angefordert werden kann.

11. Wie weiter oben in diesem Kapitel erwähnt, speichert Drviis.dll einen Zeiger auf die physische Nachricht im MailMsg-Objekt. Dieser Zeiger besteht aus der Ordner-ID und der Nachrichten-ID der Nachricht. Drviis.dll verwendet diesen Zeiger sowie zusätzliche Parameter für die Inhaltsformatierung, um durch Epoxy.dll ein Nachrichtenanforderungspaket an Exsmtp.dll im Prozess Store.exe zu übergeben.

12. Exsmtp.dll ruft eine interne Methode des Exchange-Informationsspeichers namens EcGetMime zusammen mit der Ordner-ID und der Nachrichten-ID auf, um den Inhalt der Nachricht im RFC 822-Format anzufordern. Dabei werden eventuell weitere Parameter angegeben, die von Drviis.dll übergeben wurden.

    Anmerkung:

    Hinweis   In Einträgen des Anwendungsereignisprotokolls sehen Sie möglicherweise, dass für den Aufruf der Methode EcGetMime als Ereignisquelle „MSExchangeTransport“ und als Ereigniskategorie „Exchange-Informationsspeichertreiber“ angegeben wird. For an example, see Microsoft Knowledge Base article 319682, "XGEN: The Exchange 2000 Information Store Reports an Event ID327 Warning Message and Virtual Memory May Be FragmentedXGEN: The Exchange 2000 Information Store Reports an Event ID327 Warning Message and Virtual Memory May Be Fragmented."

13. Da die Nachricht von Outlook übermittelt wurde, hat die Nachricht nicht das RFC 822-Format. Die Nachricht weist das MAPI-Format auf und ist in der EDB-Datei gespeichert. Daher ist der von Exsmtp.dll angeforderte Inhalt nicht in der Streamingdatenbank (die von ExIFS verwendet wird) vorhanden, wenn die Nachricht von einer Transportkomponente oder einem Internetclient geöffnet wird.

    Anmerkung:
    Hinweis   Exchange Server 2003 speichert Nachrichten, die von MAPI-Clients, X.400-Connectors oder EDK-basierten Connectors (Exchange Development Kit) empfangen wurden, in der EDB-Datenbank im MAPI-Format.

14. Wenn die Nachricht nicht in der Streamingdatenbank vorhanden ist, muss sie mithilfe der verschiedenen Eigenschaften und Tabellen erstellt werden, die in der EDB-Datenbank enthalten sind und die die Nachricht beschreiben. Daher verwendet der Exchange-Informationsspeicher IMAIL, um eine temporäre ExIFS-Datei zu erstellen, und stellt die Nachricht aus der Datenbank entsprechend den angeforderten und übergebenen Formatierungsparametern in dieser Datei im RFC 822-Format dar.

    Anmerkung:
    Hinweis   Das Exchange-Kategorisierungsmodul wendet mithilfe des IMAIL-Mechanismus Nachrichtenformate auf den Inhalt an. Maßgeblich sind hierbei die Festlegungen für Internetdomänen im Exchange-System-Manager bzw. die Festlegungen des Benutzers für den jeweiligen Empfänger in Outlook. Werden keine Formatierungsparameter an IMAIL übergeben, werden MAPI-Nachrichten im S/TNEF formatiert.

15. In Exchange Server 2003 erstellt ExIFS.sys eine temporäre ExIFS-Datei, sodass eine fehlerhaft arbeitende Ereignissenke, die den RFC 822-Inhalt zu ändern versucht, die übermittelten Seiten in der Streamingdatenbank nicht beschädigen kann. Die Ereignissenke schreibt keine wirklichen Inhaltsseiten, sondern lediglich eine Kopie.

16. Sobald die temporäre ExIFS-Datei erzeugt ist, wird die Dateizugriffsnummer wieder an Exsmtp.dll übergeben. Exsmtp.dll ruft ExIFS auf, um einen Zeiger auf die Seiten abzurufen, welche die Datei in der Streamingdatenbank belegt (d. h., einen Zeiger auf die erweiterten Attribute, die ExIFS in eine speicherinterne Struktur, die Scatterliste, kopiert).

17. Exsmtp.dll kopiert die Scatterliste in den gemeinsam genutzten Speicher und übergibt die Liste durch Epoxy.dll wieder an Drviis.dll.

18. Drviis.dll öffnet mithilfe dieser Scatterliste die ExIFS-Datei als EA-Datei. Da Drviis.dll jetzt über die geöffnete ExIFS-Dateizugriffsnummer verfügt, wird die Dateizugriffsnummer an MailMsg zurückgegeben, sodass Anforderungen an die Methode ReadContent oder WriteContent für den RFC 822-Nachrichteninhalt verarbeitet werden können.

19. Das SMTP-Protokollmodul kann nun den Nachrichteninhalt lesen und die Daten per SMTP an einen Remotehost oder einen Exchange-Server übertragen.

20. Nach der erfolgreichen Nachrichtenübertragung löscht das erweiterte Warteschlangenmodul das MailMsg-Objekt, da es nicht mehr benötigt wird. Dementsprechend ruft das erweiterte Warteschlangenmodul den Exchange-Informationsspeichertreiber (drviis.dll) auf, um die Nachricht zu löschen. Drviis.dll erzeugt eine Anforderung zum Löschen der Nachricht im gemeinsam genutzten Speicher und überträgt die Anforderung durch EPOXY an Exsmtp.dll. Exsmtp.dll verschiebt die Nachricht entweder aus dem Postausgang des Absenders in den Ordner Gesendete Objekte oder löscht die Nachricht.

Anmerkung:

Hinweis   Der Inhalt wird bei jeder Anforderung neu dargestellt. Dabei wird jedes Mal eine temporäre ExIFS-Datei erzeugt. Solange diese Datei geöffnet bleibt, kann sie verwendet werden. Nachdem die Datei geschlossen wurde, wird sie automatisch verworfen, da es sich lediglich um eine temporäre Kopie der Nachricht handelt. Um die Anzahl der Darstellungszyklen zu minimieren, bleibt die Inhaltsdatei im erweiterten Warteschlangenmodul geöffnet, bis die Nachricht übertragen oder zugestellt wurde. Die Inhaltsdatei wird nur geschlossen, wenn Nachrichten gelöscht werden können oder zu einem späteren Zeitpunkt ein erneuter Übermittlungsversuch geplant ist. Die Übermittlung der Nachricht wird möglicherweise zu einem späteren Zeitpunkt wiederholt, entweder da der Remoteserver nicht verfügbar ist oder weil mehr als 10.000 Inhaltsdateien geöffnet sind und aktiv in der Warteschlange verarbeitet werden. Sind über 10.000 Inhaltsdateien geöffnet, die aktiv verarbeitet werden, müssen einige Dateien geschlossen werden, um Platz für andere Nachrichten zu schaffen. Wenn eine Nachricht zu einem späteren Zeitpunkt erneut geöffnet wird (z. B. da die Nachrichtenübertragung wiederholt wird), muss der Inhalt neu dargestellt werden. Es ist wichtig zu wissen, dass IMAIL eine neue temporäre ExIFS-Datei darstellt, wenn die Datei geöffnet wird. Änderungen an dieser ExIFS-Datei gehen verloren, wenn die Datei geschlossen wird.

Übertragung eingehender Nachrichten

Für eingehende Nachrichten, die an einen lokalen Empfänger oder den Exchange-MTA übermittelt werden müssen, führt der Exchange-Informationsspeichertreiber die folgenden Schritte aus.

1. Eine Nachricht wird entweder durch das SMTP-Protokollmodul oder den Exchange-Informationsspeichertreiber in die Vorübermittlungswarteschlange gestellt, anschließend kategorisiert und zur lokalen Übermittlung gekennzeichnet.

2. Das erweiterte Warteschlangenmodul löst ein SMTP StoreDriver-Ereignis aus, um der Ereignissenke des Exchange-Informationsspeichertreibers zu signalisieren, dass eine Nachricht an den Exchange-Informationsspeicher übertragen werden soll.

3. Wenn die Nachricht über eine SMTP-Verbindung oder über den Ordner \Pickup empfangen wird, befindet sich die Nachricht weiterhin im Ordner \Queue. Dementsprechend ruft Drviis.dll die Methode CreateFile() auf, um eine neue Datei in ExIFS zu erstellen, und kopiert das Nachrichtenobjekt in die neue Datei im Exchange-Informationsspeicher.

   Anmerkung:

   Hinweis   Werden Nachrichten von demselben Postfachspeicher gesendet, in dem sie empfangen werden, wird der Inhalt nicht in den Informationsspeicher kopiert. Werden Nachrichten von verschiedenen Postfachspeichern auf demselben Server gesendet und empfangen, wird die Nachricht unter Verwendung von RFC 822 S/TNEF als Zwischenformat kopiert. Der Inhalt wird vom Exchange-Informationsspeicher nicht für den Inetinfo-Prozess bereitgestellt. Die Verarbeitung erfolgt im Exchange-Informationsspeicher. IMAIL stellt den Inhalt auf Anforderung durch Exsmtp.dll im S/TNEF in einer ExIFS-Datei dar. Mithilfe dieser ExIFS-Datei erstellt der Exchange-Informationsspeicher eine neue Nachricht, die an den Postfachspeicher übermittelt wird, der das Postfach des Empfängers enthält.

4. Bei Verwendung von SMTP und des Ordners \Pickup gibt ExIFS die Scatterliste zurück, die den Ort der Daten des neuen Elements in der Streamingdatenbank angibt.

5. Drviis.dll ordnet Speicher aus dem gemeinsam genutzten Speicherheap zu und fügt die Scatterliste in den zugeordneten Speicherblock ein. Ein Zeiger auf diesen Abschnitt des zugeordneten gemeinsamen Speichers wird daraufhin in die Warteschlange für den Store.exe-Prozess aufgenommen.

6. ExSMTP.dll empfängt den Zeiger von der Warteschlange auf der Seite des Exchange-Informationsspeichers. Der Zeiger verweist auf den gemeinsam genutzten Speicher, der die Scatterliste für die eingehende Nachricht enthält.

7. ExSMTP.dll ruft Ifsproxy.dll mit der Scatterliste auf, um von ExIFS eine Dateizugriffsnummer zu erhalten. Zur Übergabe des Objekts an die Datenbank muss eine Nachricht erstellt werden. Daher ruft ExSMTP.dll den Exchange-Informationsspeicherkernel (Store.exe) über die externe Schnittstelle der Messagingdatenbank (MDBEIF, Messaging Database External Interface) auf, um ein Nachrichtenobjekt zu erstellen. ExSMTP.dll übergibt anschließend die Dateizugriffsnummer für den Inhalt explizit an den Exchange-Informationsspeicherkernel. Dieser wiederum übergibt die Dateizugriffsnummer an ESE, um die Daten zu übermitteln, wenn ExSMTP.dll das Nachrichtenobjekt übergibt.

   Anmerkung:
   Hinweis   In der MAPI-basierten Datenbankdatei (.edb) werden Seitenprüfsummen gespeichert. Die Streamindatenbankdatei (.stm) enthält keine Seitenprüfsummen.

8. Der Exchange-Informationsspeicher informiert Outlook, wenn eine neue Nachricht eintrifft, und Outlook listet die Nachricht im Ordner Posteingang auf.

9. ExSMTP.dll informiert Drviis.dll durch EPOXY darüber, dass die Übermittlung abgeschlossen ist. Daraufhin gibt Drviis.dll an das erweiterte Warteschlangenmodul ein positives Ergebnis zurück. Die Nachricht kann anschließend vom erweiterten Warteschlangenmodul auf folgende Weise gelöscht werden:

   • Die Nachricht wurde über SMTP oder das Verzeichnis \Pickup empfangen   Das Verzeichnis \Queue enthält eine EML-Datei für die Nachricht. Das erweiterte Warteschlangenmodul ruft erneut MailMsg auf, damit die Nachricht gelöscht wird. Da das MailMsg-Objekt an den NTFS-Informationsspeichertreiber gebunden ist, wird der Aufruf an NTFSDrv.dll übergeben. NTFSDrv.dll löscht die Nachricht aus dem Verzeichnis \Queue im Dateisystem.
   • Die Nachricht wurde über den Exchange-Informationsspeichertreiber übermittelt   Das erweiterte Warteschlangenmodul ruft erneut MailMsg auf, damit die Nachricht gelöscht wird. Da das MailMsg-Objekt an den Exchange-Informationsspeichertreiber gebunden ist, wird der Aufruf an Drviis.dll übergeben und eine EPOXY-Anforderung an ExSMTP.dll in eine Warteschlange gestellt. ExSMTP.dll verschiebt die Nachricht daraufhin entweder aus dem Postausgang des Absenders in den Ordner Gesendete Objekte oder löscht die Nachricht.

Anmerkung:

Hinweis   Nachrichten für Remoteempfänger, die über das Verzeichnis \Pickup oder das SMTP-Protokollmodul eintreffen, erreichen den Exchange-Informationsspeicher nicht. Sie bleiben vielmehr im Ordner \Queue des Dateisystems, bis sie erfolgreich zum nächsten Hop auf der Route zu ihrem Ziel übertragen werden. Das Kategorisierungsmodul verwendet unter Umständen jedoch den Exchange-Informationsspeicher für Nachrichten, die nicht durch den Exchange-Informationsspeichertreiber übermittelt werden. Das Kategorisierungsmodul muss eventuell Benachrichtigungen über den Übermittlungsstatus erzeugen, die im Exchange-Informationsspeicher erstellt werden.

Wiederholte Übertragungsversuche

Beachten Sie, dass Nachrichten, die über den Exchange-Informationsspeichertreiber in das erweiterte Warteschlangenmodul gelangen, während des Kategorisierungs- und Routingprozesses sowie während der eigentlichen Übertragung im Exchange-Informationsspeicher bleiben. Die Nachrichten werden nicht in den Ordner \Queue des virtuellen SMTP-Servers kopiert. Diese Nachrichten bleiben auch dann im Exchange-Informationsspeicher, wenn ein Verbindungsfehler aufgetreten ist und die Verbindung erneut hergestellt werden muss. Wenn eine Nachricht nicht sofort übertragen werden kann, wird sie in eine temporäre Tabelle verschoben. Die Nachricht wird daher nicht mehr im Ordner Postausgang des Absenders angezeigt und in den Ordner Gesendete Objekte kopiert (wenn Outlook so konfiguriert ist, dass eine Kopie aller Nachrichten in diesem Ordner abgelegt wird). Die Nachricht bleibt in der temporären Tabelle, bis sie erfolgreich übertragen wird oder abgelaufen ist. Mit dem Snap-In Warteschlangenanzeige des Exchange-System-Managers können Sie diese Nachrichten in der Warteschlange für Nachrichten mit fehlerhafter Übermittlung anzeigen.