Technische Grundlagen der Mailversorgung

Es lassen sich zwei grundsätzliche Funktionsbereiche unterscheiden, die einmal die Handhabung von Mails durch den Nutzer und andererseits den Austausch von Mails zwischen den Computersystemen umfassen.

Dafür werden die Begriffe MUA (Mail User Agent) und MTA (Mail Transport Agent) benutzt.

Den MUA kann man sich als tägliches Werkzeug (mail tool) zur Erledigung der Korrespondenz in der Hand des Nutzers vorstellen. Dafür ist sowohl traditionelle Standardsoftware wie mail, mailx oder elm verfügbar als auch komfortablere Software, in der Regel window-orientiert, wie eudora, happy mail oder pine, um nur einige zu nennen.

Der MTA ist mit dem Postamt vergleichbar und unter dem Namen sendmail in den UNIX-Betriebssystemen vorhanden. Diese Software muß aber in der Regel aufwendig konfiguriert werden.

Wie arbeiten diese Komponenten nun zusammen?

Der Mail User Agent

Die Mailbox des Nutzers wird durch den login-Namen (account), mit dem sich ein Nutzer an einem Rechner anmeldet, identifiziert. Sie ist ein File, in das der MTA eintreffende Mail einfach am Ende hinzufügt. Mit dem MUA seiner Wahl kann der Nutzer nun in diese Mailbox hineinschauen, um vorhandene Mails zu lesen.

Durch das Löschen oder durch die Übernahme von Mails in sogenannte Folder (Ablagen oder Ordnern vergleichbar) wird die Mailbox geleert.

Das Erzeugen einer Mail beginnt mit der Angabe der Empfängeradresse(n) und der Angabe eines Subjects, dem Betreff vergleichbar. Dem schließt sich das Schreiben des Mail-Textes an.

Hierzu benötigt man einen Editor (z.B. den vi), der ein bequemes Schreiben (Korrekturmöglichkeit, Textstrukturierung und weitere nützliche Eigenschaften) besitzen sollte. In der Welt der UNIX-Systeme sind aber gerade solche Schreibwerkzeuge nicht sehr verbreitet, so daß einfache PC-Systeme in dieser Beziehung oft mehr bieten. Schließlich muß die fertige Mail noch abgeschickt werden, wozu der MUA den MTA aktiviert und ihm die Mail übergibt. Damit ist für den Nutzer das Abschicken der Mail erfolgt.

Der Mail Transport Agent

Dieses Programm ist in der Lage, eine Mail von einem MUA zu übernehmen und sie auf den Weg zum Empfänger zu bringen. Befindet sich die Empfängermailbox auf dem gleichen Computer, dann schreibt der MTA die Mail gleich in die Mailbox. Befindet sich die Empfängermailbox auf einem anderen Computer, dann nimmt der MTA zum dortigen MTA Kontakt auf, um ihm die Mail zur Weiterleitung zu übergeben. Es können durchaus eine ganze Reihe von MTAs mit der Übertragung einer Mail zu tun haben, weil der Computer des Absenders in der Regel keinen direkten Kontakt zum Rechner des Empfängers aufnimmt.

In vielen Einrichtungen werden einem Hauptpostamt vergleichbar nur wenige Rechner als zuständige Rechner für Electronic Mail (Mailserver) im Internet, dem weltweiten Computernetz, bekannt gemacht. Sie ziehen sämtliche Mail für die Einrichtung auf sich und verteilen sie dann intern an die verschiedenen Rechner mit den Mailboxen der Nutzer weiter. An diese Mailserver werden hohe Anforderungen bzgl. Verfügbarkeit und Speicherkapazität gestellt. Es kann ja passieren, daß ein Mailserver mal ausfällt oder wegen gestörter Verbindungswege nicht erreichbar ist. In diesem Fall speichert der MTA die Mails, die er nicht los wird, in einem Zwischenspeicher ab, der sogenannten Mailqueue, um in regelmäßigen Abständen weitere Zustellversuche zu machen. Das wird aber im allgemeinen nur drei Tage lang versucht, danach wird der Absender über die fehlgeschlagene Zustellung informiert.

Dieses einfache Grunprinzip gewährleistet bis heute den weltweiten Mailaustausch. Es stammt aus der Anfangszeit der Unix- und Computernetz-Entwicklung und wurde auch auf andere Systeme übertragen.

Der Mailaustausch in einer vernetzten Computer-Umgebung setzt natürlich ein Netz voraus, in dem sich die Computer mit einer gemeinsamen Sprache unterhalten können. Diese gemeinsame Sprache, das Netzprotokoll, die sich inzwischen weltweit durchgesetzt hat, ist das TCP/IP. Alle Computer, die dieses Protokoll verstehen und weltweit netzmäßig verbunden sind, sind das Internet. Dabei sind unterschiedlichste Zugangsarten zum Netz denkbar, etwa per Telefon-Wählverbindung, ISDN, permanente Ethernetverbindung, FDDI u.a.m. Es gibt aber nicht nur dieses eine Netzprotokoll. Darum soll hier noch ein Überblick zu einigen für uns wichtigen Netzprotokollen unter dem Gesichtspunkt Electronic Mail folgen.

Das TCP/IP-Netzprotokoll

Das Internet Protocol (IP) realisiert die Adressierung der Computer in dem Netz. Eine IP-Adresse eines Rechners ist eine weltweit eindeutige, strukturierte Zahl, etwa 141.20.1.31 für einen Computer der Humboldt-Universität.

Das Transport Control Protocol (TCP) gewährleistet den Transport von Daten zwischen Rechnern, die mit dem Internet Protocol adressierbar sind. Es enthält u.a. Verfahren, wie Daten in einzelne Portionen (Pakete) aufgeteilt und am Zielrechner wieder zusammengesetzt werden können. Weiterhin muß das TCP die richtige Anwendung auf dem Computer finden, für die die Daten bestimmt sind, also z.B. den MTA, wenn es sich um eine eingehende Mail handelt.

Der Austausch von Mails zwischen verschiedenen MTAs wird nach dem Simple Mail Transport Protocol (SMTP) abgewickelt. Das SMTP benutzt seinerseits das TCP/IP als universelles Transportmittel im Netz. Insofern sind Mails auch nur Daten im Netz.

Ein solcher Dialog, bei dem z.B. ein Nutzer mit dem Account h0815xyz vom Rechner joker dem postmaster eine Mail schickt, sieht wie folgt aus:

postmaster@rz.hu-berlin.de... Connecting to mailhost.rz.hu-berlin.de (smtp)...
220 hpcom.rz.hu-berlin.de HP Sendmail (1.38.193.5/15.6-10.92) ready at Tue, 7 May 1996 14:24:15 +0200
>>> HELO joker.rz.hu-berlin.de
250 hpcom.rz.hu-berlin.de Hello joker.rz.hu-berlin. , pleased to meet you
>>> MAIL From:<h0815xyz@rz.hu-berlin.de>
250 <h0815xyz@rz.hu-berlin.de>... Sender ok
>>> RCPT To:<postmaster@rz.hu-berlin.de>
250 <postmaster@rz.hu-berlin.de>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
250 Ok
postmaster@rz.hu-berlin.de... Sent (Ok)
Closing connection to mailhost.rz.hu-berlin.de
>>> QUIT
221 hpcom.rz.hu-berlin.de closing connection

Der Dialog beginnt nach der Feststellung des MTA, daß die Mail an den Rechner hpcom.rz.hu-berlin.de weiterzureichen ist, mit der "höflichen Begrüßung". Die Rechner, tauschen Absender und Empfänger aus und anschließend den Inhalt der Mail (nicht protokolliert). Es ist ein Dialog nach festen Regeln. Dazu werden auch Zeitintervalle benutzt, nach deren Ablauf der jeweilige MTA geantwortet haben muß.Werden diese nicht eingehalten, kommt ein Mailaustausch nicht zustande.

Dabei wird vorausgesetzt, daß die Netzverbindung stabil funktioniert. Gewisse Fehler kann beispielsweise das TCP ausgleichen, z.B. durch Wiederholung von Datenpaketen. Bei einer Unterbrechung der Verbindung stellt der sendende MTA die Mail nach einigen Minuten in die Warteschlange (mailqueue) zurück, um nach einer Wartezeit einen neuen Zustellversuch zu machen.

Der Mailaustausch im Internet basiert auf diesem Protokoll und wird auch oft mit SMTP-Mail oder Internet-Mail umschrieben. Dieses Protokoll ist im wesentlichen in der Norm RFC 821 festgeschrieben.

Das X.25-Netzprotokoll

Dieses Netzprotokoll wurde/wird in den öffentlichen Datennetzen vieler Telefongesellschaften benutzt Es ist mit dem TCP/IP nicht kompatibel, d.h. daß sich ein Rechner mit TCP/IP und einer mit X.25 nicht verstehen würden. Ebenso gibt es dazu Transportprotokolle und auch ein Mailprotokoll, welches in einer Normenserie mit dem Namen X.400 beschrieben ist. Das wurde von den Postgesellschaften und Computerherstellern initiiert.

Auf dieser Basis gibt es eine ganze Reihe von Mailprodukten, die durchaus nach den oben beschriebenen Prinzipien arbeiten, aber insgesamt nicht so verbreitet sind wie Produkte auf der Basis von SMTP.

Es ist damit auch eine eigenständige X.400-Mailwelt entstanden, die mit der SMTP-Mailwelt nichts gemein hat. Dieser Zustand wurde durch die Schaffung von Gateways, die die Rolle eines Vermittlers zwischen den beiden Mailwelten übernehmen, gelöst. Gateways sind Rechner mit spezieller Software, die Mails entsprechend konvertieren können.

Bei uns wird Email mit X.400-Produkten nicht mehr unterstützt. Es gibt aber noch etliche Einrichtungen, die dieses Mailprotokoll benutzen.

Das VINES-Netzprotokoll

An unserer Universität gibt es neben dem TCP/IP-Netzprotokoll noch ein weiteres, nämlich das VINES- Netzprotokoll. Es gehört zum Banyan VINES Netzwerk, das in vielen Bereichen der Universität verfügbar ist. Dieses System besitzt ebenfalls eine Mailkomponente, die nach den oben beschriebenen Grundsätzen funktioniert. Für den Nutzer gibt es zwei recht einfache Mailtools, die jedoch die wesentlichen Funktionen abdecken. Intern gibt es natürlich mit dem Intelligent Messaging (IM) ein eigenständiges Protokoll für den Mailaustausch zwischen den MTAs im VINES-Netzwerk. Das ist zu den bisher genannten Mailprotokollen natürlich nicht kompatibel. Also auch hier haben wir es mit einer abgeschlossenen Mailwelt zu tun. Äußerlich ist das auch an den Mailadressen sichtbar. Für die Verbindung zur SMTP-Mailwelt wird bei uns ein Gateway eingesetzt, das die beiden Welten verbindet.

Schlußfolgerungen aus der Protokollvielfalt

Es gibt eine Reihe in sich abgeschlossenen Mailwelten. Davon wurden hier nur drei genannt; es gibt weitere. SMTP-Mail hat sich aber weltweit als das Mailprotokoll durchgesetzt, was aber nicht unbedingt mit "Qualität" gleichzusetzen ist.

Für die Übergänge sind Gateways erforderlich, die die Konvertierung von Mails mehr oder weniger gut realisieren.

An der Humboldt-Universität werden SMTP-Mail und VINES-Mail unterstützt.

Mit VINES-typischen Mailtools kann man nicht auf Mailboxen in der SMTP-Mailwelt zugreifen und umgekehrt.

Besonderheiten

Internet-Mail - ein sicherer Dienst?

Hier soll auf einige Aspekte der Sicherheit und Zuverlässigkeit des Mailings hingewiesen werden, die man kennen sollte:

Der Weg, den eine Mail vom Sender zum Empfänger nimmt, ist nicht festgelegt. Überlastungen oder Ausfälle einzelner Komponenten werden oft durch alternative Wege ausgeglichen. Mails können mitunter nicht zustellbar sein oder, wenn auch selten, verloren gehen. Eine Quittung für die Ablieferung der Mail beim Empfänger ist im SMTP-Standard nicht vorgesehen.

Falls die Mailbox eines Nutzers nicht existiert (das kann auch nur vorübergehend durch Ausfall einer lokalen Ressource beim Empfänger der Fall sein), dann erhält der Absender eine Mail mit dem Inhalt zurück, daß der Empfänger unbekannt ist.

Ebenfalls erhält der Absender eine Information, wenn eine Mail über einen gewissen Zeitraum (i. allg. drei Tage) nicht zustellbar war. Ein typisches Beispiel sind Verbindungen nach Japan, wo mitunter nicht einmal die Information über den zuständigen Mailserver durch das Netz kommt.

Weiterhin muß man natürlich auch Fehlfunktionen von Rechnern und Software mit einkalkulieren.

Die Palette der möglichen Einflußfaktoren zwischen Sender und Empfänger ist also relativ groß.

Weiter sollte man wissen, daß Mail nicht "privat" ist. Mails liegen auf Rechnern mitunter längere Zeit fest, sie geraten mit auf Sicherheitskopien, sie werden mitunter zur Fehlerortung analysiert. Es passiert auch, daß PC-Nutzer ihre Mailbox oder Folder auf einem PC haben, der auch von anderen Personen benutzt wird.

Ferner ist es möglich, unter falschem Absender zu arbeiten, was dann aber schon in Richtung "Mißbrauch" geht. Das sollte man durchaus wissen.

Eingeschränkter Zeichensatz

Ein zunächst übertragungstechnischer Aspekt mit weitreichenden Konsequenzen ist die Einschränkung auf die Übertragung von Zeichen im sogenannten 7-bit-ASCII-Zeichensatz, d.h. nationale Sonderzeichen (ä,ö,ü,ß, ...) oder grafische Zeichen, die 8 bit zur Darstellung erfordern, sind nicht erlaubt. Das gilt auf jeden Fall für Mailadressen und bedingt für Mailinhalte. Die Nutzung solcher Zeichen in Adressen führt zu unzustellbaren Mails, innerhalb von Mailtexten können je nach Konfiguration der Arbeitsumgebung verstümmelte Texte entstehen. Als Ausweg bietet sich eine Verschlüsselung in einem 7-bit-Code an, z.B. mit uuencode, die dann der Empfänger wieder rückgängig machen muß (uudecode). Dabei sollte man aber beachten, daß der Empfänger nicht immer gleiche Arbeitsbedingungen und Möglichkeiten hat. Automatische Verschlüsselungen verschiedener Mail-Tools sind zwar bequem, aber beim Empfänger mitunter nicht rückgängig zu machen, so daß die Mail wertlos ist. Die Abstimmung der Mailpartner auf ein gemeinsam nutzbares Verfahren ist nur zu empfehlen.

Eine Lösung dieses Problems soll langfristig mit dem MIME-Standard (Multipurpose Internet Mail Extension) erreicht werden. Zusätzliche Type-Zeilen sollen innerhalb einer Mail die Art und die Verschlüsselung des nachfolgenden Textes beschreiben. Das bedeutet, daß der erzeugende MUA solche Zeilen generieren und den Text (Binärcode, eine Grafik, ein Word-Dokument, ...) entsprechend verschlüsseln muß. Bei der Übertragung im 7-bit-Code bleibt es natürlich. Der Empfänger benötigt einen MUA, der das versteht und z.B. eine mitgeschickte Grafik auch entsprechend darstellen kann. Dann muß man noch daran denken, daß solche MUAs für verschiedenste Rechnersysteme erforderlich sind, mit anderen Worten, der MIME-Standard kann sich nur allmählich durchsetzen.

VINES Mail

VINES Mail als eigenständiges Mailsystem im Bereich der Humboldt-Universität hat mit dem deutschen Zeichensatz kein Problem. Schwierig wird es immer dann, wenn man sich dieser Besonderheit beim Abschicken einer Mail in das Internet (also eingeschränkter Zeichensatz) nicht bewußt ist. Eine ältere Gateway-Software hatte in diesem Fall diese Mail sofort an den Absender zurückgeschickt, die neuere Software setzt die Umlaute in einfache Zeichen um, also keine Umschreibung wie etwa "ä" zu "ae"! Das kann die Lesbarkeit eines Textes erheblich verschlechtern. Mit anderen Worten, diese Umsetzung ist nicht optimal, und Automatismen sind mitunter gefährlich, weil man von Problemen unter Umständen nichts ahnt.

Burckhardt Schmidt