Exchange und X.400
X.400 und Exchange 2007
Der X.400 Connector ist mit Exchange 2007 NICHT MEHR VERFÜGBAR
Wenn Sie also auch hier weiterhin X.400 benötigen, dann müssen Sie wohl oder
Übel einen Exchange 2003 Server weiter betreiben.
Was ist X.400 (und was X.500) und was die Telebox 400 ?
In den frühen Jahren der Vernetzung von Computern war das Rennen noch lange nicht entschieden. Auf der einen Seite entwickelten Personen wie John Postel das Internet, TCP/IP und auch SMTP für die Mailübertragung. Ihr Ziel war auch ein "einfaches" Protokoll, welches leicht zu adaptieren war aber in der ersten Version einige Aspekte ausgelassen hat
- Auf der anderen Seite wurde X.400 als Protokoll (1984/1988) entwickelt, welches viel mehr konnte also SMTP (z.B.: 8bit Übertragungen. Wiederaufsetzen von Verbindungen, gesicherte Übertragungen etc.) aber entsprechend aufwändiger und teurer in der Umsetzung war. X.400 wird heute fast nur noch in Verbindung mit TCP/IP als Transport weg verwendet, konnte früher aber auch Paketvermittelte Datex-P Verbindungen nutzen.
X.400 ist also genau wie SMTP ein Protokoll zur Übertragung von Nachrichten zwischen zwei Mailsystemen (MTA genannt). Es sagt nichts über die Verbindung von Client zum Server (UA = User Agent) aus. Hier waren meist proprietäre Protokolle im Einsatz. Mir ist zumindest kein Gegenstück zu POP3 oder IMAP4 bekannt.
X.400 verwendet auch eine andere Adressierung als SMTP.
SMTP: User@host
X400: c=country,a=AdminDomain,p=PrivateDomain, etc
Während SMTP per DNS und MX-Einträge den Zielserver für die Mail sucht und das Internet damit "flach" war, konnte man mit X.400 hierarchische Bäume zusammenstellen um Leitwege zu Vereinfachen. So konnte ein MTA einfach den "nächsten Hop" zum Ziel erkennen. So könnte eine Adresse wie folgt gültig sein:
X400: c=DE,a=DBP,p=MSXFAQ, o=Paderborn, s=Carius, g=Frank
Damals gab es ja auch noch kein Internet, bei dem jeder Server jeden anderen Server erreichen konnte. Damals musste man Als Administrator noch "peerings" einrichten, d.h. AT&T hatte damals als "c=us,a=ATT" ein peering mit "c=de,a=DBP. Und ein eine Firma wie Net at Work hatte dann eben ein Peering mit der der Deutschen Bundespost (DBP). Und so fand die Mail dann ihren Weg. Und nicht immer gab es funktionierende Leitwege, denn warum sollte jemand von ATT aus den USA über die Telekom eine Mail in die Schweiz senden können ?. Es war nicht selbstverständlich dass ein Provider als Relaystation für fremde Sender und Empfänger diente. Also musste dann jeder Provider mit jedem anderen eine Peering vereinbaren, was mit der Schaltung einer Leitung verbunden war. In den Anfangszeiten des Internet war das aber auch ausgeprägt, dass Provider als "Subprovider" eines anderen aufgetreten sind.
Wenn der Begriff X.400 fällt, dann hören viele auch gleich EDIFACT und Telebox.400. Die Telebox.400 war damals nichts anderes als ein Postfach bei der Telekom, aus dem Sie ihre Mails abrufen konnten. Heute bieten ihnen die Internetprovider POP3/IMAP4-Postfächer auf deren Servern an, in denen ihre Nachrichten zwischengespeichert werden.
Die Telebox.400 war also nie eine Option, um einen Exchange Server über einen X.400 Connector an die weite Welt anzubinden, sondern immer eine Einzelbenutzerlösung.
MTA Stacks und X.400 Connector
Den recht seltenen Fall, dass Sie eine Exchange Organisation per X.400 an einen externen Dienstleister anschließen, möchte ich hier nicht beschreiben. Aber X.400 ist mit Exchange 4.x bis 5.5 eine perfekte Wahl, um Exchange Standorte und Server miteinander zu verbinden. Der X.400-Connector ist sehr viel Bandbreitenschonender, Firewallfreundlicher (nur ein Port 102/TCP) und problemloser als ein "Siteconnector", der per RPC arbeitet oder ein SMTP-Connector mit verbundenen Standorten, der jede Mail per MIME-Codierung aufbläßt.
Damit eine Verbindung jedoch zustande kommt, müssen auf beiden Seiten entsprechende Konfigurationseinstellungen gemacht werden.
- X.400 MTA Stacks
Diese Konfigurationseinstellung teilt dem Exchange Server mit, über welche Wege (X.25, TCPIP, Seriell) er Verbindungen annehmen soll. Hier wird auch der "lokale MTA-Name" und eventuell ein Postfach hinterlegt.
Dieser Stack dient aber auch als Endpunkt für eingehende Verbindungen von anderen Exchange Servern - X.400 Connector
Der Connector enthält die Konfigurationsdaten für die Verbindung zur Gegenstelle. Er nutzt dabei aber einen der lokal zu konfigurierenden Stacks, damit er weiß, wie und mit welchen Parametern er die Verbindung aufbaut. Die Zieladresse ist aber im Connector hinterlegt
Damit das alles nun funktioniert, müssen die Parameter natürlich ganz genau übereinstimmen. Es reicht nicht auf der einen Seiten einen MTA-Stack zu konfigurieren und auf der andren Seite einen Connector. Der annehmende Mailserver "erkennt" anhand der bei ihm konfigurierten Connectoren die Gegenstelle, die gerade zu ihm eine Verbindung aufbaut. Daher muss es immer auf beiden Seiten einen Connector geben. Knifflig wird es, wenn man Namen und IP-Adressen "mischt", denn der eingehende Server bekommt erst mal nur die IP-Adresse und versucht mit dieser Adresse bzw. dem dazu gehörenden Namen (Achtung Reverse-DNS !!!) den lokalen Connector zu finden.
Ganz einfach machen Sie es sich natürlich wenn Sie einfach IP-Adressen statt Namen hinterlegen, weil damit dann die Auflösung entfällt. Trotzdem sind natürlich auch noch Dinge wie die MTA Namen zu pflegen. Und hier ist äußerste Sorgfalt geboten, da X.400 zwischen Groß und Kleinschreibung unterscheidet.
Einrichtung
Zuerst müssen Sie auf beiden Servern einen MTA-Stack für das gewünschte Protokoll (meist TCP) einrichten. Das ist mit wenigen Mausklicks erledigt.
Die OSI-Informationen können sie leer lassen. Wichtig ist der Servername.
Der zweite Schritt ist dann die Konfiguration eines Connectors in der Routinggruppe:
Hier kommen dann aber ein paar Einstellungen mehr zum tragen
Hier ist der vorher angelegte Transportstack auszuwählen aber insbesondere der Name (nicht IP-Adresse!) des MTAs auf der Gegenseite manuell einzutragen. Erst auf der Karteikarte "Stapel" gibt man den auf die IP-Adresse auflösbaren Rechnernamen oder die IP-Adresse ein. Exchange erkennt nicht alleine, ob es sich um eine IP-Adresse handelt. Sie müssen also schon selbst die Einstellung richtig machen. Hier ist gut zu sehen, dass es sehr wohl einen unterschied zwischen MTA-Name und Servername geben kann.
Eingehende Verbindungen werden anhand der IP-Adresse der Gegenstelle auf einen konfigurierten Connector umgesetzt. Wenn Sie es gut meinen und hier z.B. den DNS-Namen des anderen Servers eintragen, dann müssen Sie sicherstellen, dass auch die DNS-Reverseauflösung auf dem Zielserver für diese IP-Adresse genau diesen Namen zurück liefert. Notfalls hilft hier eine Kontrolle mit NSLOOKUP. Funktioniert dies nicht, dann lehnt der Zielserver die Verbindung ab.
Erst dann ist an der Zeit unter "Verbundene Standorte" den Tunnel zur anderen Exchange Routinggruppe bzw. Exchange 5.5 Site anzulegen.
Sie sehen rot markiert das Leerzeichen im Feld "a". Eine Schöne Konfiguration sieht natürlich so aus, dass man hier die Einträge vornimmt, die auf der Gegenseite in der Exchange 5.5 Standortadressierung hinterlegt sind. Erforderlich ist dies aber nicht.
Fehlersuche
Der erste Ansatzpunkt, wenn zwei Server nicht über einen X.400 Connector kommunizieren wollen ist TCP/IP. X.400 lauscht auf Port 102/TCP, so dass Sie von einem Exchange Server ganz einfach einen "TELNET xx.xx.xx.xx 102" starten können. Im Normalfall nimmt der Server die Verbindung an, aber unterbricht diese wieder sehr schnell, wenn Sie nicht X.400 sprechen. Wenn Sie hingegen eine Sanduhr sehe, dann blockiert eine Firewall den Port, das IP-Routing klappt nicht o.ä. Wenn sie im Connector den Namen verwenden, dann prüfen sie auch die Namensauflösung, indem Sie den Telnet auf den Namen versuchen. Wenn Sie hingegen IP-Adressen zur Verbindung nutzen, dann kontrollieren Sie, dass Sie im Connector auch "IP-Adresse" in der Auswahlbox angewählt haben. Der Telnet sollte in beide Richtungen identisch funktionieren.
Dass die Namen alle "Case sensibel" sind, habe ich schon gesagt. Kontrollieren Sie trotzdem noch einmal die Eintragungen auf diese Besonderheit. Sie sollten die "Overwrite"-Karteikarte nur nutzen, wen Sie genau wissen, was Sie hier abweichend einstellen müssen. Normalweise sind hier keine Eintragungen notwendig.
Wenn eine Verbindung per TCP möglich scheint, dann ist der zweite Blick das Eventlog. Hier finden sich die verschiedenen Einträge zum X.400 Dienst. Beim Einsatz von IP-Adressen machen ihnen eventuell Router und NAT-Umsetzungen einen Strich durch die Rechnung. Wichtig ist, dass beim Empfänger eine IP-Adresse ankommt, für die er auch einen Connector finden kann.
- EventID 9301
Dieser Eintrag verrät, dass der Exchange Server keinen passenden Connector zur eingehenden Verbindung finden konnte. Sie sollten einen "10061 socket error" finden, der mehr zur IP-Adresse sagt.
Manchmal ist es auch einfacher mit dem NetMon3 einfach alle eigehenden Verbindungen auf Port 102 (Capture Filter auf "tcp.Port == 102" setzen) mitzuschneiden um die echte IP-Adresse der anderen Seite in Erfahrung zu bringen.
Ein letzter kniffliger Punkt ist die Karteikarte "Verbundene Standorte". Diese muss ja gepflegt werden, um Exchange Standorte durch einen X.400 Connector durch zu "tunneln". Welche Werte da drin stehen ist eigentlich gar nicht so wichtig, solange sie "passen". Auch hier gilt wieder: Groß/Kleinschrift ist wichtig. Auch sollten Sie dran denken, dass ein "leeres" a-Feld nicht erlaubt ist. Geben Sie hier einfach ein Leerzeichen ein, wenn das Feld ansonsten frei bleiben soll
Links
- 285934 Exchange 2000 Server Top Message Transfer Agent Support Issues
- 263248 XCON: X.400 Message Flow in Exchange 2000
- 264426 XCON: List of KB Articles on X.400 Connector Concepts and Troubleshooting
Hier die weiterführenden KB-Artikel.
- 140014 TechNet-article claims, that the remote host is not listening on the X.400 over tcp/ip-port (port 102)
- 152934 XCON: X.400 Connector Stack Property Page Behavior
- 154301 XCON: MTA X.400 Connector Problems on Slow Links
- 154385 XCON: MTA Generates Error Message Because of Corrupted or Missing .tpl File
- 161931 XCON: Configuring MTA TCP/IP Port # für X.400 and RPC Listens
- 165030 XCON: Sample Configuration between Microsoft Exchange and MailBus 400
- 165111 XCON: Configuring X.400 Connector between Two Exchange Servers
- 165279 XCON: X.400 First Contact Form für X.400 Connector Problem
- 166308 XCON: Exchange MTA Logs NT Event ID 51
- 166602 XCON: MTA Only Allows 64 TCP/IP or TP4 Connections
- 169113 XCON: using an X.400 Connector with TCP/IP in a Cluster Environment
- 169159 XCON: X.400 Connector Configuration Checklist
- 175496 XCON: using RPCPING to Troubleshoot MTA Connections
- 186344 XCON: Exchange Routes Messages Over X.400 Connector When It Should NDR Them Locally
- 190022 XCON: Comparison of X.400 and Site Connectors
- 191947 XCON: MTA Fails to Convert Message with TNEF in P2 from 1984 X.400 System
- 193322 XCON: Route Selection Criteria
- 193380 XCON: Mail Does Not Flow over X.400 Connector; Event 9301
- 197378 XCON: MTA Generates 9301 Events on Incoming Connections
- 199326 XCON: Configuring X.400 Connectors to Communicate Through a Firewall
- 200259 XCON: Event ID 9156 from the Exchange Server 5.5 Message Transfer Agent
- 215472 XFOR: How the X.400 Connector Handles High-Priority Mail
- 230508 XCON: How to Configure X.400 to Send System Messages Only
- 234157 XCON: Explanation of the Fields on the Override Tab of the X.400 Connector
- 243632 XCON: Maximum Number of X.400 Connectors That Can Be Installed on One Exchange Server Computer
- 244519 XADM: How to Restore Multiple X.400 Addresses
- 255991 XCON: How to Configure an X.400 Connector with RRAS over TCP/IP
- 263248 XCON: X.400 Message Flow in Exchange 2000
- 271449 XADM: Message Transfer Agent Stacks Service Incorrectly Logs an Error When It Runs in a Cluster Environment
- 271723 XCON: Cannot Create a New MTA Stack für Exchange 2000 with the Exchange 5.5 Administrator Program
- 273646 XCON: Message Transfer Agent Repeatedly Fails to Start with Event 155 or Event 164
- 274770 XCON: MTA with Special Characters Does Not Communicate with Exchange Server 5.5 MTA
- Q328484 XCON: A Remotely Initiated X.400 Connection Does Not Permit Messages That Are Queued on the Mailbox Server to Be Delivered
- 816466 Message sent through a fax connector generates an NDR after you move the routing group in Exchange 2000 and in Exchange 2003
- X.400 Concepts and Terminology Introduction to the CCITT X.400 Standard
http://www.Microsoft.com/TechNet/prodtechnol/exchange/plan/appb.asp - Implementing the X.400 Connector - Is It Worth using with Exchange Server
2003?
http://www.MSExchange.org/tutorials/X400-Connector-Exchange-Server-2003.html