Exchange 2000/2003 MTA und Routing

Das Nachrichten Routing bei Exchange 5.5 war X.400 basiert und nutzte den MTA-Dienst. Dieser hat die Nachrichten aus den Warteschlangen geholt und weiter verteilt. Der SMTP-Connector war nur ein "Anhängsel" des MTA, d.h. ohne den MTA lief nichts innerhalb von Exchange 5.5. Der MTA hat seine Wegewahl anhand der Routing Tabelle getroffen, welche über den normalen Verzeichnisabgleich in der Organisation aktualisiert wurde.

Exchange 2000 hat einen gänzlich anderen Mechanismus zum übermitteln von Nachrichten und Leitwegeinformationen. Aufgrund der Verbreitung des Internet und der erwiesen robusten Funktion von SMTP und DNS und dem immensen Aufkommen von "MIME-codierten" Nachrichten ist Exchange 2000 nun ebenfalls ein SMTP-basiertes Übermittlungssystem. Natürlich kann Exchange auch weiterhin mit X.400 Systemen und alten Exchange 5.5. Servern per MTA kommunizieren, aber zwischen Exchange 2000 Servern und Routinggruppen wird in der Regel "SMTP" gesprochen.

Die Rolle des MTA

Der Microsoft Exchange MTA ist in einer reinen Exchange 2000x Umgebung nicht mehr unbedingt nötig, da der Exchange 2000/2003 Routing Service in Verbindung mit dem virtuellen SMTP-Server hier die meiste Arbeit übernimmt. Der MTA ist eigentlich nur noch für folgende Tätigkeiten erforderlich.

Entsprechend können Sie natürlich den MTA deaktivieren, wenn Sie seine Funktion wirklich nicht mehr benötigen.

Routing Extrem

Um etwas Licht in das Exchange Routing zu bringen, habe ich eine kleine Testreihe aufgebaut.

Nun wurden von intern mit Outlook Nachrichten an folgende Empfänger gesendet:

Um das genaue Verhalten von Exchange zu ermitteln, wurde folgende Testreihe durchgeführt.

Richtlinie Connector Test
Adressraum		 Empfänger Ergebnis
firma.tld
autoritativ		 Nicht installiert Unknown@firma.tld NDR vom Postfachserver
user@host.firma.tld Queue Internet Connector
Smtp:firma.tld Unknown@firma.tld NDR vom Postfachserver
user@host.firma.tld Queue Internet Connector
Smtp:*.firma.tld Unknown@firma.tld NDR vom Postfachserver
user@host.firma.tld Queue TEST Connector
firma.tld
NICHT autoritativ		 Nicht installiert Unknown@firma.tld Queue Internet Connector
user@host.firma.tld Queue Internet Connector
Smtp:firma.tld Unknown@firma.tld Queue TEST Connector
user@host.firma.tld Queue Internet Connector
Smtp:*.firma.tld Unknown@firma.tld Queue Internet Connector
user@host.firma.tld Queue TEST Connector

Aus der Tabelle ist gut zu erkennen, dass Exchange Mails von intern auf die Hostadresse user@host.firma.tld immer zustellt, auch wenn Exchange Autoritativ für firma.tld ist. Die Zustellung kann aber mit einem Connector mit dem passenden Adressraum gesteuert werden. Nur genau entsprechende Adressen werden von Exchange mit einem NDR beantwortet, wenn der Empfänger nicht in der Organisation zu finden ist.

Ist Exchange jedoch nicht autoritativ, dann werden die Mails von unbekannten Empfängern prinzipiell über Connectoren weiter versendet.

Sonderfall Alternate-Recipient / Target Address

Normalerweise löst Exchange jede SMTP-Mail gegen das Active Directory auf und sucht das entsprechende Zielpostfach. Wird die SMTP-Adresse im AD gefunden, dann stellt Exchange die Mail in das dazugehörige Postfach zu. Das kann durchaus über mehrere Server und Connectoren laufen.

Allerdings gibt es einen Fall, in dem Exchange sich nicht um die Empfängerrichtlinien und das interne Routing kümmert, sondern die Mail als "geht ins Internet" betrachtet und entsprechend den Adressräumen der SMTP-Connectoren aus  der Exchange Organisation hinaus sendet. Dies ist z.B.: bei Kontakten der Fall.

Exchange unterscheidet, ob die SMTP-Adresse "nur" eine Adresse von vielen in den "ProxyAddresses" ist  (Siehe auch AD LDAPFelder), sondern ob die Adresse als "TargetAddress" ausgeführt wird. Wenn Sie z.B.: als Domäne "firma.de" in ihren Empfängerrichtlinien definiert haben, dann haben meist alle Postfächer auch diese Adressen. Nun können Sie aber einen Kontakt anlegen, der ebenfalls "username@firma.de" als Zieladresse hat.

Wenn Sie nun annehmen,  dass Exchange die Mail versucht, intern aufzulösen, dann haben Sie sich geirrt. Auch wenn diese Zieldomäne eigentlich "intern" ist und selbst wenn es intern sogar ein Postfach mit dieser Adresse geben würde, so wird Exchange 200x die Mail auf dem kürzesten und günstigsten Weg aus der Organisation hinaus in das Internet sendet. Das passiert sogar, wenn es sich dabei um ein Postfach handelt, bei dem Sie manuell (LDAP, ADSIEDIT o.ä.) das Attribut gesetzt haben.

Nun mag man sich fragen, was das eigentlich soll zumal viele nun sagen werden, dass Exchange dank MX-Record die Mail ja wieder direkt zu sich selbst zurück sendet und damit eine Schleife baut. Diese Funktion ist aus meiner Sicht z.B. für folgende Fälle interessant.

Damit diese Lösungen aber funktionieren, müssen Sie natürlich sicherstellen, dass die Mails tatsächlich an diese externen Mailserver gehen. Dazu richten Sie am besten einen  Internet Mail Connector ein, welcher nur  ihren eigenen Adressraum bedient und direkt an die gewünschten Server zustellt. Eine Zustellung über eine DNS-Auflösung wird die Mail sonst vermutlich direkt zu ihnen zurück senden.

Routing, DNS und DNS-Hostname

Eine weitere Tücke im Detail verbirgt der DNS-Hostname, welchen Sie im virtuellen SMTP-Server pflegen können. Viele Administratoren verändern diesen Namen, weil Sie z.B.: möchten, dass sich Exchange bei der Kommunikation mit dem Internet per SMTP nicht mit ihrem "echten" Namen melden. Allerdings hat diese Einstellung noch weitere Auswirkungen.

Das Problem tritt nicht bei Umgebungen mit nur genau einem Server aus, sondern nur wenn mehrere Server miteinander kommunizieren und der geänderte Name intern nicht eindeutig auf den gleichen Server verweist

Ein falscher Name kann nämlich das interne Exchange Routing komplett stören. Microsoft hat nicht umsonst den Button "DNS überprüfen" an diese Stelle hinzugefügt.

Leider wird dabei gerne übersehen, dass diese Änderung nicht nur in der METABASE des SMTP-Servers hinterlegt wird, sondern auch in der Exchange Konfiguration, wie man mit ADSIEDIT leicht auslesen kann.

Das entsprechende Feld lautet "msExchSmtpFullyQualifiedDomainName". Und auch in WinRoute wird der FQDN mit aufgeführt.

Damit sollten Sie erkennen, dass dieser Hostname für das Exchange Routing essentiell wichtig ist. Die Informationen in der Exchange Konfiguration werden von der Exchange Routingengine ausgewertet und auch auch für die interne Mailzustellung verwendet.

Sie können sich nun natürlich denken, was bei einer Änderung dieses Namens so alles passieren kann.

Leider ist diesem Verhalten auch nicht so einfach durch einen zweiten virtuellen SMTP-Server beizukommen, der z.B. auf einer eigenen IP-Adresse lauscht und für den ausgehenden SMTP-Connector konfiguriert wird. Denn intern sind dann beide Server Bestandteil der Routinggruppe.

Unterm Strich bedeutet dies: "Finger weg" von diesem Namen. Sorgen Sie dafür, dass der Name wirklich dem Hostnamen entspricht und eindeutig ist. Wenn Sie aber nach extern von von extern ihre Nachrichten senden und empfangen und dabei z.B. eine abweichende SMTP-Meldung haben wollen, dann fahren Sie am besten mit einem Relay zwischen Exchange und Internet.

Wenn Sie den Eintrag im virtuellen SMTP-Server ändern, dann kann es sein, dass Exchange diese Änderung nicht im Routing übernimmt (Kontrolle mit Winroute). Meist hilft es dann, z.B.: im SMTP-Connector einfach einen Wert zu ändern und wieder zurück zu ändern, so dass man einmal "übernehmen" sagen kann. Soe ein Änderung triggert die Routingengine an, die Daten neu einzulesen. (Kontrolle mit Winroute)

Rerouting

Keine Konfiguration ist für immer statisch und so stehen Sie als Administrator irgendwann einmal vor der Aufgabe, das Mailrouting zu ändern. Sie müssen als Connectoren addieren und entfernen, Dienste durchstarten etc. Da fragt man sich dann doch mal, was Exchange hier im Detail macht, wenn Sie z.B. einen Routinggroup Connector löschen, in dessen Warteschlange noch Nachrichten stehen. Werden diese Mails gelöscht, als unzustellbar zurückgewiesen oder gar neu einsortiert ?.

Hierzu müssen sie nur ganz wenige Fakten wissen:

Tipp:
Richten Sie erst die neuen Connectoren ein und erhöhen Sie dann die Kosten der Connectoren, die sie demnächst entfernen wollen oder halten Sie diese Warteschlange an. (Fixieren). Wenn ihr Routing korrekt ist, dann sollte in der alten Wartenschlange keine Mail "stecken" bleiben

Unterstützung durch Net at Work:
Gerade in größeren Umgebungen kann eine Umstellung  etwas Zeit bedeuten und nicht jeder kann auf allen Servern alle Warteschlangen überwachen. Wenn Sie keine Hilfsmittel wie MOM2005 o.ä. einsetzen, dann könnten wir Sie mit QStatus während der Umstellung unterstützen.

Insofern ist es also kein Problem, das Routing im laufen Betrieb zu ändern. Allerdings bietet es sich an, zuerst die neuen Wege zu konfigurieren und deren Nutzung zu prüfen und dann die alten Wege zu entfernen. Auch eine Überwachung der Warteschlangen ist angeraten.

Der Weg durchs System

Zuletzt möchte ich noch ein paar Details zur internen Verarbeitung beim Routing aufführen, die für das Verständnis sehr hilfreich sein können.

Ausgehende Nachrichten

Wird eine Mail von einem Exchange Postfach zu einem anderen Exchange Postfach, einem externen Mailsystem (z.B. Internet) oder einem Connector (z.B. Notes) versendet, dann passiert folgendes:

  1. Store bekommt Mail mit Empfängerliste
    Outlook legt also die Mail in den Postausgang ihrer Mailbox ab. Das Mailobjekt enthält eine Liste aller Zielempfänger
  2. Store Driver -> Advanced Queuing component
    Die Mail wird dann vom Store zum Queueing des virtuellen SMTP-Servers übergeben und dort in die  Warteschlange "pre-categorization queue" eingestellt
  3. Kategorisierung
    Der "Categorizer" ist nun bemüht, die Empfänger als auch den Absender im Active Directory aufzulösen und Verteiler in einzelne Empfänger zu zerlegen.
  4. Routing
    Abhängig vom Ziel wird die Mail nun je Empfänger weiter verteilt:
    Lokale Empfänger: Mail geht zum Informationsstore, welcher diese lokal zustellt. Der Prozess ist beendet
    Entfernte Empfänger: Ablage in der Warteschlange "post-categorization queue"
  5. Routing Engine
    Alle Mails, die den Server verlassen müssen, werden von der Routing Engine nun abgeholt und anhand der Zieladresse weiter geleitet:
    Andere Exchange Server in der Organisation: Weitergabe per SMTP
    Fremde Connectoren: Mail wird an den den Server für dieses Gateway übertragen und dort dann an den MTA übermittelt. Dieses Gateway muss die Mail aus dem ordner "MTS-OUT" abholen, übersetzen und zustellen. Wenn das Gateway nicht läuft, dann wird der MTA weiterhin Mails in diese Warteschlange senden. Überwachen Sie daher diese Mailbox, damit Sie Störungen schnell erkennen.

Ein Versucht, die auch visuell darzustellen, ist folgendes Bild:

Winroute

Winroute ist ein Tool auf der Exchange 2000 bzw. Service Pack CD im jeweiligen Support Unterverzeichnis -siehe WINROUTE

Weitere Links

Keywords:Routing MTA