Das Post-Programm stellt eigentlich nur einen Kopfzeilen-Generator dar, d.h. es versieht den Brief vor allem mit einem Absender, der Adresse und einem Betreff. Es kann in der Regel jedoch noch weitere mehr oder weniger sinnvolle Informationen im Kopf unterbringen. Einzelne Informationen können sich dabei durchaus als nützlich erweisen. Da es eine Zumutung wäre, im Einzelnen herauszufinden, in welcher Weise die jeweiligen Programme dazu gebracht werden können, zusätzliche Informationen im Kopf unterzubringen, folgt hier eine allgemeine Vorstellung von Möglichkeiten.
Die einzelnen Daten werden in vordefinierten Feldern untergebracht, die bestimmte Namen haben. "To:" lautet der Name des Feldes für die Adresse. "From:" heißt das Feld in dem die Adresse des Absenders untergebracht wird, und "Subject:" lautet der Name für das Feld Betreff. Im Kopf eines Briefes sieht das folgendermaßen aus:
From pat Mon Jan 29 11:24:51 1996
Return-Path: <pat>
Received: by minerva.hanse.de (Smail3.1.28.1 #6)
id m0tgqlX-0006FvC; Mon, 29 Jan 96 11:24 MET
Message-Id: <m0tgqlX-0006FvC@minerva.hanse.de>
Date: Mon, 29 Jan 96 11:24 MET
From: Patrick Goltzsch <pat>
To: root@minerva.hanse.de
Subject: test
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Test
Der eigentliche Text des Briefes besteht nur in dem Wörtchen "Test". Die Leerzeile zwischen Kopf und Text interpretiert das Post-Programm als den Hinweis, daß nun der Text beginnt. Das heißt auch: Kopfzeilen dürfen keine Leerzeile enthalten.
Die drei angesprochenen Felder werden aufgeführt, aber offenbar
gibt es noch eine ganze Reihe anderer. Die ersten Zeilen bis
einschließlich zum Feld Received: stammen dabei nicht vom
Post-Programm selbst. Das Transportprogramm stempelt den Brief bei
seinem Durchgang durch verschiedene Systeme ab. Da es sich in
diesem Beispiel nur um einen einzigen Rechner als Sender und
Empfänger handelt, ist diese Information relativ kurz. Bei
längeren Wegen wird ein Received: ans nächste geheftet.
Ähnlich wie in diesem Beispiel werden Informationen über die
verwendete Transport-Software in diesen Feldern untergebracht.
Die Felder Date: und Message-Id: können vom
Post-Programm vorgegeben werden, müssen es aber nicht. Dabei dient
vor allem die "Message-Id" einer eindeutigen Identifizierung des
jeweiligen Briefes.
Die drei weiteren Felder (MIME-Version:; Content-Type:;
Content-Transfer-Encoding:) wurden von mir als Optionen des
Post-Programms gesetzt. (s. dazu
Software bzw.
MIME). Andere Felder
können entweder durch das Programm, oder per Hand hinzugefügt
werden.
Als sehr nützlich erweist sich das Feld Cc:. Cc
steht für Carboncopy. In diesem Feld werden diejenigen Adressen
untergebracht, die eine Kopie des Briefes erhalten sollen. Eine
Antwort auf einen solchen Brief kann dann sowohl an den Absender
als auch an die weiteren Adressen, die im Cc-Feld
stehen, gerichtet werden. Mit diesem Feld eröffnet sich die
Möglichkeit, eine kleine Mailing-Liste zu beginnen.
Mit Bcc: und Fcc: hat dieses Feld noch
sinnvolle Abwandlungen erfahren. Bcc für "Blind
carboncopy" schickt eine Kopie des Briefes an die angegebenen
Adressen, blendet die anderen Empfänger der Kopie im Gegensatz zu
Cc jedoch aus. Man kann also nicht wissen, ob der Brief
noch anderen Empfängern zugegangen ist, und die Antwort geht
automatisch nur an den Absender. Eine andere Möglichkeit dieses
Feld zu nutzen, besteht darin, hier die eigene Adresse
unterzubringen, um einen abgehenden Brief selbst zu
erhalten. Wird das Feld Fcc: für "Folder carboncopy"
vorgegeben, wird der abgehende Brief an die Datei
angehängt, die in diesem Feld angegeben wird.
Das Reply-To:-Feld kann dazu verwandt werden, die
Antwort auf einen Brief an eine andere Adresse schicken zu
lassen, als sie im From:-Feld genannt wird.
Das Feld Sender: erlaubt die Unterscheidung zwischen dem
eigentlichen Autor des Briefes, welcher im From:-Feld
genannt sein sollte, und demjenigen, der den Brief abgeschickt
hat. Die Antwort wird automatisch an die Adresse im
From:-Feld gerichtet.
In den Feldern Comments: und Keywords: können
zusätzliche Informationen untergebracht werden. Während das Feld
Comments: einen zusammenhängenden Text, der sich über
mehrere Zeilen erstrecken kann, erlaubt, müssen die Stichwörter
hinter Keywords: durch Kommata voneinander getrennt
werden. (Für die Leute, die es vorziehen, die Kopfzeilen selbst
zu editieren, sei angemerkt, daß neue Zeilen im
Comments-Feld mit einem Leer- oder Tabulator-Zeichen
beginnen müssen.)
Es besteht die Möglichkeit neben den vorgegebenen Feldern auch
eigene unterzubringen, z. B. Birnen-Bohnen-und-Speck:.
Es sollte allerdings beachtet werden, daß bestimmte Namen für
Felder schon belegt sein können oder in Zukunft belegt werden
könnten. Selbst-definierte Felder, die nicht für einen Standard
vorgesehen sind, sollten daher ein X-
voranstellen. Viele Post-Programme nutzen z. B. das Feld
X-Mailer:, um den eigenen Namen dort unterzubringen. Der
Nutzen selbst-definierter Felder kann durch eine Absprache
festgelegt werden; z. B. könnte eine Mailing-Liste vereinbaren,
die Kopfzeile X-Archive: zu verwenden. Es werden dann
nur die Briefe im Archiv der Liste gespeichert, welche die
Kopfzeile X-Archive: Yes tragen. Beachten: die
Namen von Feldern dürfen kein Kontrollzeichen, kein Leerzeichen
und keinen Doppelpunkt enthalten. (Der Doppelpunkt dient der
Trennung von Feldname und -inhalt.)
Weitere Details finden sich bei David Crocker: "Standard for the format of arpa internet text messages" (RFC 822).
Der RFC 822 legte 1982 in erster Linie den Standard für Kopfzeilen in der elektronischen Post fest. Dort wurde unterstellt, beim Inhalt des Briefes handele es sich um reinen Ascii-Text. Wer Dateien versenden wollte, die Zeichen enthielten, welche nicht unter den 128 des Ascii-Alphabets vorkamen, mußte die Datei so codieren, daß sie nur noch aus Ascii-Zeichen bestand.
MIME (Multipurpose Internet Mail Extensions) fügt diesem Standard vier weitere Felder hinzu, die genauer den Inhalt des Briefes spezifizieren. Aus diesen Feldern kann das Post-Programm, so es diese berücksichtigt, entnehmen, welche anderen Programme aufzurufen sind, um z. B. ein Bild darzustellen. Das heißt nicht, daß die Daten im Brief nicht codiert würden, aber ein MIME-konformes Post-Programm bietet die Möglichkeit, alle Codierungsvorgänge zu automatisieren.
Das erste Feld, welches der MIME-Standard definiert, heißt
MIME-Version:. Bislang gibt es nur die Version 1.0, so
daß der Eintrag 1.0 dem Standard genügt. Mit der
Verwendung dieses Feldes wird dem Post-Programm signalisiert, daß
der Inhalt des Briefes mit dem MIME-Standard konform geht.
Kannte der RFC 822 zwei Teile eines Briefes, nämlich den Kopf und
den Text, so können Briefe im MIME-Format aus mehreren Teilen
bestehen. Die Zeile MIME-Version: 1.0 muß nur einmal im
Kopf des Briefes auftauchen. Die anderen Felder, welche der
MIME-Standard definiert, können öfter verwandt werden. Sie
beschreiben dann jeweils die Einzelteile, aus denen der Brief
besteht.
Ein Beispiel:
(Die Informationen oberhalb der ersten Zeile hier unterscheiden sich nicht von denen anderer Briefe und wurden daher weggelassen.)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2120168431-824156555=:325"
--8323328-2120168431-824156555=:325
Content-Type: TEXT/PLAIN; charset=US-ASCII
Virtuell zu knuddeln!
--8323328-2120168431-824156555=:325
Content-Type: IMAGE/JPEG; name="Xteddy.jpeg"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.91.960212212235.325B@localhost>
Content-Description:
/9j/4AAQSkZJRgABAQAAAQABAAD//gBqICBJbXBvcnRlZCBmcm9tIE1JRkYg
aW1hZ2U6IFh0ZWRkeQoKQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjAwICBSZXY6
[..]
se78SaxeW7Qz3zeW33tqqu7/AHtv3qyaKmOGox96MSeSIUUUVuUFFFFABRRR
RZAFFFFABRRRTAKKKKACiiigAooooA//2Q==
--8323328-2120168431-824156555=:325--
Mit dem Feld Content-Type: wird der Inhalt eines Briefes
beschrieben. Im Kopf des Briefes legt das Feld
Content-Type: für den ganzen Brief dessen Aufbau
fest. Das Stichwort Multipart signalisiert, daß der
Brief aus mehreren Teilen besteht. Der Untertyp von "Multipart"
Mixed liefert den Hinweis, daß der Brief aus heterogenen
Teilen besteht. Der erste Teil dieses Beispiels besteht denn auch
aus Klartext, und der zweite Teil enthält ein Bild. Die einzelnen
Teile des Briefes werden durch eine Zahlenkombination
eingegrenzt, die im Kopf des Briefes im Feld Boundary
festgelegt wurde. Ein MIME-konformes Post-Programm sollte anhand
dieser Informationen jeden einzelnen Teil adäquat darstellen
können.
Im Feld Content-Type: können sieben verschiedene Typen
festgelegt werden, die jeweils bestimmte Untertypen zur genaueren
Beschreibung des Inhalts umfassen:
Die Typen image, audio, video sprechen für sich
selbst. Der Typ message sollte dann verwandt werden,
wenn der Brief einen anderen enthält. (z. B. einen
weitergeleiteten Brief). Der Typ application ist für die
Beschreibung ausführbarer Programme gedacht.
Dem Typ text kann noch der Parameter charset:
beigefügt werden. Die Vorgabe der Programme lautet in der Regel
charset: us-ascii. Anstelle von us-ascii kann
hier auch iso-8859-1 eingetragen werden. (Andere gültige
Werte sind die ISO-Zeichensätze iso-8859-2 - iso-8859-9, die
unter anderem arabische und hebräische Zeichensätze definieren.)
Dieser Parameter sollte die tatsächlich verwendeten Zeichen
reflektieren.
Über kurz oder lang stößt wohl jeder Benutzer der elektronischen
Post auf folgende Zeichen: =E4, =F6, =FC, =C4, =D6, =DC,
=DF; im Klartext: ä, ö, ü, Ä, Ö, Ü, ß. Für den
Fall, daß der Brief Zeilen enthält, die länger als 76 Zeichen
sind, erscheint ein =-Zeichen am Ende der Zeile für den
automatischen Zeilenumbruch. Verantwortlich für dieses Phänomen
ist der Eintrag quoted-printable im Feld
Content-transfer-encoding. Mit der Vorgabe
quoted-printable soll ein MIME-konformes Post-Programm
alle Zeichen, deren Wert größer ist als 127, hexadezimal mit einem
vorangestellten Gleichheitszeichen darstellen, und es soll
Zeilen, die länger als 76 Zeichen sind umbrechen. Unter Umständen
werden noch einige andere Zeichen codiert.
Einige Post-Programme verwenden von vornherein
quoted-printable, obwohl eine andere Belegung des Feldes
möglich ist; andere Möglichkeiten sind: 7bit, 8bit, binary,
base64. Die ersten drei signalisieren allgemein, daß keine
Codierung vorgenommen wurde. 7bit signalisiert im
Besonderen, daß ein Brief reine Ascii-Zeichen enthält;
8bit, daß ein Brief über den Ascii-Zeichensatz
hinausgeht, und binary, daß es sich um 8bit-Zeichen
handelt, wobei die Zeilenlänge über 1000 Zeichen hinausgehen
kann. base64 signalisiert ein Codierungsverfahren, in
dem eine Untermenge von 65 Zeichen des Ascii-Alphabets Verwendung
findet. Der mit base64 codierte Teil des Briefes besteht dann nur
noch aus Zeichen, die mit 7 bit dargestellt werden können. Der
Vorteil dieses Codierungsverfahrens besteht im Gegensatz zu
anderen darin, daß diese Untermenge in vielen anderen
Zeichensätzen ebenfalls enthalten ist. Damit wird eher eine
fehlerfreie Übermittlung erreicht, als mit anderen
Verfahren.
Eine ausführliche Beschreibung des MIME-Standards findet sich bei N. Borenstein und N. Freed im RFC 1521.
Wenn der Dalai Lama Herrn Kinkel plötzlich, ohne vorherige Absprache, einen Schal um den Hals legt, reagiert Herr Kinkel verwirrt. Sein Gast hat sich mit dieser Geste nicht an die Etikette gehalten und das diplomatische Protokoll gebrochen.
In der gleichen Weise, wie das diplomatische Protokoll Mißverständnisse und Peinlichkeiten einschränken soll, dienen Protokolle in der Netzwelt dazu, das regelgerechte Verhalten verschiedener Programme, die zusammenspielen sollen, festzulegen. Im Bereich des Internet heißt das Protokoll, welches den Standard zum Transport der Post festlegt "Simple Mail Transfer Protocol" (SMTP). Die Transportprogramme (Mail Transport Agent, MTA), welche das Protokoll umsetzen, heißen z. B. "sendmail" oder "smail". Die Benutzer müssen sich um diese Programme nicht bekümmern; ihnen darf es ausreichen, daß ihr Post-Programm (Mail User Agent, MUA) einen Brief an den MTA zur Zustellung übergeben kann.
Während die gelbe Post Briefe in Briefkästen sammelt, und zu vorgegebenen Zeiten weiterleitet, tritt auf einem Rechner, der an das Internet angebunden ist, der MTA sofort in Aktion. Der MTA gehört zu jenen Programmen, die immer im Hintergrund laufen und aktiv werden, sobald eine Zustellung gewünscht wird. Die Vorgehensweise des MTA nach der Übergabe des Briefes durch einen MUA kann in zwei Schritte gegliedert werden: zuerst muß der MTA die Adresse herausfinden, und dann muß er Kontakt mit dem MTA des empfangenden Systems aufnehmen.
behauptete James Bond einmal in der Gewißheit, eine allseits bekannte Nummer zu besitzen. Im Internet besitzt ebenfalls jeder Rechner eine Nummer, die ihn weltweit eindeutig identifizierbar macht. Nur ist diese Nummer, die sogenannte IP-Adresse (IP = Internet Protokoll), in den seltensten Fällen allseits bekannt, weil Menschen sich eher Namen (z. B. arme.schlucker.de) als Zahlen (z. B. 196.46.233.19) merken können. Wenn Hänsel seiner Schwester einen Brief an die Adresse gretel@arme.schlucker.de schickt, muß der MTA also zuerst die IP-Adresse von arme.schlucker.de herausfinden.
Die IP-Adresse besteht aus einer 32 Bit großen Nummer, die in vier Felder zu je 8 Bit unterteilt wird (z. B.: 193.174.4.62). 8 bit erlauben die Darstellung von Zahlen im Raum von 0 bis 255, d. h. die einzelnen Felder haben nie einen Wert über 255. Durch ihre Kombination ergibt sich theoretisch die Möglichkeit 256ˆ4, also über 4,2 Milliarden Rechner, zu adressieren. Es handelt sich deshalb um eine theoretische Möglichkeit, weil verschiedene Adressbereiche reserviert sind und nicht zur Verfügung stehen.
Um die Adresse herauszufinden, bestünde für den MTA innerhalb eines kleinen Netzes die Möglichkeit, den Namen des Zielrechners in einer Datei, die Namen und IP-Adressen verknüpft, nachzusehen. Unter Unix heißt diese Datei "/etc/hosts". In den Anfangszeiten des Internet wurde an zentraler Stelle eine Datei geführt, in der diese Verknüpfungen für das gesamte Netz gesammelt wurden. In regelmäßigen Abständen mußte diese Datei auf die teilnehmenden Rechner kopiert werden, um den aktuellen Stand zu halten. Durch das rasche Wachstum des Internet wurde diese Lösung bald unpraktikabel und 1984 wurde das Domain Name System (DNS) eingeführt. Seit dem kann ein MTA die IP-Adresse des Zielrechners bei einem Domain Name Server erfragen.
Ein Beispiel mag den Vorgang verdeutlichen. Hänsel schickt von seinem Rechner "hexenhaus.fitug.de" einen Brief an seine Schwester mit der Adresse "gretel@arme.schlucker.de". Der MTA von "hexenhaus" wird eine Anfrage an den Domain Name Server seines Netzes mit dem Namen des Zielrechners "arme.schlucker.de" schicken. Dieser antwortet, da ihm der Zielrechner unbekannt sein wird - er gehört nicht zu seiner Domain -, mit der Adresse des Domain Name Servers der Domain "schlucker.de". Daraufhin startet der MTA eine zweite Anfrage an den Name Server der Domain "schlucker.de". Erst dieser könnte mit der IP-Adresse von "arme.schlucker.de" antworten, woraufhin der MTA von hexenhaus den MTA von "arme.schlucker.de" kontaktieren und den Brief übermitteln könnte. In der Regel wird es jedoch innerhalb einer Domain für die eingehende Post einen speziellen Mail-Server geben, der immer erreichbar ist. Der Mail-Server wird in der Datenbasis des DNS über einen sogenannten MX-Record bekanntgemacht, was bedeutet, daß der Datensatz, der Name und IP-Adresse verknüpft, auch ein "mx" (Mail-Exchange) enthält. Der MTA auf "hexenhaus" fragt daher nach einem MX-Record für die Zieldomain. Als Antwort erhält er vom DNS Namen und Adresse des Mail-Servers der Zieldomain, z. B. "mail.schlucker.de", und kann den Brief dorthin übermitteln. Die Zustellung zum Zielrechner übernimmt dann der MTA von "mail.schlucker.de".
Für den Fall, daß der Zielrechner nicht erreichbar sein sollte oder Hänsel den Brief an den unbekannten Benutzer "fretel" adressiert haben sollte, übernimmt es der MTA, eine Fehlermeldung zu erstellen und den Brief zurückzuschicken.
So wie die gelbe Post Nachsendeanträge erfüllt, kann auch ein MTA Briefe weiterleiten. Sollte Gretel ihr Glück gemacht und auf Grund dessen sich eine neue Adresse, etwa "gh@neu.reich.de", zugelegt haben, kann sie in ihrem Heimat-Verzeichnis auf dem Rechner "arme.schlucker.de" eine Datei namens ".forward" anlegen. Diese Datei enthält nichts weiter als die neue Adresse. Der MTA von "arme" liest die Datei und wird den Brief an die neue Adresse weiterleiten. Eine andere Möglichkeit bestünde darin, die Zeile "forward to" gefolgt von der Adresse direkt in die Postfach-Datei zu schreiben: "forward to gh@neu.reich.de".
Eine erschöpfende Darstellung der Postzustellung im Zusammenspiel mit dem DNS enthält der RFC 974 "Mail Routing and the Domain System" von Craig Partridge.
Der urspüngliche Standard für SMTP - niedergelegt im RFC 821 - stammt aus dem Jahr 1982 und gilt, abgesehen von einigen Erweiterungen, nach wie vor. Dieser RFC 821 legte ein Minimum an Schlüsselworten fest, die jede Implementation von SMTP (d.h. die Verkörperung von SMTP in einem Programm) beherrschen muß. Dies sind:
220 arme.schlucker.com Smail3.1.28.1 #6 ready
HELO hexenhaus.fitug.de
250 arme.schlucker.com Hello hexenhaus.fitug.de
MAIL FROM: haensel@hexenhaus.fitug.de
250 <haensel@hexenhaus.fitug.de> ... Sender Okay
RCPT TO: gretel@arme.schlucker.com
250 <gretel@arme.schlucker.com> ... Recipient Okay
DATA
354 Enter mail, end with "." on a line by itself
To: gretel@arme.schlucker.com
From: haensel@hexenhaus.fitug.de
Subject: Re: Es war einmal
Iss nie Lebkuchen auf nuechternen Magen! Das gibt Alptraeume.
Haensel
.
250 Mail accepted
QUIT
Beim Verbindungsaufbau meldet sich der lokale MTA mit einer "Begrüßungszeile". Der lokale empfangende MTA wird mit "HELO" angesprochen und als sendender MTA der des Systems hexenhaus.fitug.de angegeben. Der lokale MTA antwortet mit einem Zahlencode, der dem Sender-MTA signalisiert, daß seine geforderte Aktion in Ordnung geht. Die Klarschrift nach dem Zahlencode dient nur der besseren Lesbarkeit für den Menschen (z. B. für den, der Fehler suchen muß). Auf "MAIL FROM:" folgt die Adresse des Absenders, und auf "RCPT TO:" die des Empfängers. Auf das Schlüsselwort "DATA" folgt schließlich der ganze Brief, also sowohl die Kopfzeilen, als auch der Text. Der Empfänger-MTA wird solange Text erwarten, bis ihm der Sender-MTA über eine Zeile, die nur einen Punkt enthält, signalisiert, daß der Brief zu Ende ist. Nach der letzten Bestätigung des Empfänger-MTAs könnte der Sender den nächsten Brief übermitteln, wiederum beginnend mit "MAIL FROM:". Nach dem Empfang des Briefes kopiert der lokale MTA den Brief in die Postfach-Datei des Empfängers.
Der RFC 821 legte noch einige weitere Schlüsselworte fest, z. B. "EXPN" für expand, welches eine Unterstützung von Mailing-Listen erlaubt, oder "VRFY" für verify, mittels dessen eine Bestätigung der Empfänger-Adresse gefordert werden kann. Eine ganze Reihe von RFCs haben den Standard für SMTP erweitert. Die erweiterte Version heißt nun offiziell ESMTP (für Extended SMTP). Hinzugekommen sind beispielsweise Schlüsselworte für die Unterstützung von 8bit-Briefen (z. B. solche mit Umlauten), und die Möglichkeit eine maximale Größe für Briefe, die empfangen werden, festzulegen.