Table of Contents

1. EMail aus der Perspektive von Unternehmen

Kaum ein Unternehmen, und sei es noch so klein, kann heute auf den Einsatz von Computern verzichten, egal, ob für die Buchhaltung, die Konstruktion technischer Zeichnungen oder die Überwachung von Fertigungsanlagen. Daten werden eingegeben und Berechnungen unterworfen, um dem Menschen Arbeit abzunehmen und komplexe Zusammenhänge zu veranschaulichen. Oft werden auch Daten, die von einem Rechner erzeugt werden, in einen anderen Rechner gefüttert, der dann anhand dieser Daten entsprechende Aktionen ausführt. Das Zusammenspiel zwischen CAD(1) und CAM(2) ist nur eines von vielen Beispielen hierfür.

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:

  1. das zu transportierende Datenvolumen
  2. die Anzahl der anzuschließenden Rechner sowie
  3. der Bedarf an Gateways für unterschiedliche Plattformen und Protokolle
Zu 1.: Der Bedarf an Informationen eines mehrere hundert Mitarbeiter zählenden Betriebs und damit auch das zu transportierende Datenvolumen unterscheiden sich von dem, was ein privater Heimanwender produziert bzw. konsumiert, um mehrere Zehnerpotenzen. Entsprechenden sind andere Technologien nötig, diese Masse an Informationen zu transportieren, zu verwalten und zu verteilen.

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.

1.1 Argumente für EMail

Welche Argumente sprechen konkret für den Einsatz von elektronischer gegenüber herkömmlicher Korrespondenz?

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.

1.2 Client-Plattformen

Abhängig von der betrieblichen Infrastruktur sind heute auf den einzelnen Arbeitsplätzen IBM-kompatible PCs im Einsatz, meist unter einem der folgenden Betriebssysteme:

Diese sind mit einer gängigen Software vernetzt, etwa Novell NetWare, TCP/IP, LanManager oder DECnet, wodurch auch die Grundlage für eine LAN-basierende EMail-Anbindung geschaffen ist.

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.

1.3 MTA- und Server-Plattformen

Die heute zum Mail-Transport verwendeten Rechner basieren durchwegs auf Betriebssystemen, die für den Server-Betrieb konzipiert sind. In der Praxis werden v.a. die folgenden Plattformen eingesetzt:

Diese Server-Systeme müssen entsprechend ausgerüstet sein, um den an sie gestellten Anforderungen gerecht zu werden. Im einzelnen sind dies:

Die einzelnen Anforderungen werden natürlich stark durch das äußere Umfeld bestimmt. So muß z. B. die Plattenkapazität auf die Art der versendeten Daten abgestimmt sein: relativ wenig bei reinen Text-Nachrichten bis zu großen Platten bei intensivem Austausch von Multimedia-Daten. Weiterhin hängen Faktoren wie CPU-Leistung und Netzwerk-Performance stark von der Anzahl der zu bedienenden Benutzer ab. Abteilungsweite Mail-Server stellen hier z. B. niedrigere Anforderungen als firmenweite Server.

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:

1.4 Standards

Angesichts der großen Anzahl der verschiedenen Hardware-Plattformen und Betriebssysteme auf Client- und Server-Seite sowie ihrer Vernetzungsmöglichkeiten ist eine Standardisierung auch im Bereich des Austausches von EMail nötig.

Generell sind beim Austausch von Nachrichten zwei Punkte zu definieren:

  1. das Format der Meldung
  2. der Ablauf des Meldungsaustausches
Das Meldungsformat legt z. B. die Form der Adressierung fest, wie Absender und Empfänger gekennzeichnet werden, Verschlüsselung, Dokumenteinbindung, etc. Beim Meldungsaustausch spielen Punkte wie z. B. verzögerte Auslieferung, die Umleitung von Nachrichten an andere Benutzer oder Rechner sowie Abrechnungsfunktionen und Zugriffskontrolle ([4], Seite 158ff) eine Rolle.

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.

1.4.1 X.400

Die EMail-Spezifikation der International Standard Organisation (ISO) ist als MOTIS bekannt, was für "Message Oriented Text Interchange System" steht. Diese Spezifikation ist identisch mit dem Message Handling System (MHS), das im Zuge der allgemeinen Vereinheitlichung bereits vorher von der CCITT beschrieben und als X.400 standardisiert wurde.

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.

1.4.2 SMTP und weitere Internet-Protokolle

Da die Anbindung an Internet-SMTP-Mail Bestandteil der Diplomarbeit ist, soll hier etwas näher auf die Eigenheiten und verwandte bzw. weiterführende Protokolle eingegangen werden.

Wie eingangs erwähnt, sind auch hier die folgenden Gebiete bei der Standardisierung zu unterscheiden:

Folgende Protokolle beschäftigen sich mit dem Format der ausgetauschten Nachrichten:

Im Gegensatz zu X.400 war im Bereich der Internet-Mail lange Zeit nur der Austausch von Textnachrichten definiert, erst in letzter Zeit wurde dies geändert. Ähnliche Veränderungen treffen auch auf das Vorgehen beim Austausch der Nachrichten zu:

Reichte lange Zeit das SMTP-Protokoll zum Nachrichten-Austausch aus, so ist mit dem Einzug von PCs auf dem Schreibtisch ein Verfahren nötig geworden, mit dessen Hilfe die Post von den zentralen Mail-Servern auf den Schreibtisch geholt werden kann. Diese Funktionalität wird durch das Post-Office-Protocol erreicht.

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                                                            
---------------------------------------------------------------------

1.5 Firmenspezifische Lösungen

Im Bereich des Mail-Transports und der Mail-Anwendungen gibt es nicht nur allgemeine Standards wie SMTP und X.400, sondern es existieren auch spezielle Lösungen, die von verschiedenen Herstellern angeboten werden. Hier sind auf PC- und NetWare-Seite vor allem Novell mit NGM(3) und Microsoft mit MS-Mail anzuführen.

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.

1.5.1 NetWare Global Messaging von Novell

NetWare Global Messaging baut auf NetWare auf und bedient sich dessen Leistungsfähigkeit und Protokollunabhängigkeit. NGM setzt sich aus mehreren NLM(4)`s zusammen und ist daher relativ leicht erweiterbar, z. B. um eine Anbindung an X.400- oder SNA-Netzwerke. Da NGM wie andere Netzwerkdienste direkt auf dem Server läuft, ist die Netzwerkbelastung sehr gering, weil die Kommunikation mit den NetWare Dateidiensten unmittelbar erfolgt.

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:

In jedem Nachrichten-System hält jeder Server Informationen über dessen Benutzer und andere Server. NetWare Global Messaging bietet die Möglichkeit der sog. Directory Synchronisation, was das Verwalten und Updaten dieser Daten über mehrere Server hinweg automatisiert. Immer wenn Änderungen vorgenommen werden, wird eine Änderungsmeldung generiert. Außerdem werden die Verzeichnisse auch periodisch abgeglichen. Seit kurzem kann hierfür auch NDS(11) eingesetzt werden

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:

1.5.2 MS-Mail von Microsoft

Das Konzept von Microsoft baut auf einem zentralen Verzeichnis, dem sog. PostOffice auf. Solch ein Post-Office kann sich auf einem beliebigen File-Server, z. B. Windows NT oder NetWare, befinden. Es muß lediglich ein Netzlaufwerk von einer Arbeitsstation auf das Device (Platte) verweisen, auf der sich das Post-Office befindet. Zudem kann nur ein einziges PostOffice pro Server existieren.

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:

Die OLE-Funktionalität kann auch per Option abgeschaltet werden, dann sind die entsprechenden Objekte im Nachrichten-Dokument nicht nur Verweise, sondern werden direkt in das Dokument kopiert. Das ist besonders wichtig, wenn ein Austausch mit anderen Mailsystemen vorgenommen werden soll, die nicht auf Windows basieren.

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.


Footnotes

(1)
Computer Aided Design
(2)
Computer Aided Manufacturing
(3)
NetWare Global Messaging
(4)
NetWare Loadable Module
(5)
NetWare Directory Support
(6)
Electronical Data Interchange
(7)
NetWare Standard Message Format
(8)
NetWare Message Handling Service
(9)
NetWare Internetwork Messaging Protocol
(10)
NetWare Async Messaging Protocol
(11)
NetWare Directory Support (basierend auf dem X.500-Standard)
 
Table of Contents Next Chapter