Wie wird ein Connector angebunden ?

Auch wenn Sie nicht gleich ihren eigenen Connector schreiben wollen, so ist etwas Verständnis zu den Hintergründen eine wichtige Basis für die Fehlersuche. Connectoren gibt es seit der ersten Version von Exchange und sind zum Teil dazu geeignet, eine Verbindung zwischen Exchange Standorten und Servern in der gleichen Organisation herzustellen (z.B. X.400, SMTP-RG, RG-Connector) und zum anderen um Fremdsysteme an eine Exchange Organisation anzubinden, z.B. MS-Mail, Fax, SMS, Notes und X.400. Um die letzteren Connectoren geht es auf dieser Seite.

Zwar ist SMTP das mittlerweile gebräuchliche Protokoll zum Austausch von Nachrichten aber dennoch gibt es weiterhin die Anforderung auch Fremdsysteme an eine Exchange Organisation anzubinden. Dabei kann es sich um andere Mailsysteme (z.B.: MS-Mail, Notes oder GroupWise) handeln oder um ganz andere Dienste wie Fax, Voice, Telex etc.

Für die Anbindung eines Connectors an Exchange gibt es schon immer zwei unterschiedliche Ansätze, damit die Nachrichten in Exchange landen und aus Exchange übertragen werden.

  • EDK-Gateway
    Diese Schnittstelle ist an Anfang an für Entwickler der der Weg zur Anbindung ihrer Connectoren an Exchange 4.0 und neuer. Allerdings ist absehbar, dass dieser Zugang mit Exchange 2007 vermutlich entfällt, da schon bei Exchange 2000/2003 diese Anbindung nur noch zweite Wahl ist. Die Nachrichten müssen einfach zu lange Wege gehen.
  • SMTP-Gateway
    Seit Exchange 2000 ist das Protokoll SMTP quasi als Standard gesetzt und entsprechende Definitionen sind nun auch allgemein bekannt, obwohl diese auch schon bei Exchange 5.x genutzt wurden. Denken Sie nur an Mailadressen in der Form "IMCEA*". Doch eins nach dem anderen.

Nicht beantwortet ist hierbei die Zusatzfunktion eines Adressbuchabgleichs, der Übernahme von Konfigurationsdaten aus Exchange für Zwecke des Connectors (z.B.: die Faxnummer aus dem Active Directory als Routinginformation zu nutzen) und die Kopplung von zusätzlichen Informationen bei Mailsystemen wie z.B. "Frei/Belegt-Zeiten( (Siehe auch Koexistenz)

EDK-Gateway

Achtung: Die EDK-Schnittstelle ist mit Exchange 2007 nicht mehr verfügbar.
Siehe dazu auch E2K7:ForeignConnector

Das Exchange Development Kit Gateway ist der klassische Ansatz einen Connector an eine Exchange Umgebung anzuhängen. Microsoft hat dazu sogar ein Beispielgateway im Sourcecode im SDK beigepackt. Sehr viele Gateways nutzen heute noch diese Schnittstelle die natürlich noch deutlich die Suren des früher dominanten Protokolls X.400 beinhaltet. So werden die Nachrichten zu diesen Gateway wie auch in Exchange 5.x über den X.400 MTA übertragen, d.h. der Dienst, der in der Vergangenheit auch die X:400 Nachrichten übermittelt hat.

Technisch erfolgt die Anbindung per MAPI, d.h. in Exchange wir ein besonderes Postfach für das Gateway angelegt, in welchem es aber nicht die Ordner "Posteingang" und "Postausgang" gibt, sondern statt dessen die Ordner "MTS-IN und MTS-OUT". Jede Mail, die das Gateway in den Ordner MTS-IN ablegt, ist aus Sicht von Exchange eben als "eingehend" zu betrachten. Umgekehrt werden Nachrichten an das Gateway in den Ordner MTS-OUT abgelegt. Dieses "Postfach" ist im Exchange System Manager problemlos zu sehen und hat sogar eine Mailadresse. Allerdings ist es natürlich im Adressbuch "verborgen". Das Gateway selbst greift auf das Postfach einfach per MAPI zu. Dabei ist es egal, ob das Gateway nun "auf" dem Exchange Server installiert wird und mitläuft oder auf einem anderen Server installiert ist. Allerdings muss das Gateway auch diesen "Remote Mode" unterstützen. Viele Gateways stören sich leider daran, wenn Exchange nicht auf dem gleichen Server läuft.

Damit Exchange den Weg zu diesem Gateway findet, muss natürlich ein Connector eingerichtet werden, welcher zum einen einen passenden Adressraum (z.B.: FAX) hat und auf das Gateway.Postfach verweist. In der Folge können dann alle Exchange Server diesen Adressraum und leiten alle Nachrichten an diese Gateway weiter.

Es gibt durchaus Gateway, die bei der Installation einfach die entsprechenden Einträge in Exchange vornehmen aber sich im Exchange System Manager nicht hinterlassen, d.h. dort gibt es kein sichtbares Objekt und die Konfiguration erfolgt über eine separate Anwendung. Solange Exchange einfach den Weg in die Gateway-Postfächer kennt, ist das auch ausreichend, wenn gleich manchmal verwirrend.

Der Nachrichtenfluss in einer Exchange 2000/2003 Umgebung kann dann wie folgt aussehen

Nehmen wir für das Beispiel an, dass ein Fax empfangen wird. Die einzelnen Phasen bedeuten dann

Phase Beschreibung

Der Faxserver empfängt ein Fax und meist wird er anhand einer Durchwahl (MSN) den Empfänger zuordnen. Einige Faxserver nutzen dazu eine eigene Benutzerdatenbank, andere fragen direkt das Active Directory oder importieren zumindest die Daten von dort. Der Faxserver oder das Gateway konvertieren das Fax in ein geeignetes Format, hängen diese Datei an eine Mail an und werfen diese in MTS-IN ein.

Nun ist es am MTA diese Nachrichten entweder gleich an einen lokalen Benutzer in der gleichen Datenbank zuzustellen oder an den Exchange Routing Prozess zu übergeben.

Im Beispiel wird die Mail über einen Routinggruppenconector zu einem anderen Server übertragen. Hier ist es übrigens egal, welcher Connector diese Mail weiterleitet. Es muss nicht zwingend ein X.400 Connector sein, wie dies manchmal behauptet wird.

Der SMTP-Service stellt die Mail dann in das Postfach des Anwenders zu.

In der umgekehrten Richtung ist natürlich ein Versand ebenso wünschenswert

Phase Beschreibung

Der Anwender erstellt demnach eine Mail mit einem passenden Adresstyp. Sie können in Outlook solche Adressen einfach mit eckigen Klammern eingeben, also in der Form "[fax:1234567]". Outlook erstellt daraus dann eine Faxadresse. Wenn ihr Connector entsprechende Add-ons in Form von DLLs mitliefert, dann können Sie in Outlook auch die Adresse schön über eine Maske eingeben. Das ist sicherer wenn es um ungewöhnliche Adressen handelt.  "[MS:netzwerk/postoffice/alias]"  können Sie sicher eingeben aber die korrekte Eingabe einer X.400 Adresse ist sicher etwas für ambitionierte Anwender.

Nun kann der SMTP-Dienst natürlich nur SMTP-Adressen durchleiten. Daher werden die Adressen "eingekapselt" und mit dem Prefix "IMCEA" versehen (InternetMail Connnector Extended Adressing). Also wundern Sie sich nicht über solche Adressen.

Über das Routing kennt Exchange nun den Weg zum Fremdsystem über den entsprechenden Adressraum eines Connectors und leitet die Nachrichten dorthin weiter. Der Exchange Server auf dem das Connectorpostfach liegt, leitet die Mails an den MTA weiter.

Der MTA legt die Nachrichten dann direkt in das Postfach des Gateways ab. Im Prinzip entspricht dies einem "Wildcard"-Postfach, da alle Nachrichten an [FAX:*] in diesem Sammelpostfach landen.

Nun ist es am Gateway regelmäßig dieses Postfach auf neue Nachrichten zu prüfen und diese dort abzuholen. Es ist gut erkennbar, dass Exchange die Nachrichten nicht aktiv an das Gateway zustellt, sondern nur zur Abholung bereit legt. Allerdings gibt es natürlich in MAPI die Möglichkeit einer Benachrichtigung, d.h. ein Gateway muss nicht alle 5 Minuten das Postfach "pollen".

Ein gutes Gateway wird die Nachricht nun gemäß seiner Leistungsfähigkeit konvertieren und versenden. Wenn der Absender eine Quittung angefordert hat, dann sollte das Gateway natürlich eine konforme Quittung erstellen und an den Absender über den bekannten Weg zurück senden.

In der gleichen Art sind  natürlich auch Gateway zu GroupWise, Lotus Notes und vielen anderen Fremdsystemen angebunden. Bedenken Sie aber, dass diese Beschreibung nur den Transport von Nachrichten erläutert. Die meist erforderliche Konvertierungen von Nachrichten und die Auswahl der korrekten Empfänger und weitere Funktionen sind nicht Bestandteil des Transports.

Da Sie nun wissen, wie das EDK-Gateway funktioniert, haben Sie natürlich auch alle Optionen zur Fehlersuche. Sie können die verschiedenen Prozess (Gateway, MTA, SMTP) einfach stoppen und in die jeweilige Warteschlange schauen. Sogar in das Gateway-Postfach können Sie mit MFCMAPI oder MDBVU32 schauen. Sie müssen dazu aber auf dem Server mit dem Connector das dort angelegte MAPI-Profil mit REGEDIT kopieren und bei sich importieren.

SMTP als Gateway

Was machen wir aber, wenn es mit Exchange 2007 vielleicht kein EDK-Gateway mehr gibt? und was machen Hersteller, die einfach kein EDK-Gateway mehr schreiben wollen?. In dieser Situation können Sie einfach SMTP nutzen. Hierzu müssen Sie einfach ein paar Dinge bedenken.

  • SMTP bedeutet Senden
    Eine Gateway-Verbindung per SMTP bedeutet, dass der Exchange Server aktiv die Nachrichten versenden möchte und ihr Gateway daher Nachrichten per SMTP annehmen muss. Es muss daher einen eigenen SMTP-Server betreiben.
  • SMTP eingehend
    Wenn das Gateway Nachrichten an Exchange übermitteln will, muss es nun auch per SMTP diese Nachrichten an Exchange zustellen.
  • SMTP Codierung
    Damit sind natürlich einige zusätzliche Funktionen erforderlich, damit Nachrichten auch "Hübsch" ankommen. Es hat sich eingebürgert, dass eingehende Faxe auch als Nachricht der Klasse "IPM.Fax" beim Anwender ankommen. Entsprechend muss das Gateway seine Nachricht codieren. Dazu gehört auch eine Umsetzung der Anlagen mittels UUENCODE oder besser BASE64/MIME. Das Gateway muss also einiges zusätzlich können.
  • SMTP-Adressierung
    Das Gateway muss weiterhin die erweiterte SMTP-Adresse von Nachrichten an das Gateway "verstehen" und umsetzen und Senden an Exchange mit einer brauchbaren "From-Adresse" versehen. Auch hier spielt IMCEA eine große Rolle.

Schauen wir und so ein Gateway ebenfalls im Schaubild an. Es ist natürlich um einiges einfacher.

Phase Beschreibung

Auch hier empfängt das Gateway ein Fax ordnet einen Empfänger anhand einer eigenen Datenbank oder eines Felds im AD zu. 

Der Faxserver konvertieren das Fax und sendet diese als SMTP-Mail einfach an den Exchange Server. für Exchange ist dies eine ganz normale externe Mail Sie sollte aber vielleicht die IP-Adresse des Faxserver als "vertrauenswürdig" einstufen oder, sofern der Faxserver dies unterstützt, eine SMTP-Authentifizierung einrichten. Damit werden diese Nachrichten dann auch nicht mehr durch den Intelligent Message Filter überprüft und eventuell geblockt.

Das Exchange Routing stellt diese Nachricht nun entweder direkt lokal zu oder über einen Connector an eine andere Routinggruppe.

Im Beispiel wird die Mail über einen Routinggruppenconector zu einem anderen Server übertragen. Auch hier ist es egal, welcher Connector diese Mail weiterleitet. Es muss nicht zwingend ein X.400 Connector sein.

Der SMTP-Service stellt die Mail dann in das Postfach des Anwenders zu.

In der umgekehrten Richtung ergibt sich folgendes Routing:

Phase Beschreibung

Der Anwender erstellt eine Mail mit einem passenden Adresstyp, z.B.: [FAX:1234567]. Der Exchange Routingdienst erkennt diese nicht gerade SMTP-konforme Adresse und ersetzt diese durch die Extended Adressing in der Form.

IMCEA<ExtendedAddresstype>-<RecipientAddress>

Aus einem [FAX:12345667] wird demnach ein IMCEAFAX-1234567@meinedomain.de

Diese Adresse wird von Exchange dann zum Connector mit dem Adressraum "FAX" weitergeleitet, der auch problemlos bei einem SMTP-Connector eingetragen werden kann.

Natürlich muss im Beispiel die Nachricht erst mal über den Routinggruppenconnector zum eigentlichen Server.

Dort sendet der virtuelle SMTP-Server dann die Nachricht an den im SMTP-Connector mit dem Adressraum "FAX" hinterlegten Smarthost. In ihrer Konfiguration haben Sie daher meist zwei SMTP-Connectoren: Einen für das Internet und einen für den Faxserver. Nun liegt es am Faxserver diese Nachricht anzunehmen.

Der SMTP-Server auf dem Faxserver muss nun die Nachricht in die interne Warteschlange ablegen, konvertieren und die richtige Zieladresse aus der SMTP-Adresse IMCEAFAX-1234567@domain.de extrahieren und das Fax versenden.

Rückantworten des Faxservers an den Anwender sollten natürlich ebenso  "nett" formatiert sein, wie dies bei eingehenden Faxen möglich ist. Das Gateway kann aber jede beliebige "Absenderadresse" vorgaukeln, d.h. es kann auch eine Nachricht  mit einer Absenderadresse der Form IMCEAFAX-01234567@domain.de versenden. Dann kann der Anwender sogar direkt darauf antworten

Zusammenfassung

Sie sehen dass auch eine SMTP-Anbindung eine sehr leistungsfähige Anwendung sein kann, die problemlos mit Outlook und Exchange harmoniert. Beide Anbindung haben ihre Vorteile wobei die Anbindung per SMTP natürlich einfacher und geradliniger ist. Dies gilt insbesondere wenn das Gateway nicht unter Windows läuft und damit ein Zugriff per MAPI auf ein Connectorpostfach ausscheidet oder eine Zweiteilung der Funktion erforderlich würde. Zudem ist die Anbindung per SMTP-Connector natürlich eine sehr einfach Möglichkeit, eigene Funktionen an Exchange anzubinden. Wenn Sie daher eine geniale Idee haben, z.B.: dass Exchange ein "Mail 2 Print"-Gateway unterstützen sollte, dann ist auch das möglicht. Sie benötigen nur einen SMTP-Server, an den Exchange die Nachrichten sendet und ein eigenes Programm um die Funktion umzusetzen. Die Bastelstunde ist eröffnet.

Auf der anderen Seite hat natürlich auch der Weg über das EDK seinen Charme, da damit über MAPI direkt und einfach Zugriff auf die GAL möglich sind und Nachrichten direkt ohne besondere Umsetzungen versendet werden können. Es ist eben "fast wie Outlook".

Letztlich ist es aber eh nicht ihre Entscheidung, sondern der Hersteller gibt natürlich mit seinem Gateway die Anbindung vor.

Links