Abbildung 28 : Beispiel für eine Workgroup-Hierarchie
Table of Contents 
Previous Chapter Diese Betrachtung ist im wesentlichen in zwei Bereiche zu unterteilen:
Die möglichen Systeme lassen sich dabei wieder einteilen in Lösungen, die auf Standards basieren, und firmenspezifische Lösungen. Dabei standen vor allem die Produkte Mercury, NGM von Novell und MS-Mail von Microsoft zur Debatte. Davon ist Mercury ein Vertreter, der auf einem Standard (SMTP) basierenden Mail-Systeme. NGM und MS-Mail stellen eigene, firmenspezifische Lösungen dar.
Im Folgenden sollen nun die Konzepte und deren Tauglichkeit für den Einsatz genauer betrachtet werden.
Des weiteren ist positiv zu vermerken, daß Mercury Freeware ist, d. h. daß die Software kostenlos zur Verfügung steht. Somit ist es auch kleineren Firmen mit geringem Budget möglich, bei entsprechender Vernetzung, das wichtige Kommunikationsmittel EMail einzusetzen.
Die Verwaltung der Nachrichten kann auf zwei unterschiedliche Arten erfolgen. Mercury bietet ein Queue- und ein Spool-Interface:
Tests im Rechenzentrum haben gezeigt, daß es keine nennenswerten Probleme beim Einsatz von Mercury gibt. Lediglich die Konfigurationsdatei mußte geringfügig modifiziert werden, um den Anforderungen gerecht zu werden. Mercury ist auch sehr wartungsfreundlich, nach der Installation und Konfiguration ist kein weiterer Aufwand nötig.
Mercury besitzt neben der Fähigkeit lokal verschickte Mail herauszufiltern und direkt zu verteilen auch die Möglichkeiten des Mail-Routing. Das Konzept ist auch hier sehr einfach und wird ebenfalls über die Konfigurationsdatei festgelegt. Allerdings ist die Flexibilität gering und sollte nur für einfaches Routing genutzt werden, z. B. um Mail auf zwei bis drei NetWare-Servern zu versenden.
Oft ist es auch erforderlich, eine Nachricht an mehrere Benutzer gleichzeitig zu verschicken. Dazu werden meist sog. Distribution-Lists eingesetzt. Auch Mercury verfügt über die Möglichkeit, solche Verteilerlisten automatisch zu verwalten. Dabei können öffentliche, moderierte und beschränkte Listen verwendet werden:
Tabelle 1: Verteilerlisten in Mercury
---------------------------------------------------------------------------------
Art Benutzerverwaltung Posten
---------------------------------------------------------------------------------
öffentliche autom. Ein- und jeder darf Mails an die Liste schicken
Liste Austragen von Mit
gliedern
moderierte autom. Ein- und nur Moderator kann in die Liste posten
Liste Austragen von Mit (Mails werden an den Moderator geschickt
gliedern und dieser entscheidet, ob sie an die Liste
geschickt werden)
beschränkte kein autom. Ein- und nur Moderator und eingetragene Mitglieder
Liste Austragen von Mit können in diese Liste posten
gliedern
---------------------------------------------------------------------------------
Man kann eine Nachricht an mehrere Benutzer gleichzeitig verschicken, indem man diese an eine Gruppe von Benutzern adressiert. Da ein Mißbrauch verhindert werden soll, muß diese Methode explizit für jedes erlaubte Gruppen-Tupel in der Konfigurationsdatei festgelegt werden.Darüberhinaus bietet Mercury auch die Möglichkeit, Nachrichten automatisch zu beantworten. Das kann z. B. verwendet werden, wenn ein Benutzer in Urlaub geht und dadurch seine ankommende Mail erst später bearbeiten kann. Das kann nun dem Absender mitgeteilt werden, indem Mercury eine festgelegte Meldung als Autoreply-Nachricht an den Absender zurückschickt.
Um eine mögliche Flut von Mails zu verhindern (das kann passieren, wenn z. B. eine Autoreply-Nachricht an eine Mailing-Liste geht, in die der entsprechende Benutzer eingetragen ist) merkt sich Mercury jede Adresse, von der eine Nachricht in den letzten 48 Stunden angekommen ist. Sollte mehr als eine Mail von derselben Adresse binnen dieses Zeitraumes (48 Stunden) ankommen, so wird nur eine Autoreply-Nachricht erzeugt.
Gelegentlich ist es auch erforderlich, den Zugriff auf einen Server zu beschränken. Hierbei kann man durch das Modul MercuryS Verbindungen von bestimmten Internet-Adressen oder Adreßbereichen erlauben oder verbieten. Das geschieht ebenfalls über die Konfigurationsdatei. Dabei wird die punktierte, numerische Schreibweise verwendet, ähnlich den Netzmasken unter UNIX.
Falls man einen anderen Mail-Namen als den Namen der Kennung haben möchte, stellt Mercury zwei Methoden zur Verfügung. Zum einen kann man für eine vollständige Adresse ein sog. Alias definieren. Dazu wird eine Quelldatei erstellt, in der die gewünschten Alias-Namen für die Benutzer aufgelistet sind (Format siehe Anhang D.4). Diese Datei wird dann mit dem Programm MALIAS.EXE. In der Konfigurationsdatei MERCURY.INI wird die daraus resultierende Datei im Abschitt zu Mercury unter Aliasfile angegeben.
Die zweite Möglichkeit ist, ein sog. Synonym zu verwenden. Hierbei kann man für Benutzer einen Namen angeben, der anstelle des Kennungs-Namens verwendet werden soll, z. B. statt SCHWARZ soll G.SCHWARZ im From:-Header erscheinen. Der Unterschied zwischen Alias und Synonym ist, daß ein Alias i. d. R. nur in eine Richtung funktioniert und ein Synonym bi-direktional wirkt, d. h. ein Synonym ersetzt die Aderesse im Header sowohl beim Senden als auch beim Empfangen. Außerdem kann für einen Benutzer maximal ein einziges Synonym existieren.
Mercury kann auch Adressen in beschränktem Umfang umschreiben, d. h. ein sog. Address-Rewriting durchführen. Dadurch kann sichergestellt werden, daß verkürzt geschriebene Adressen die richtige Domain erhalten, z. B. RZI kann ersetzt werden durch RZI.ngate.uni-regensburg.de.
Für den Einsatz auf einer größeren Anzahl von Novell-Servern, wie im Rechenzentrum gegeben, empfiehlt es sich, einen dedizierten Mailgateway für das Routing einzusetzen. Im Fall des Rechenzentrums ist das ngate. Hierbei werden nicht-lokale Mails von den NetWare-Servern an ngate geschickt, von wo aus die Nachrichten auf die entsprechenden NetWare-Server bzw. an die comsun weitergeleitet werden. Auf den Novell-Servern übernimmt dann Mercury die weitere Distribution.
Da NGM auch von Novell stammt, fügt es sich sehr gut in die NetWare-Umgebung ein. Bisher war ein Server mit NetWare v3.11 nötig, um NGM einsetzen zu können. Aber seit Kurzem ist es möglich, NGM auch auf NetWare v3.12 und v4.1 laufen zu lassen. NetWare Global Messaging besteht aus mehreren NLM`s , die je nach Bedarf am Server geladen werden. Die wichtigsten NLM`s davon sind (näheres siehe [11], Seite D-1 ):
Ist NGM installiert, so erfolgt die Konfiguration und Wartung über ein einziges NLM, dem sog. Admin-Tool. Dieses bietet eine bedienungsfreundliche, menügeführte Oberfläche und läßt sich recht leicht handhaben. Das Hauptmenü ist dabei in funktionale Bereiche aufgeteilt. Da dieses Programm ein NLM ist, muß es auf dem Server laufen. Das führt wieder zu dem Problem, daß man für Modifikationen oder Wartungstätigkeiten direkten Zugriff auf die Konsole benötigt bzw. das Programm RCONSOLE auf dem Server eingerichtet sein muß.
Daß NGM nur über das Admin-Tool zu verwalten ist, führt zu einem weiteren Problem. Es ist dadurch nicht möglich einen genaueren Einblick in das System zu erhalten, d. h. man kann nicht nachvollziehen, was bei den einzelnen Arbeitsschritten am System oder in der Bindery geändert wird. Auch die entsprechende Dokumentation ist nur mangelhaft. Dadurch ist es fast unmöglich, Fehler zu beheben.
Es gibt aber noch weitere Probleme, die in der mangelnden System-Dokumentation und dem monolithischen Admin-Tool begründet sind. Einige Konfigurationsschritte nehmen Änderungen im System vor, die nicht mehr zurückgenommen werden können, z. B. Directory Synchronisation. Das führt meist soweit, daß eine Neuinstallation unumgänglich ist.
Für NGM gibt es verschiedene Lizenzen für bis zu 1000 Benutzer. Nun ist es lastmäßig nicht sehr sinnvoll, diese 1000 Benutzer auf nur einem einzigen Server zu verwalten. Deshalb bietet NGM die Möglichkeit der Lastverteilung durch sog. Active- bzw. Passive-Servers.
Bei diesem Konzept verwaltet ein Active-Server mehrere Passive-Servers, d. h. eine Adressierung erfolgt lediglich über den Active-Server und dieser leitet Mails an die entsprechenden Passive-Servers weiter. Dabei muß auf dem Active-Server NGM installiert sein. Auf den Passive-Servern reicht es aus, eine MHS-Verzeichnisstruktur anzulegen.
NetWare Global Messaging verwendet ein völlig eigenes Adressierungsschema. Dieses basiert auf sog. Administrative Domains und Workgroups.
Administrative Domains sind dabei die oberste Schicht der logischen Organisationselemente und spielen eine Schlüsselrolle bei der Adressierung und beim Routing. Sie ermöglichen es einer Gruppe von Servern, gemeinsame Informationen und Dienste zu teilen. Außerdem können diese Server an der sog. Directory Synchronisation teilnehmen, die auf Server im selben Administrative Domain beschränkt ist.
Die Aufteilung in Administrative Domains ist dabei nicht an den physikalischen Standort eines Servers gebunden. Somit können Server in einem Gebäude, auf einem großen Firmengelände und sogar Server unterschiedlicher Firmen-Standorte, z.B. München und Regensburg zu einer Domain zusammengefaßt werden. Ein solches Administratives Domain kann dabei auch Server enthalten, auf denen nicht NetWare Global Messaging installiert ist. Diese können MHS-Server sein oder Server, die Protokolle wie SMTP, MHS, SNADS oder X.400 verwenden.
Mit den Workgroups wird die eigentliche Adressierung durchgeführt. Sie sind logische Einheiten zur Organisation von Benutzern in hierarchischen Strukturen. Jeder NGM-Benutzer muß einer solchen Gruppe im Domain angehören, dabei ist die physikalische Lage der Mailbox eines Benutzers unwichtig. Diese wird über eine NGM-Datenbank vom Server ermittelt.
Bei den Workgroups gibt es grundsätzlich zwei Typen (können auch identisch sein):
So könnte man für die Universität und Fachhochschule in Regensburg z. B. folgende Workgroup-Hierachie aufbauen (siehe Abbildung 28 auf Seite 49). Regensburg stellt dabei die Root-Workgroup dar. Darunter könnte es dann die Bereiche FH und Uni geben, die wiederum unterteilt sind in die entsprechenden Fachbereiche.
Abbildung 28 : Beispiel für eine Workgroup-Hierarchie
Eine Adresse würden dann wie folgt aussehen, unabhängig davon, auf welchen NGM-Server sich die eigentliche Mailbox befindet:Schwarz@Informatik.FH.Regensburg
Für kleinere Firmen oder wie im Falle des Rechenzentrums, wo kein so umfassender Einsatz geplant ist, kann aber auch darauf verzichtet werden eine tiefe Hierarchie aufzubauen. Eventuell kann sogar eine einzige Gruppe ausreichen.
Theoretisch wäre es also möglich, mit NGM ein globales Messaging-Netzwerk auf der Basis von MHS/NGM aufzubauen. Leider ist auch hier die Dokumentation der praktischen Realisierung nicht ausreichend. Es gibt aber Beispiele dafür, daß es auch in der Praxis funktioniert, so betreibt z. B. Novell selbst ein weltweites NGM-Netzwerk mit ca. 2500 Servern.
Um den Administratoren einen großen Arbeitsaufwand zur Abstimmung von Benutzern, Verteilerlisten und weiteren Verwaltungsinformationen zwischen verschiedenen Servern abzunehmen bietet NGM die sog. Directory Synchronisation. Dabei gibt es genau einen Domain-HUB in jedem administrativen Domain, der die benötigten Initialisierungsinformationen bereitstellt, wenn ein NGM-Server zu einem neuen Participating-Member gemacht wird. In allen anderen Belangen verhählt sich der Domain-HUB wie ein gewöhnlicher NGM-Server. Änderungen auf einem Server, z. B. neu angelegte Benutzer, werden durch sog. Directory Update Messages sofort auf allen NGM-Servern, die Mitglied im Directory Synchronisation-Verbund sind, bekanntgegeben.
Leider wurde auch bei der Realisierung der Directory Synchronisation bislang darauf verzichtet, sich an einen Standard wie z. B. X.500 zu halten. Somit war auch diese Option herstellerabhängig. Aber es wurde kürzlich eine neue Version veröffentlicht, die eine X.500-Unterstützung bietet.
NetWare Global Messaging bietet somit alle wichtigen Funktionalitäten, die für den Einsatz benötigt werden.
Das Grundkonzept von MS-Mail baut auf sog. Post-Offices auf. Ein Post-Office stellt dabei eine simple Verzeichnisstruktur dar, unter der die verschickten und empfangenen Nachrichten verwaltet werden. Aufgrund dieser einfachen Basis findet ein Nachrichtenaustausch via Dateitransfer statt und hat dadurch relativ eingeschränkte Möglichkeiten.
Soll nun ein Austausch zwischen zwei Post-Office-Rechnern bzw. zur SMTP- oder X.400-Welt stattfinden, so muß ein Gateway eingerichtet werden, ein sog. PostOffice-Exchanger. Ein einziger Gateway-Rechner kann dabei nur je zwei Server, egal ob Post-Office-, SMTP- oder X.400-Rechner, miteinander verbinden (siehe Abbildung 29 auf Seite 51). Dabei sind die Rechner RRZEXx jeweils dedizierte PC`s, auf denen ein Post-Office-Exchanger läuft. RRZEX1 ist ein Gateway zu SMTP, RRZEX2 und RRZEX3 verbinden je zwei Post-Office Rechner miteinander.
Abbildung 29 : Beispiel: Gatewaykonzept von MS-Mail
Somit ist pro Gateway ein eigener Rechner unter DOS, Windows for Workgroups bzw. Windows NT nötig. Das gesamte Mail-System ist dadurch finanziell sehr aufwendig und auch unflexibel. Positiv ist die gute Gateway-Unterstützung, d. h. es gibt eine große Palette an verschiedenen Post-Office-Exchangern, speziell im kommerziellen Bereich, z. B. für SNA-Profs von IBM.Die Adressierung gestaltet sich bei MS-Mail ähnlich der bei SMTP. Sie setzt sich auch aus Benutzer- und Rechnernamen (mit Domain) zusammen, getrennt durch "@". Dabei kann der Rechnername weggelassen werden, wenn es sich um eine lokale Nachricht handelt.
MS-Mail ist bei der Adressierung bzw. beim Versenden von Nachrichten sehr unkomfortabel. Ein Benutzer muß z. B. wissen, welches Mail-System am Zielrechner eingesetzt wird, d. h. beim Verfassen der Nachricht ist bereits festzulegen, ob diese an SMTP, X.400, usw., gerichtet ist.
Mit diesem Mail-System ist es sehr schwierig eine größere und komplexe Mail-Struktur aufzubauen, z. B. in einer Firma. Daher ist es für einen sehr breiten Einsatz eher ungeeignet.
Die benötigte Verbindung zur comsun legt dann auch schon SMTP als eines der benötigten Protokolle fest, die der Gateway beherrschen muß.
Als zweites Protokoll zwischen dem Gateway und den Novell-Servern besteht die Möglichkeit, ebenfalls ein TCP/IP-basierendes Mail-Protokoll zu verwenden, oder, die Features des Gateway-Betriebssystems UnixWare auszunutzen und ein auf IPX/SPX aufsetzendes Mail-Protokoll zu verwenden. Entsprechend kann als Gateway-Software sendmail oder das mailsurr-Konzept von UnixWare verwendet werden.
Diese beiden Lösungsmöglichkeiten sollen anschließend näher beleuchtet werden.
Um auch auf die unterschiedlichsten Mail-Setups entfernter Rechner eingehen zu können werden beim Versenden die Mail-Exchanger der entfernten Rechner bevorzugt bedient. Dies wird durch eine Abfrage der MX-Records des Domain Name Services erreicht.
Sendmail wird von den meisten Unix-Herstellern bereits mit dem Betriebssystem mitgeliefert, darüber hinaus existiert auch noch eine Reihe frei verfügbarer Implementierungen, die anstelle der mitgelieferten Mail-Software eingesetzt werden können. Es unterstützt neben SMTP noch UUCP als Transportprotokoll für EMail. Soll darüber hinaus noch ein anderes Protokoll zum Transportieren von Mails verwendet werden, so ist die Konfigurationsdatei von Sendmail, "sendmail.cf", eigenhändig an dieses anzupassen. Dies stellt auch gleichzeitig den entscheidenden Nachteil von Sendmail dar: Die Konfiguration ist extrem kryptisch!
Das folgende Beispiel zeigt dies, es stellt einen Teil aus sendmail.cf, der für das Umschreiben von Adressen zuständig ist, dar:
R<$=X$+>$+ $:$2?<$1$2>$3 Move domain out front.Da der Gateway die einzige Stelle sein soll, an der Änderungen gemacht werden sollen, wenn neue Novell-Server ans Netz gehen, ist ein unkompliziertes Schema für das Umschreiben der Adressen und das gesamte Mail-Routing von großer Wichtigkeit. Aus diesem Grund sollte Sendmail auch nicht als Gateway-Software eingesetzt werden.
R<>,$=X$+$=Y$+ $:$2?<>,$1$2$3$4 Move out in front here too.
R$-$*?<$*>$+ $:$(N$1$2$:$1?$2$)<$3>$4 Try full domain.
R$+?.$-$*<$*>$+ $(N.$2$3$@$1$:$1.$2?$3$)<$4>$5 or partial domains
R$+?$*<>,$=X$+$=Y$+ $@$6<>,$3$4$5$6 Return with local marked.
R$+?$*<$=X$+>$+ $:$4<$3$4>$5 Remove marker.
R$+<>,$=X$+$=Y$+ $@$5<>,$2$1$4$5 Return with remapped domain.
R$+<$=X$=w>$=Y$~A$* $@$5$6<$2$1>$4$5$6 Return with remapped domain.
R$+<$=X$+>$+ $@<$2$1>$4 Non-local with remapped domain
In der Konfigurationsdatei ist eine einfache Zuordnung von Anweisungen für Adreß-Umsetzung und Mail-Auslieferung für beliebige (Sender, Empfänger)-Paare möglich. Sender und Empfänger werden dabei durch reguläre Ausdrücke angegeben, bei der Mail-Auslieferung kann wahlweise SMTP, UUCP oder Novell`s MHS als Transportprotokoll verwendet werden.
Falls MHS zum Transportieren der Mails verwendet wird, so wird auch gleichzeitig eine Konvertierung des Nachrichtenformats von RFC 822 nach SMF und zurück vorgenommen. Diese nur bei UnixWare vorhandene Gateway-Funktionalität war auch ausschlaggebend für die Entscheidung, Mailsurr als Gateway-Software zu verwenden.
Novell vertreibt auch einen SMTP-MHS-Gateway, der nicht auf UnixWare basiert, dieser kostet jedoch ca. DM 6.000,-. Ein Grund mehr, den bei UnixWare als kostenlose Zugabe mitgelieferten Gateway zu verwenden.
Next Chapter