Table of Contents Zu Beginn dieser Entwicklung wurden Daten zwischen unterschiedlichen Rechnern noch manuell transportiert, indem sie ausgedruckt und wieder eingetippt oder mit Hilfe von Datenträgern wie z. B. Disketten oder Magnetbändern zwischen den Rechnern bewegt wurden.
Man erkennt schnell, daß dies ein mühsames Unterfangen ist, und entsprechend schnell wurden auch andere Möglichkeiten gefunden, Daten ohne großem Aufwand zu transportieren. Übertragungen über serielle Leitungen zwischen zwei Maschinen bildeten den Anfang, schnell wurden dann abteilungsweite Datennetze eingerichtet, um Daten auszutauschen und auch gemeinsame Ressourcen wie Drucker oder Plattenspeicher gemeinsam zu nutzen. Aus der heutigen Sicht mittlerer und großer Unternehmen ist dies längst nichts Neues mehr, sind doch nicht nur die einzelnen Abteilungen untereinander, sondern sogar die einzelnen Niederlassungen selbst miteinander über LANs und/oder WANs vernetzt.
Die Firmennetze, die ursprünglich zum Austausch von Firmen- und Produktionsdaten aufgebaut wurden, bieten ganz nebenbei auch eine hervorragende Infrastruktur für den Austausch von Informationen, die bis dahin noch per Rundschreiben bzw. Hauspost hin- und hergeschickt wurden. Solche elektronischen Notizen und Briefe gehören nach wie vor zu den Hauptanwendungen von Netzwerken.
Dies zeigt sich auch umgekehrt in den vielen privaten und wissenschaftlichen Mailbox-Systemen und -Netzen, die eigens aus dem Bedarf der Kommunikation entstanden sind und die heute den gesamten Erdball umspannen und weltweit mehr als 50 Millionen Benutzer verbinden. Mit dem Aufbau der Datenautobahnen in den USA und in Europa dürfte sich diese Zahl sicher bald vervielfachen ([4], S. 55).
Oft wird von Firmen Anschluß an diese weltweiten Netze gesucht, bieten sie doch eine große Menge an fachspezifischen Informationen und kompetenten Kontakten an, die sonst nur schwer zu finden sind. In dieser Hinsicht mögen die Interessen von Heimanwendern und Firmen am Informationsaustausch noch am ehesten übereinstimmen, es gibt jedoch auch Punkte, wo sich diese beiden Anwendergruppen ganz klar unterscheiden. Dies sind:
Zu 2.: Während man als Privatmann selten mehr als einen Rechner betreibt, sieht dies in Firmen ganz anders aus. Es muß eine klare Infrastruktur vorhanden sein, mit deren Hilfe Informationen zwischen Rechnern transportiert werden können. Ist der Anschluß erst realisiert, will auch jeder Benutzer individuell adressiert werden, es reicht nicht, wenn pro Firma nur eine EMail-Adresse besteht. Vielmehr muß ein Mechanismus bereitstehen, der die Nachrichten firmenintern weiterverteilt.
Zu 3.: Oft sind nicht nur viele gleiche Rechner und Betriebssysteme im Einsatz, sondern verschiedene, kunterbunt gemischt. In einer solchen heterogenen Umgebung besteht automatisch Nachfrage nach Gateways, die das Format von Nachrichten einer Plattform in das einer anderen umwandeln. Dies stellt zum einen einen Investitionsschutz dar, da bereits vorhandene Plattformen in das Kommunikationsnetz eingebunden werden können, zum anderen müssen damit evtl. keine neuen Techniken und Programme eingeführt werden, was eine höhere Akzeptanz seitens der Anwender in den einzelnen Abteilungen mit sich bringt.
Im Gegensatz zur Korrespondenz via Briefpost benötigt EMail einen wesentlich geringeren Overhead: Bereits heute sitzt man am Schreibtisch und tippt seine Briefe in den Computer ein. Wieso diesen also ausdrucken, einen Briefumschlag bedrucken und das Ganze zur Post bringen, wenn alles dies auch gleich vom Schreibtisch aus mit einem einzigen Tastendrucken erledigt werden kann. EMail leistet in dieser Hinsicht durchaus einen Beitrag zur Büroautomation und ist ein wichtiger Schritt zum papierlosen Büro.
Ein weiterer wesentlicher Punkt gerade bei Briefen ins Ausland ist die Zeit, die vergeht, bis der Empfänger den Brief in Händen hält. Bei EMail kann diese - abhängig vom vorhandenen Anschluß - im Sekundenbereich liegen. Man kann so in sehr kurzer Zeit Anfragen an Filialen, Lieferanten, Großhersteller oder Informationsanbieter tätigen oder Anfragen von Kunden nachkommen, was bisher nur via Telefon oder Telefax möglich ist. Gerade im internationalen Support-Bereich ist dies nicht unerheblich.
Durch den schnellen Transport von Anfragen und Antworten schrumpfen auch räumliche Zwischenräume, da die Antwortzeiten für einen Brief ins Ausland dank der geringen Laufzeiten nicht länger sind als für einen Brief ins nächste Dorf.
In Zukunft sind als Client-Plattformen, auf denen die Benutzer ihre gesamte EMail-Korrespondenz abwickeln, auch mittels TCP/IP vernetzte Workstations unter Unix (z. B. Solaris, NetBSD, Linux, ...) zu erwarten.
Host-basierende Mailsysteme, bei denen sich die Benutzer über Netz auf einem zentralen Mail-Server einloggen, sind zwar heute noch im Gebrauch, verlieren aber zunehmend an Bedeutung.
Im Gegensatz zu reinen MTAs (Mail Transport Agents, Systeme, die rein für den Nachrichtentransport zuständig sind) stehen Host-basierende Mail-Systeme, bei denen Mail-Client und MTA auf einem zentralen Mail-Rechner laufen, und in die sich die EMail-Benutzer einloggen müssen, um die gebotenen Dienste in Anspruch zu nehmen. Durch diesen interaktiven Zugang gelten hier etwas stärkere Anforderungen:
Generell sind beim Austausch von Nachrichten zwei Punkte zu definieren:
Zur Zeit existieren zwei allgemein akzeptierte, offene Standards. Dies ist zum einen der OSI-Standard "X.400", zum anderen das insbesondere im Bereich des Internet etablierte Simple Mail Transport Protocol (SMTP). Auf beide soll im folgenden kurz eingegangen werden.
Bei X.400 handelt es sich jedoch nicht um ein einziges Protokoll, sondern um einen ganzen Satz. Diese einzelnen Protokolle regeln das Zusammenspiel der einzelnen Mail-Programme (MUAs, Mail User Agents), den Sende- und Empfangseinrichtungen (SDSEs, Submission and Delivery Service Elements) sowie den eigentlichen Transporteinrichtungen (MTAs, Mail Transport Agents).
X.400 ist bisher das einzige OSI-Protokoll, das halbwegs Akzeptanz erreicht hat, obwohl es immer noch eine relativ geringe Marktbedeutung hat. Dies mag sich jedoch in Zukunft ändern: bereits heute bietet jeder namhafte Hersteller von Mail-Software Gateways nach und von X.400 an. In wieweit dies jedoch ohne die restlichen OSI-Dienste - hauptsächlich dem Directory-Dienst X.500 - sinnvoll nutzbar ist, bleibt dabei wiederum offen.
Da die Anbindung an X.400 nicht Teil der Diplomarbeit ist, soll hier auch nicht näher auf die Architektur eingegangen werden. Als Referenz sei [2], Seite 653ff genannt.
Wie eingangs erwähnt, sind auch hier die folgenden Gebiete bei der Standardisierung zu unterscheiden:
Da sich die Funktionen des ISO-Protokolls X.400 durchaus mit den einzelnen Internet-Protokollen decken, soll hier eine kurze Aufstellung helfen, die verschiedenen Protokolle gegenüberzustellen ([2], S. 657):
--------------------------------------------------------------------- Funktion Internet-Protokoll X.400-Sub-Protokoll --------------------------------------------------------------------- Mail an Post-Office (X.400) SMTP P3 / P1 bzw. entferntes System Mail von Post-Office holen POP P7 und lesen Aufbau der versendeten RFC 822, MIME P2 Nachrichten ---------------------------------------------------------------------
Solche herstellereigenen Lösungen sind fast ausschließlich auf PC`s zu finden. Diese Software-Pakete setzen meist auch ein homogenes PC-Netzwerk voraus und lassen sich daher nur mit größerem Aufwand oder gar nicht in ein heterogenes Netz aus Unix-Workstations, PC`s und Großrechner einbinden.
Außerdem führen diese firmenspezifischen Lösungen dazu, daß jeder Hersteller seinen eigenen "Standard" definiert. Auch dieser Umstand erschwert meist den kooperativen Einsatz unterschiedlicher Mail-Server und Client-Software verschiedener Hersteller.
Die einzige Möglichkeit, um einen parallelen Betrieb zu gewährleisten, sind also Gateways, die eine Umsetzung der jeweiligen Formate vornehmen. Von manchen Herstellern werden solche Gateways als Zusatzpakete für ihre Mail-Software angeboten, allerdings sind diese meist sehr teuer.
Dieses Design ermöglicht außerdem die Nutzung der Standard-Utilities von NetWare, z. B. RCONSOLE zur Konfiguration und Administration. Zudem bietet NGM vollständige Integration mit der NetWare-Bindery und NDS(5), d. h. es können dieselben Benutzernamen und Paßwörter für Message-Services verwendet werden wie für Datei-, Druck- und weitere NetWareDienste.
Zum Nachrichtenaustausch arbeitet die NGM-Software mit Anwendungen dritter Hersteller zusammen. Das können zum einen gewöhnliche EMail-Anwendungen sein, aber auch eine Vielzahl weiterer Anwendungen wie Zeitplanungsprogramme, verteilte Datenbanken, elektronische schwarze Bretter oder EDI(6). Diese Anwendungen stellen dem Anwender FrontendDienste zur Verfügung, z. B. Adreßlisten, und NGM übernimmt im Hintergrund das Routing.
Einzige Voraussetzung für diese Anwendungen ist, daß sie das von NGM verwendete Nachrichtenformat SMF(7) verstehen. NGM stellt zwei SMF-Schnittstellen zur Verfügung, SMF v70 und SMF v71. Das SMF v70 Interface ist das gleiche, das schon von Novell`s MHS(8) 1.5 unterstützt wurde. Daher können alle Applikationen und Gateways, die für MHS 1.5 erhältlich sind und SMF v70 entsprechen, unverändert auch mit NetWare Global Messaging zusammen verwendet werden.
NGM ist der Nachfolger von Novell`s MHS und ist so konzipiert, daß es problemlos mit MHS zusammenarbeitet. Es erweitert zudem die Kapazität und Connectivity von MHS-Systemen. Ein NetWare-Server mit NGM erscheint MHS V1.5 Hosts als normaler MHS-Server.
Die von NGM unterstützte, auf SMF-basierende Adressierung kann sowohl einfache als auch komplizierte Anforderungen abdecken und ist daher für kleinere Firmen geeignet, ebenso wie für große Konzerne. Es erlaubt Benutzernamen bis zu 253 Zeichen, d. h. es können volle Benutzer- und Firmennamen verwendet werden (SMF v71). Aus Kompatibilitätsgründen mit Systemen, die Längenrestriktionen haben, z. B. MHS 1.5, werden zusätzlich auch verkürzte Namen (maximal 8 Zeichen) unterstützt (SMF v70).
Die Adressierung ist dabei nicht an die physikalische Lage einer Mailbox gebunden, sondern baut auf einer hierarchischen Struktur von sog. Workgroups auf. Diese ist frei definierbar und kann somit einfach an die Organisationsstruktur einer Firma angepaßt werden. Jeder Anwender erhält dabei auch einen NGM Benutzernamen, der sich auch vom NetWare Benutzernamen unterscheiden kann. Mit dem NGM Benutzernamen wird festgelegt, wo in der Workgroup-Hierarchie man sich befindet.
NetWare Global Messaging unterstützt von haus aus mehrere Übertragungsprotokolle. Mit NGM werden zwei Protokoll-Module standardmäßig mitgeliefert. Das ist zum einen NIMP(9), das in der Regel für die meisten Aufgaben eingesetzt wird, z. B. für die Verbindung zu anderen NGM-Servern. Zum anderen wird noch das NAMP(10)-Modul mitgeliefert, für asynchrone und Dial-Up Verbindungen, vor allem zu den öffentlichen Nachrichtenträgern wie Novell`s NHUB, CompuServe oder PBHUB von Pacific Bell. Optional sind noch Protokoll-Module für SNA-, SMTP- und X.400-Netzwerke erhältlich.
Näheres zur Spezifikation und weitere Informationen zu SMF kann man von der Software Developpers Kit-CD für NetWare zum Preis von ca. DM 200,- erhalten. Diese Informationen werden evtl. später auch einmal über den NetWare-Server edi.rz.uniregensburg.de zugänglich sein. Dabei sind Zugriffsbeschänkungen für bestimmte Benutzergruppen nicht ausgeschlossen.
Um nun eine Meldung mit NGM zu senden oder zu empfangen, ist es nicht nötig, daß eine bestimmte Arbeitsstation, Verbindung oder ein bestimmtes Gerät im NetWare Global Messaging Netzwerk gerade zu dem Zeitpunkt aktiv ist, an dem die Übertragung einer Nachricht erfolgen soll. Die Nachricht wird nämlich in einem bestimmten Verzeichnis abgelegt. NGM nimmt die Nachricht, ermittelt den Server, auf dem die Mailbox des Empfängers liegt, und schickt sie dorthin ab. Dabei können mehrere Server dazwischen sein. Somit kann ein bestimmter Bereich inaktiv sein, und die Meldung kommt trotzdem beim Empfänger an.
Das System der verteilten Verzeichnisse von NGM:
Die gesamte Konfiguration und Wartung von NGM geschieht mit einem einzigen Administrations-Utility. Auch zusätzlich installierte Protokoll-Module können darüber konfiguriert und verwaltet werden, da die nötigen Optionen dann im Menü erscheinen. Mit diesem Werkzeug erhält man auch Informationen über:
Die Lösung mit MS-Mail geht von einem fast ausschließlichen Einsatz von PC`s aus. Daher steht auch das Frontend zu MS-Mail nur für Windows, das auf dem Markt der PC`s sehr weit verbreitet ist, zur Verfügung. Ein Post-Office auf einem Server kann sowohl vom MSMailFrontend von Windows for Workgroups bzw. Windows NT aus angesprochen werden, als auch von Windows über Novell NetWare kann das PostOffice erreicht werden.
Da das Frontend ausschließlich eine Windows-Applikation ist, ist es dementsprechend gut in die ganze Umgebung eingebunden und nutzt auch gewisse Fähigkeiten von Windows:
In der Praxis ist es meist nicht ausreichend und auch organisatorisch ungeeignet, den gesamten Nachrichtenfluß über ein einziges Post-Office laufen zu lassen. Daher ist es notwendig, einen Gateway zwischen zwei Post-Offices oder zu anderen Mailsystemen wie SMTP oder X.400 aufzusetzen. Das ist im Falle von MS-Mail ein dedizierter PC unter MS-DOS, wobei dieser Gateway nur für je zwei Post-Offices zur Verfügung steht, d. h. um mehrere Post-Offices über einen Gateway zu verbinden, ist pro Gateway ein eigener PC nötig. Daher ist das Routing sehr unflexibel und bedeutet einen hohen finanziellen Aufwand.
Das Dateiformat, das MS-Mail für Nachrichten verwendet, ist proprietär und daher nicht allgemein mit anderen Mail-Clients einsetzbar. Zudem ist das Mailformat nicht offengelegt, d. h. Daten über den Aufbau sind nicht erhältlich. Aus diesem Grund ist auch die Umsetzung in ein anderes Mailformat, z. B. SMTP, sehr schwierig.
Durch das Konzept des zentralen Post-Office Verzeichnisses bedingt, gestaltet sich der Nachrichtenaustausch als normaler Dateiaustausch. Zur Übertragung wird also nur ein reines Dateitransferprotokoll eingesetzt, was zwar sehr einfach, aber auch unpraktikabel ist. Das ist auch mit ein Grund für das unflexible Gateway-System.
Table of Contents 
Next Chapter