Dr. Claus Aßmann
Christian--Albrechts--Universität zu Kiel,
Institut für Informatik und praktische Mathematik,
Preußerstraße 1 - 9,D--24105 Kiel
EMail: RFC 822: ca@informatik.uni-kiel.de
X.400: /PN=ca/OU=informatik/O=/PRMD=uni-kiel/ADMD=d400/C=de/
28 August 1993
If there is someone who has time and ambition to translate this article, please let me know!
Die nachfolgenden Aussagen sind gemäß der Kenntnisse des Autors richtig und enthalten einige Verallgemeinerungen. Sie sind als private Äusserungen des Autors anzusehen.
Die Verteilung von Informationen ist ein wichtiger Bestandteil der heutigen Gesellschaft. Neben den etablierten Kommunikationsmedien (Brief, Telefon) drängt sich nach den FAXgeräten als neuestes Medium Electronic Mail (EMail) geradezu auf. Es hat verschiedene Vorteile:
Während in der akademischen Welt EMail bereits ein unabdingbares Arbeitsmittel ist, ist dies in der kommerziellen Welt noch nicht weit verbreitet. Um hier einen weltweiten Standard zu etablieren, wurde von CCITT und ISO X.400 ins Leben gerufen. Es soll dem Quasistandard RFC 822, der vor allem im Internet verwendet wird, einen ``offenen'' Standard entgegensetzen, der vor allem von den Telekommunikationsgesellschaften gefördert wird. X.400 beschreibt ein Mail Handling System (MHS), das zur zuverlässigen Übertragung von Nachrichten dient.
Ein einfaches Modell der Nachrichtenübermittlung ist in Abbildung 1 dargestellt.
Die einzelnen Komponenten eines solchen Modells sind:
Eine Nachrichtenübermittlung läuft dann in etwa wie folgt ab:
Dieses Kapitel stellt kurz vor, was mit X.400 bzw. RFC 822 überhaupt gemeint ist.
X.400 ist ein Kurzname für eine Reihe von Standards, die von ISO und CCITT etabliert worden sind. Es ist der einzige nicht proprietäre Standard für den elektronischen Nachrichtenaustausch, der die Sanktionierung eines offiziellen Standardisierungsgremiuns hat [Alv93]. Mitglieder von ISO sind die nationalen Normungsgremien der Mitgliedsländer (ANSI für USA, DIN für Deutschland, usw.). Das internationale Gremium CCITT trifft Festlegungen zur Telegraphie und zum Telefon. X.400 ist eine Applikation des OSI--Referenzmodells [Tan88]. Die Entwicklung von X.400 ist in Studienperioden eingeteilt, die jeweils 4 Jahre dauern. Die unterschiedlichen Standards werden durch die Hinzufügung der Jahreszahl gekennzeichnet, d.h. es gibt X.400(84), X.400(88) und X.400(92). Die meisten verfügbaren Implementationen basieren auf X.400(84). X.400(88) ist im Vergleich zu X.400(84) stärker formalisiert und bietet einige Erweiterungen, wie z.B. AU, PDAU, MS, sowie ein Modell zur sicheren Meldungsübermittlung. Im folgenden wird zwischen diesen Normen nicht weiter unterschieden.
RFC 822 beschreibt ein Format zum Austausch von textbasierten Mails im ARPA Internet. Um ein ganzes MHS zu beschreiben, ist also mehr als nur diese Formatbeschreibung notwendig. Deshalb betrachten wir hier noch RFC 821 [Pos82], das ein Protokoll zur Übertragung von Nachrichten definiert, und TCP/IP [Hun92][Com91][Bre92], das einen Satz von Datenkommunikations--Protokollen definiert. Aus Firmen- und Forschungsaktivitäten heraus entstanden viele pragmatische Normungen, wie z.B. Ethernet von Xerox, das dann im nachhinein normiert wurde. Das IAB am SRI gibt die RFCs als Standardisierungsvorschläge heraus. Diese können als retrospektive Normen betrachtet werden. Das IAB koordiniert einen Großteil der Forschung und Entwicklung der TCP/IP Protokolle und der Anleitungen zur weiteren Evolution des Internets [Com91]. Die TCP/IP Technologie gehört also keinem Hersteller oder einem offiziellen Standardisierungsgremiun. Die Dokumentation der Protokolle, Standards und Policies sind deshalb als RFCs vom NIC zu beziehen. Die Maxime bei der Entwicklung dieser RFCs ist ([Com91], pg. 12):
Use existing protocol standards whenever such standards apply; invent new protocols only when existing standards are insufficient, but be prepared to migrate to international standards when they become available and provide equivalent functionality.
Der Vorteil von prospektiver Normierung, wie im Falle des OSI Referenzmodells, ist für komplexe Systeme darin zu sehen, daß der nicht unerhebliche Implementierungsaufwand in die richtigen Bahnen gelenkt werden kann. Trotzdem ist natürlich vorher eine gewisse Forschungsaktivität notwendig, da ansonsten die Norm aus verschiedenen Gründen (zu kompliziert, nicht anwendbar, o.ä.) fehlschlagen kann. X.400 hatte den Vorteil, die Erfahrung von existierenden Systemen in die Normierung einfliessen lassen zu können.
In Tabelle 1 sind im Vergleich die Protokollstacks OSI und TCP/IP dargestellt. [Tan88] enthält in Abschnitt 1.6.3 eine ``harsche'' Kritik des OSI Schichtenmodells. Zum einen wird die Aufteilung in die verschiedenen Layer als unpassend, zum anderen die nicht klare Zuordnung von gewissen Funktionen zu bestimmten Layern kritisiert.
Die FAQ aus der Usenet--Gruppe comp.iso.protocols.x400 [Alv93]
geben eine kurze Zusammenfassung der Unterschiede zwischen
X.400 und SMTP:
Die Adresse eines ``Agenten'' dient zu dessen eindeutigen
Identifizierung.
Genauso wie bei der ``gelben Post'' in Deutschland
ein allgemein akzeptierter Standard verwendet wird,
ist dies auch für die EMail notwendig.
Hier ist sofort der dem Benutzer am deutlichsten sichtbare Unterschied
zwischen X.400 und RFC 822 festzustellen.
In der einfachsten Form wird bei RFC 822 eine Adresse der Form
user@subdomain..domain
verwendet, während bei X.400 die sogenannte
O/R--Adresse verwendet wird, die aus einer Menge von
Attributen, d.h. Paaren von Attributtypen und Attributwerten
besteht.
Die Standardattribute (von Format 1[PLL +89])
sind in Tabelle 2 aufgeführt.
Die Adresse im RFC 822 Format spiegelt den Rechnernamen oder den ``Netznamen'' des Adressaten wieder. Da alle im Internet vertretenen Rechner einen sogenannten FQHN haben, der über das DNS [Moc87a][Moc87b] weltweit verteilt wird, kann dieser als Adresse verwendet werden. Allgemein werden allerdings MX--Records eingesetzt, um eine gewisse Unabhängigkeit von den real existierenden Rechnern (und deren Namen) zu erreichen [Par86]. Die Einteilung in Domains erfolgt im Internet in organisatorische Toplevel--Domains ([Hun92], pg. 60):
Die Einteilung der X.400 Adressen erfolgt dagegen auf
oberster Ebene nur in die Länder, und in der nächsten
Stufe in administrative Bereiche
(wie z.B. die Telekomm--Gesellschaften der Länder).
Darunter schliessen sich entweder die private
MD oder aber Organisationen an.
Diese können wiederum in organisatorische Einheiten
untergliedert sein.
Durch die Aufteilung der Adresse in Attributtypen
und -werte
ähnelt die Adressierung hier mehr
der üblichen Briefpost, obwohl bei der O/R--Adresse
explizit der Attributtyp angegeben werden muß,
während dies bei einer Briefadresse
durch die Struktur der Adresse (zeilenweise Gliederung)
meist implizit klar ist.
Da aber die Adresse in O/R--Format nicht in
Zeilen aufgeschrieben ist, müssen die Attributtypen
explizit mit angegeben werden.
Die X.400 Adresse des Autors sieht z.B. so aus:
/PN=ca/OU=informatik/O=/PRMD=uni-kiel/ADMD=dbp/C=de/.
Es gibt auch alternative Darstellungsformen für diese Adresse,
wie z.B.: PN=ca; OU=informatik; O=; P=uni-kiel; A=dbp; C=de,
wobei die erste Form diejenige ist, die von SunNet MHS
verwendet wird (man beachte die Abkürzung von ADMD und PRMD
auf ihren ersten Buchstaben bei der zweiten Form).
Betrachten wir die Situation in Deutschland.
Der Countrycode ist ``de'', d.h. bei O/R--Adressen
steht auf jeden Fall ein C=de.
Bei dem ADMD fangen die Probleme an.
Bisher gab es in Deutschland nur eine administrative Domain,
nämlich ``dbp''.
Dies hat sich in diesem Jahr allerdings geändert.
Dazu gibt es eine Mitteilung des DFN--Vereins
an alle MHS--Administrator(inn)en [vS93],
aus der der folgende Text zusammengefaßt wurde.
Die ADMD-Bezeichnung ``dbp''
wurde bei
der Einrichtung des DFN--Dienstes im Jahre 1987 in der Annahme gewählt,
daß die DBP Telekom den Dienst im Laufe der Zeit übernimmt.
Hierzu wird es aber nicht kommen,
nicht zuletzt auch aufgrund der Liberalisierung der Postgesetzgebung.
Da also auch der Telebox-400-Dienst die ADMD-Bezeichnung ``dbp'' benutzt,
muß der Namen der ADMD des DFN--Vereins geändert werden.
Gewählt wurde schließlich ``d400'' in Anlehnung an den Countrycode
und X.400.
Diese Umstellung läuft vom 3.6.93 bis 3.11.93.
Ab 1.1.94 sind die bisherigen ``dbp''-Adressen der
Mitglieder des DFN--Vereins ungültig.
Die X.400 Adresse des Autors ist ab dem 3.11.93 /PN=ca/OU=informatik/O=/PRMD=uni-kiel/ADMD=d400/C=de/.
Die o.g. Adressierungen stellen den ``Normalfall'' dar. Leider haben aber nicht alle EMail--Benutzer solche einfachen Adressen, bzw. sind nicht alle Benutzer über solche Adressen direkt zu erreichen. Dann werden gewisse ``Tricks'' notwendig, damit die EMail--Adresse in einer Notation des absendenden Systems geschrieben werden kann, die von den Rechnern ``zwischendrin'' während des Routings verstanden und umgesetzt wird. Ist z.B. jemand nicht direkt am Internet, sondern per UUCP mit einem Rechner am Internet verbunden, so kann dieser über verschiedene Adressierungsarten erreicht werden. RFC 822 erlaubt zunächst einmal zwei grundsätzlich verschiedene Adressierungsarten, von denen nur die erste offiziell unterstützt wird, während die zweite von der Implementation des MTA abhängig ist:
Eine immer wieder gestellte Frage ist die
Konversion von X.400 Adressen in RFC 822 Format
und umgekehrt.
Dazu gibt es zum einen zwei einfache Default--Abbildungen
und dann Ausnahmen von diesen Regeln.
Leider sind die Ausnahmen derart vielzählig,
daß es wohl kaum Adressen gibt,
die gemäß der Default--Abbildung umgesetzt werden.
Die Umsetzung der Adressen ist Teil der RFCs
987, 1026, 1138, 1148, 1327 [HK92][Kil87][Kil86].
Die nachfolgende Beschreibung beruht vor allen Dingen
auf [Gri87], in dem zwei minimal notwendige
Abbildungen beschrieben werden.
Abbildung (1) bildet X.400 O/R--Adressen
in das RFC 822 Format ab,
Abbildung (2) ist für die umgekehrte Richtung definiert.
Hier werden nur X.400 Standardattribute unterstützt
(vgl. Tabelle 2).
Die Default--Abbildung (1) ist wie folgt definiert:
Eine O/R--Adresse wird abgebildet nach
PN@OU.OU.
.OU.O.PRMD.ADMD.C.
Wenn ein Attribut fehlt, so wird es einfach weggelassen.
Bsp.:
/PN=ca/OU=informatik/O=/PRMD=uni-kiel/ADMD=dbp/C=de/
ca@informatik.uni-kiel.dbp.de
Die Default--Abbildung (2) ist wie folgt definiert:
Eine Adresse der Form
local@sdm.sdom
.
.sdom
.sdom
.dom
wird abgebildet gemäß:
local
PN,
sdom
OU,
sdom
OU,
sdom
O,
sdom
PRMD,
sdom
ADMD,
dom
C.
Falls
, werden PRMD, O und OU
für
werden O und OU
und bei
wird OU
nicht benutzt.
Bsp.:
Die Abbildung (2) kann nur auf Adressen angewendet werden,
deren Unterdomain und Toplevel-Domain
die Bedeutung eines X.400 Standardattributes haben.
Ein Gegenbeispiel ist
postmaster@Jpl.Nasa.gov,
da gov kein Name eines Landes ist.
Ein anderes ist
ca@informatik.uni-kiel.dbp.de,
da hier der Attributtyp O nicht verwendet wird:
/PN=ca/OU=informatik/O=/PRMD=uni-kiel/ADMD=dbp/C=de/.
Deshalb gibt es zwei Konversionstabellen (je eine für die Abbildung (1) und (2)), die diese Ausnahmen auflisten. Diese Tabellen werden in regelmässigen Abständen an alle Betreiber von X.400 - RFC 822 Gateways verteilt, deren Administratoren sie dann evtl. an lokale Gegebenheiten anpassen müssen (s. dazu auch 7). Außerdem sind nicht eindeutige Umsetzungen zu berücksichtigen:
Für die Rückübersetzung muß dann in Deutschland nur ein Eintrag ausgewählt werden:
Diese Methode ist natürlich kaum mit dem modernen DNS vergleichen, sondern erinnert stark an die Anfangszeiten des Internet, als die Hosttabelle noch zentral verwaltet wurde und regelmäßig verteilt wurde. Ob hierfür sinnvollere Methoden eingesetzt werden sollen, ist aus der Literatur leider nicht zu ersehen.
Will man die speziellen Adressierungsarten von RFC 882 nachbilden, so kann man anstelle des PN auch sogenannte DDAs benutzen. Zu diesen gehört unter anderem RFC-822, mit dem man eine RFC 822--Adresse (nach Kodierung) direkt angeben kann. Dies ist natürlich nur dann sinnvoll, wenn der Empfänger in einem Teil des EMail--Netzes ist, daß RFC 822 Adressierung verwendet und das Gateway diese DDAs unterstützt.
X.400 erfordert für die Werte von Attributen, daß diese ASN.1 ``Printable Strings'' sein müssen. Diese Printable Strings umfassen Buchstaben, Zahlen, Leerzeichen sowie die Zeichen
( ) + - , . / : = ?
Die Umsetzung der restlichen ASCII Zeichen ist in Tabelle 3 aufgelistet.
Hier noch einige Beispiele für Adressen, die sich nicht ohne Zuhilfenahme von dem DDA RFC-822 darstellen lassen:
X.400:
/DD.RFC-822=hagar#l#p#r#nuki.uucp#l#a#r#Germany.EU.net/OU=germany/O=eu/
PRMD=net/ADMD=dbp/C=de/
RFC 822:
<'' nuki!hagar'' @Germany.EU.net>
bzw.
<'' hagar%nuki.uucp'' @Germany.EU.net>
X.400:
/DD.RFC-822=js#l#p#r#pine#l#a#r#ztivax.zfe.siemens.de/OU=ztivax/O=zfe/
PRMD=siemens/ADMD=_/C=de/
RFC 822:
<'' js%pine@ztivax.zfe.siemens.de'' @ztivax.zfe.siemens.de>
Bei dem Routing gibt es viele verschiedene Möglichkeiten. Betrachten wir für RFC 822 den Fall des Internets, bei dem mit SMTP Mails verschickt werden. Wenn z.B. sendmail als Internetwork Mail Router (MTA) eingesetzt wird, so wird meistens eine direkte Verbindung zum Zielrechner aufgebaut. Im DNS kann man über MX-Records für jeden Rechner angeben, wer für ihn als MTA fungiert. Damit kann man
Ein Nachteil des DNS ist die Tatsache, daß die MX-Records eine absolute Größe angeben, d.h. nicht relativ zu irgendwelchen Gegebenheiten spezifiziert werden können. Beispiel: Der (einzige) MX-Record für Germany.Sun.COM zeigt auf Sun.COM. Dies hat zur Folge, daß EMail von Deutschland an die Sun Hotline in München über die USA geroutet wird. Selbst wenn Sun allerdings zwei Gateways in ihr internes Netz hätte, so wäre es mittels der MX-Records trotzdem nicht möglich, einen Umweg definitiv zu vermeiden, da die per DNS verteilten Daten global gültig sind.
Damit diese direkte Erreichbarkeit überhaupt
möglich ist,
erfordert SMTP keine Authentifizierung
im Gegensatz zu z.B. UUCP.
Zwar wird beim Eröffnen der Verbindung
über ein HELO Kommando der Name des sendenden
Rechners angegeben, aber es ist weder zwingend
erforderlich, daß dieser Name richtig ist,
noch wird ein Passwort verlangt.
Daher kann man prinzipiell jede beliebige
Adresse sowohl im Envelope als auch im Header
angeben, d.h. es ist ein einfaches ``forging''
möglich.
Neuere Versionen von sendmail können allerdings
feststellen, woher die Verbindung wirklich kommt
(im Rahmen der Möglichkeiten von TCP/IP),
und somit ein forging erschweren.
Das Routing bei X.400 ist z.Zt. sehr unterschiedlich. X.400 arbeitet prinzipiell nach der store-and-forward Methode ähnlich der Briefpost. Betrachtet man den Fall einer konkreten Implementation (SunNet MHS), so entspricht dies in etwa der UUCP--Methode oder der Art, wie im Usenet die News verbreitet werden: Dem Rechner ist eine gewisse Menge von ``Nachbarn'' bekannt, an die er EMail weiterleiten kann. Zwar soll durch den X.500 Directory Dienst auch ein anderes Routing ermöglicht werden (ähnlich dem der MX-Records), aber dies wird hier nicht betrachtet, da der Autor es weder in der Literatur noch in der konkret vorliegenden Implementation vorgefunden hat.
Die Verbindung zwischen dem Internet und X.400 wird durch Gateways realisiert, die üblicherweise von den ADMD--Besitzern betrieben werden. In Deutschland betreibt momentan die GMD im Auftrag des DFN--Vereins ein Gateway zwischen X.400 und anderen EMail--Netzen. Über dieses Gateway geht alle EMail zwischen dem X.400 Netz des WiN und den anderen Netzen, sofern die PRMDs nicht eigene Umsetzungen vornehmen. Die Beschränkung auf ein Gateway hat die bekannten Nachteile (Ausfälle, Überlastung, etc.). Z.Zt. läuft der Betrieb aber störungsfrei.
Der grundlegende Dienst eines MHS ist natürlich die zuverlässige Zustellung von EMail von einem Absender zu einem Empfänger. ``Zuverlässig'' heißt in diesem Zusammenhang, daß die EMail entweder an den Empfänger korrekt ausgeliefert wird, oder aber der Absender eine Benachrichtigung erhält, daß (und nach Möglichkeit warum) dies nicht erfolgt ist.
Um weiter auf die möglichen Dienste eingehen zu können, ist erst einmal eine Betrachtung des Aufbaus von EMails notwendig. Bei beiden hier betrachteten MHS ist eine EMail in zwei Teile gegliedert: den sogenannten Envelope, der Informationen für die Weiterleitung der EMail enthält, und den Content, der sich wiederum in Header und Body aufteilt.
Betrachten wir dies für SMTP einmal genauer: Der Envelope enthält eine From: Adresse, die den Absender spezifiziert. Zweiter Teil des Envelopes ist eine To: Adresse, mit der der (oder die) Empfänger angegeben werden. Der nachfolgend als ganzes übermittelte Teil besteht aus dem Header, der die Dienste beschreibt und einem Body, der die eigentliche EMail enthält. Getrennt werden diese beiden Teile durch die erste Leerzeile.
Dies entspricht auch ziemlich dem Aufbau eines konventionellen Briefes: Auf dem Briefumschlag ist die Adresse des Empfängers und üblicherweise auch die des Absenders vermerkt. Auf dem Brief selbst wird dieses im ``Kopf'' nochmals wiederholt (weshalb auch Fensterbriefumschläge so beliebt sind, um diese doppelte Beschriftung zu sparen), und im ``Rumpf'' folgt dann der eigentliche Inhalt des Briefes.
Während SMTP rein text-basiert ist, sind bei X.400 diese Daten kodiert. Dazu ist in ASN.1-Format beschrieben, wie die einzelnen Teile (Envelope, Header, Body) aussehen. Diese Kodierung spart einerseits etwas Bandbreite ein, andererseits erschwert sie das Debuggen von fehlerhaften Verbindungen (s.a. 7). X.400 erlaubt das standardisierte Verschicken von anderen Formaten als reinen Text. Aufgeführt sind: IA5 Text: International Alphabet 5 (ISO 646), TLX: Telex, Voice: Sprache, G3FAX: Fax Gruppe 3, TIF.0: Text Interchange Format (Fax Gruppe 4), TIF.1: Fax Gruppe 4, Klasse 2+3, TTX: Teletex, Videotext, NationallyDefined, Encrypted (nicht näher spezifiziert), und SFD: Simple Formattable Document. In X.400(84) waren die meisten dieser Formate mit ``for further study'' gekennzeichnet. Wie bereits in Abschnitt 3 geschrieben, sind kaum spezielle Formate implementiert.
Dienste sind bei RFC 822 explizit im Header spezifiziert, während sie bei X.400 mittels der ASN.1 kodiert sind und für den Absender bzw. den Empfänger in eine lesbare Form gebracht werden müssen. Durch diese Kodierung (entspricht in etwa der Definition einer Datenstruktur in C) ist eine Erweiterung um weitere Dienste auch kaum möglich, da dann alle MTA und MUA geändert werden müssen. Bei RFC 822-basierender EMail können dagegen einfach weitere Header--Zeilen angefügt werden, die neue Dienste beschreiben. Dies ist durch die Konvention möglich, daß MTA und MUA ihnen unbekannte Header-Zeilen ignorieren (aber trotzdem weiterleiten) sollen. Eine Erweiterung von RFC 822 für die Übertragung von anderen Datenformaten ist in RFC 1341 - 1344 beschrieben inklusive der notwendigen Umgebung [BF92]. Dies ist aber auch Inhalt eines anderen Vortrages im Rahmen dieser Tagung [Fre93], und soll deshalb hier nicht weiter aufgeführt werden.
Dienste, die beiden Mailstandards gemeinsam sind, können bei einer Konversion natürlich auch beibehalten werden und sind somit in den entsprechenden Dokumenten beschrieben [Gri87][HK92][Kil87][Kil86].
Diese Dienste umfassen (hiervon sind einige optional, andere müssen wiederum nur dann vorhanden sein, wenn andere fehlen (für Details s. z.B. [Cro82])):
RFC 822 definiert noch einige ``Resent-'' Header, die zur Identifizierung von weitergeleiteten EMails dienen (forwarding).
X.400 hat einige Dienste definiert, die bei RFC 822 desöfteren vermißt werden, darunter die Versendung von Empfangsbestätigungen. Während sendmail zwar die Verwendung von Return-Receipt-To: erlaubt, ist dies aber nicht durch RFC 822 standardisiert. Für diese Zwecke unterscheidet X.400 auch zwischen mehreren EMail--Typen; es gibt nicht nur die üblichen Nachrichten zwischen Benutzern, sondern auch
Einige interessante Dienste von X.400, die keinen Gegenpart in RFC 822 haben, sind:
Es gibt noch wesentlich mehr Dienste, die von X.400 definiert werden, aber diese können z.B. in [Geh89] nachgelesen und sollen hier nicht alle aufgelistet werden.
Das Institut für Informatik und praktische Mathematik der Christian-Albrechts-Universität zu Kiel (im folgenden als IfI und CAU abgekürzt) betreibt ein X.400 -- RFC 822 Gateway. Dabei wird auf einer SPARC 10/41 die SunNet Software eingesetzt [Sun91]. Diese besteht hier aus den Teilen: SunNet X.25, SunNet OSI, und SunNet MHS. Über dieses Gateway wird nicht nur das IfI, sondern auch etwa 10 weitere Institute an der CAU mit EMail versorgt. Einen kleinen Ausschnitt dieses Netzes zeigt Abbildung 2.
Die Einbindung ist dabei wie folgt: Eine externe Verbindung mittels X.400 über X.25 zu dem RZ der Universität, die Verbindung zu den Instituten erfolgt mittels SMTP über Ethernet. Als zentraler MTA im IfI dient sendmail [All93a][All93b] von Sun ([Sun90], Ch.20), das X.400 als einen speziellen Mailer einsetzt, und zwar als sogenannten ''major relay mailer''. Dieser ist der default mailer, der verwendet wird, falls keiner der anderen Mailer für die Weiterleitung der Mail ``paßt''. Im RZ dient eine VAX als MTA. Die Installation von SunNet MHS hat beim erstenmal über 2 Tage gedauert, da offenbar bisher niemand in Deutschland eine Sun und eine VAX über X.400 verbunden hatte (zumindest war Sun Deutschland nicht so hilfreich wie sonst). Dazu mussten auf verschiedenen Ebenen Tracetools eingesetzt werden, die den Datenstrom in eine halbwegs lesbare Form umsetzen (etwa vergleichbar mit einem Hexdump einer Binärdatei). Da die Software auch noch als Teil des Kernels eingespielt werden muß, hat sich die Installation als überaus schwierig erwiesen.
Durch das IfI gehen ca. 75% aller X.400--Mails der CAU. In den letzten Monaten waren dies etwa 700 EMails täglich.
SunNet MHS enthält keinen X.400 UA, sondern das
``gateway attempts to make X.400 appear as an
extension of RFC 822 and vice versa''.
Bekannte Beschränkungen sind laut Handbuch:
Das Folgende ist ein Auszug aus unserem Konfigurationsfile von SunNet MHS, wobei sowohl ganze Einträge gelöscht als auch einzelne Einträge gekürzt worden sind.
# X.400 CONFIGURATION FILE
this_x400_domain = /O=/PRMD=uni-kiel/ADMD=dbp/C=de/;
this_internet_domain = "uni-kiel.de";
this_mta_name = "gutemine";
######## Neighbor MTA configuration
neighbor_mtas = { { mta_name = "rz.uni-kiel", is_same_domain = true } }
# X.400 Routing (Mandatory)
# There can be at most 120 routing entries.
x400_routing = {
# Route within our domain
{ x400_domain=/OU=informatik/O=/PRMD=uni-kiel/ADMD=dbp/C=de/, next_mta=internet }
{ x400_domain=/OU=pz-oekosys/O=/PRMD=uni-kiel/ADMD=dbp/C=de/, next_mta=internet }
{ x400_domain=/OU=rz/O=/PRMD=uni-kiel/ADMD=dbp/C=de/, next_mta="rz.uni-kiel" }
{ x400_domain=/OU=sfb313/O=/PRMD=uni-kiel/ADMD=dbp/C=de/, next_mta=internet }
{ x400_domain=/OU=theo-physik/O=/PRMD=uni-kiel/ADMD=dbp/C=de/, next_mta=internet }
# Route our domain to gateway
{ x400_domain = this_x400_domain, next_mta = "rz.uni-kiel" }
# Route other domains through neighbor MTAs
# { x400_domain = /PRMD=???/ADMD=???/C=??/, next_mta = "???" }
# Route anything else to ADMD
{ x400_domain = *, next_mta = "rz.uni-kiel" }
}
# Local Directory Tables (Optional)
# The following table associates user names with X.400 personal names.
local_directory_tables = {
{ orname_component=/OU=informatik/, internet_subdomain="informatik",
pn_file="cfg/local.pns.informatik", uname_file="cfg/local.unames.informatik" }
{ orname_component=/OU=pz-oekosys/, internet_subdomain="pz-oekosys",
pn_file="cfg/local.pns.pz-oekosys", uname_file="cfg/local.unames.pz-oekosys" }
}
# Special Address Translations (Optional)
# For each association as specified by RFC 987 (section 4.2.1 and
# appendix F), there should be an rfc_987_association entry below.
# Entries should be ordered so that the more general ones are later.
special_address_translations = {
rfc_987_association = {
x400_domain = /PRMD=uni-graz/ADMD=ada/C=at/
,internet_domain="uni-graz.at" }
rfc_987_association = {
x400_domain = /OU=bcsystems/OU=gov/O=bc/PRMD=bcgovt/ADMD=telecom.canada/C=ca/
,internet_domain="bcsystems.gov.bc.ca" }
rfc_987_association = {
x400_domain = /OU=hrz/O=/PRMD=th-darmstadt/ADMD=dbp/C=de/
,internet_domain="hrz.th-darmstadt.d400.de" }
rfc_987_association = {
x400_domain = /OU=informatik/O=/PRMD=uni-kiel/ADMD=dbp/C=de/
,internet_domain="informatik.uni-kiel.de" }
rfc_987_association = {
x400_domain = /O=/PRMD=uni-kiel/ADMD=dbp/C=de/
,internet_domain="uni-kiel.dbp.de" }
}
Erklärung zu den einzelnen Einträgen:
Hier sieht man, daß sich das Gateway für eine ``höhere'' Ebene zuständig erklärt, damit auch andere Subdomains (bzw. OUs) von ihm bearbeitet werden können. Dies ist ein kleiner Hack, da sich auch das RZ für den gleichen X.400--Domain zuständig erklärt. Das ganze wird aber durch die entsprechenden Routing--Einträge wieder ``zurechtgebogen''.
Der spezielle Wert ``this_x400_domain'' für x400_domain bezieht sich auf diesen Domain (es muß ein solcher Eintrag vorhanden sein).
Diese Tabellen werden für jeden Subdomain einzeln spezifiziert. Die Felder orname_component und internet_subdomain werden also jeweils vor die oben genannten Domains this_x400_domain bzw. this_internet_domain gehängt.
In diesen Tabellen werden die Umsetzungen vom local-part einer RFC 822 Adresse in den Attributwert für PN der O/R--Adresse und umgekehrt spezifiziert. Während zwar EMails von ``innen'' (d.h. von der RFC 822 Seite) auf jeden Fall durchgelassen werden, werden aber in der Gegenrichtung unbekannte PN--Werte vom Gateway zurückgewiesen. Es ist also notwendig, für jeden einzelnen Benutzer einen Eintrag in den entsprechenden Tabellen vorzunehmen. Dies hat zwar einerseits den Vorteil einer Kontrollierbarkeit der Benutzung des Gateways, andererseits bedeutet es aber einen nicht geringen administrativen Aufwand.
notwendig. Da aber das vorgesehene Patternmatching sehr eingeschränkt ist (nur vollständig fehlende Teile sind erlaubt, keine regulären Ausdrücke wie oben angedeutet, o.ä.), müssen alle diese Ausnahmeregeln explizit aufgeführt werden. Die Tabelle bei unserem Gateway umfaßt mehr als 1600 Ausnahmeregeln.
Einige Erfahrungen mit den Gateways von X.400 ins Internet sind sehr frustierend. Beispiele hierfür sind
Report from domain /PRMD=gmd/ADMD=dbp/C=de/:FAILED delivery to:
1 Recipient ORName: /PN=Hardi.Hungar/OU=arbi/O=informatik/PRMD=uni-oldenburg /ADMD= /C=de/ Translates to: Hardi.Hungar@arbi.informatik.uni-oldenburg.de Reason: transfer failure Diagnostic: mta congestion
X.400 hat durch seine große Anzahl von Diensten RFC 822 einiges voraus. Andererseits werden aber auch durch neue Spezifikationen weitere Dienste (MIME etc) für RFC 822-basierende EMail ermöglicht. Welches MHS für einen Anwender (oder eine Institution) in Frage kommt, hängt von deren Bedürfnissen und Präferenzen ab. Die Verfügbarkeit von PD (bzw. frei verfügbaren) Implementationen ist für den interessierten Anwender sicherlich ein großes Plus. Kommerzielle Institutionen, die keine entsprechende Computerabteilung und die auch ein gewisses Sicherheitsinteresse haben, werden sicherlich X.400 vorziehen.
Für den Forschungsbereich wird aber wohl noch
lange ein Zitat von Tom Limoncelli gelten:
``X.400 is the mail system of the future. Let's keep it that way''.
appendix
Claus Aßmann (ca@informatik.uni-kiel.de)