Forum

E-Mail, das unbekannte Bekannte
April 17, 2006, 23:09:06
Täglich erstellen wir E-Mails, geben eine Empfängeradresse an und drücken den „Senden“ Knopf. Und täglich empfangen wir E-Mails und erhalten sie von unserem E-Mail Programm angezeigt. Wir wissen, dass der Internet Dienst „E-Mail“ dazu da ist, Mitteilungen an andere Computerbenutzer zu senden. Aber wie das genau abläuft, davon haben die wenigsten von uns eine Ahnung. In Foren tauchen denn auch immer wieder Fragen im Zusammenhang mit E-Mail auf, die sich aus der Unkenntnis dieser vom Benutzer nicht direkt einsehbaren Abläufe ergeben. Dieser Text versucht ein wenig Licht in diese verborgenen Abläufe zu bringen und häufig auftauchende Fragen zu beantworten. (Nicht eingehen wird der Text hingegen auf Fragen zu einzelnen E-Mail Programmen.)

Früher oder später taucht im Zusammenhang mit E-Mail immer auch die Geschlechterfrage auf.  ;) Klären wir dies also gleich zu Beginn. Das Variantenwörterbuch des Deutschen (Verlag Walter de Gruyter Berlin ISBN 3-11-016574-0) äussert sich dazu wie folgt: „E-Mail das/die; -s/-, -s [`i:me?l A CH, `i:me:l D] <engl.>: ist in A meist Neutrum, in D meist Femininum, in CH schwankend.“ Ich bin mir als Schweizer sowohl im aktiven wie passiven Sprachgebrauch fast ausschliesslich die Verwendung des Neutrums gewohnt. In diesem Text erscheint, wo ich die Frage nicht umschifft habe, E-Mail somit als Neutrum. Diskussionen darüber sind zwecklos.  ;)

Obwohl der Internet Dienst „E-Mail“ aus Sicht des Benutzers und konzeptionell gesehen relativ simpel ist, steckt eine ziemlich komplexe Ansammlung von Protokollen, Standards und Konventionen dahinter. Dass diese in den diversen Programmen, die sich um den E-Mail Versand kümmern, unterschiedlich gut umgesetzt sind, kann öfters zu Verwirrung und Problemen führen. Mit etwas Hintergrundwissen lassen sich jedoch viele dieser Probleme umgehen oder vermeiden.

Eine E-Mail Mitteilung besteht aus drei Teilen, dem Envelope (Umschlag), dem Header (Kopfdaten) und dem Body (eigentliche Mitteilung, Inhalt). Wir werden uns diese drei Teile in umgekehrter Reihenfolge ansehen und so von der Benutzersicht langsam etwas tiefer in die Technik dahinter vordringen.
« Letzte Änderung: August 21, 2006, 09:12:25 von warlord »
_______
Complete liberty of contradicting and disproving our opinion, is the very condition which justifies us in assuming its truth for purposes of action; and on no other terms can a being with human faculties have any rational assurance of being right. (John Stuart Mill - On Liberty)
Re: [Vorschlag] E-Mail, das unbekannte Bekannte
Antwort #1: April 17, 2006, 23:16:32
Der Body

Zentral und von grösstem Interesse für mich als Benutzer ist natürlich der Inhalt. Denn ich will mit E-Mail ja irgend etwas von hier nach dort versenden (oder umgekehrt, natürlich). Aber was ist denn dieses „etwas“, das ich mit E-Mail versenden oder erhalten kann? Text, Dokumente, Bilder, Dateien sind Antworten, die wohl ein grosser Teil der Leser basierend auf den eigenen Erfahrungen mit E-Mail so von sich geben wird. Streng genommen ist aber nur die erste Antwort richtig. E-Mail kann eigentlich nichts anderes, als reinen simplen unformatierten nackten ASCII Text transportieren. Und dabei darf der Text noch nicht einmal alle der total 256 Zeichen des ASCII-Alphabetes enthalten. Denn ursprünglich ist E-Mail als 7-Bit Dienst ausgelegt. Das heisst, der Dienst nutzt jeweils nur 7 von 8 Bits in einem Byte zur Darstellung von Daten. Das 8. Bit diente lediglich Prüfzwecken. Und mit 7 Bits lassen sich nur Zeichen der ersten Hälfte des ASCII Alphabetes darstellen. Die Zeichen in der zweiten Hälfte, z.B. die deutschen Umlaute, können nicht direkt dargestellt werden.
 
Gesprengt wird diese Limitierung auf 7-Bit Text heute durch die sogenannten MIME-Erweiterungen. Dabei handelt es sich, vereinfacht ausgedrückt, um eine Reihe von standardisierten Verfahren zur Um- und anschliessenden Rückwandlung von allem, was Menschen via E-Mail transportiert haben möchten und keinen 7-Bit Text darstellt in eben solchen 7-Bit Text. Die ab 1992 eingeführten MIME-Erweiterungen haben E-Mail erst zu jenem Arbeitstier gemacht, als das wir es heute wahrnehmen und nutzen. Sie sind aber auch der Hort der meisten Probleme, mit denen sich E-Mail Nutzer so herum schlagen. Denn nutzen Absender und Empfänger nicht das selbe E-Mail Programm und haben deren Programmierer die festgelegten Standards zur Um- und Rückwandlung nicht auf die genau gleiche Weise interpretiert und umgesetzt oder sind sie gar absichtlich von den Standards abgewichen, dann kommt es bei diesen Umwandlungen zwangsläufig zu Pannen, welche die E-Mail Kommunikation erschweren.

MIME definiert für diese Umwandlungen 5 Kodierungsarten: 7bit, 8bit, Binary, Base64 und Quoted-Printable. Wobei die ersten 3 eigentlich nicht wirklich Kodierungen, sondern lediglich Angaben sind.
7bit entspricht dem normalen ursprünglichen Standard für den E-Mail Body. Fehlt die Angabe der Kodierung, wird automatisch 7bit angenommen. Daten mit 7bit Schema können aus Zeilen von maximal 998 Zeichen, jeweils abgeschlossen mit einem CRLF bestehen. Innerhalb der Zeilen dürfen alle Zeichen mit einem ASCII Code kleiner als 128 vorkommen, mit Ausnahme von ASCII 0, CR und LF.
Das 8bit Schema entspricht weitgehend dem 7bit Schema, mit dem Unterschied, dass hier auch Zeichen mit einem ASCII Code grösser als 127 und ASCII Code 0 erlaubt sind. Es ist somit nicht eine wirkliche Kodierung, sondern eher eine Deklaration, dass gewisse Limitierungen missachtet und überschritten werden. Diese beiden Schema sind durch ihre Zeilenorientiertheit eigentlich nur für Text geeignet.
Beim Binary Schema handelt es sich gewissermassen am wenigsten um eine Kodierung. Es bezeichnet die „normale“ Darstellung von beliebigen 8-Bit Daten ohne Einschränkungen bezüglich Zeilenlänge und erlaubten Zeichen. Derzeit gibt es allerdings noch keine Möglichkeit, diese „Kodierung“ direkt in einem E-Mail zu verwenden.
Base64 ist eines der beiden Schema, das eine tatsächliche Kodierung darstellt. Es dient der Umwandlung von beliebigen 8-Bit Daten in Textblöcke und ist somit das Arbeitstier der MIME-Erweiterungen, das immer dann zum Einsatz kommt, wenn etwas anderes als Text transportiert werden soll. Eine passable Erklärung der Base64 Kodierung findet sich bei Wikipedia.
Ebenfalls eine echte Kodierung stellt das Quoted-Printable Schema dar. Im Gegensatz zur Base64 Kodierung werden dabei nicht die kompletten Daten, sondern (vereinfacht gesagt) nur die im E-Mail Body nicht erlaubten Zeichen kodiert. Auch diese Kodierung ist damit in erster Linie für Text geeignet. Eine kurze Erklärung findet sich ebenfalls bei Wikipedia.
Der Vollständigkeit halber zu erwähnen ist noch ein sechstes Schema: Uuencode. Das aus Ur-UNIX-Zeiten stammende Kodierverfahren war in den Zeiten vor MIME praktisch die einzige Möglichkeit, 8-Bit Daten via E-Mail zu transportieren. Es wurde daher in den jungen Jahren des Internets, als dieses noch fast ausschliesslichlich aus UNIX Rechnern bestand, zur Umgehung der Limiten des Dienstes E-Mail verbreitet eingesetzt. Es ist auch heute mitunter noch anzutreffen, obwohl es nie Eingang in die MIME Standards gefunden hat und somit für den E-Mail Verkehr offiziell nicht „zugelassen“ ist.
   
Als damit begonnen wurde, mit E-Mail auch Daten zu versenden, die nicht Text darstellen, stellte sich damit für die E-Mail Programme noch ein weiteres Problem. Wie sollte das empfangende Programm wissen, worum es sich bei den empfangenen kodierten Daten handelt, und wie und als was es sie folglich darstellen sollte? Ist es ein Bild? Ist es Ton? Oder sonst etwas? Zur Lösung dieses Problems definieren die MIME Standards sogenannten Medientypen, mit welchen die Daten „etikettiert“ werden können. Diese häufig einfach kurz MIME-Typ genannten MIME-Medientypen finden heute auch ausserhalb der E-Mail Welt Verwendung, insbesondere im Web bei HTTP-Übertragungen. Die Bezeichnung eines Medientyps setzt sich aus zwei Teilen zusammen, einem Haupttyp und einem Subtyp.
MIME definiert 8 Haupttypen: text, image, audio, video, application, message, multipart und model. Für jeden dieser Haupttypen gibt es eine Reihe von Subtypen - zur Zeit sind dies über 130. 7 Haupttypen mit ihren wichtigsten Subtypen werden nachfolgend kurz vorgestellt.
Der Haupttyp text definiert naheliegenderweise textbasierten Inhalt. Alle Subtypen dieses Haupttyps können theoretisch ohne zusätzliche Programme zur Darstellung und Formatierung des Inhalts gelesen werden. Die wichtigsten Subtypen sind plain (text/plain) für nicht strukturierten, nicht formatierten Text, enriched (text/enriched) für Text, der mit einer einfachen Beschreibungssprache in Farbe, Ausrichtung und Schrift beeinflusst werden kann, sowie html (text/html).
Was die Haupttypen image, audio und video definieren, dürfte sich aus ihren Namen von selbst erklären. Allerdings ist die ursprüngliche Liste der dazu definierten Subtypen sehr beschränkt, so dass Bild-, Audio- und Videodaten häufig nicht mit diesen Haupttypen etikettiert werden: image/jpeg, image/tiff, video/mpeg und audio/basic (8-Bit ISDN mu-law Audiodatei). Andere Bild-, Audio- und Videodaten werden dadurch häufig als application/octet-stream etikettiert.
Der Haupttyp application dient zur Bezeichnung von Daten, die in einem programmspezifischen Format vorliegen. Dieser Haupttyp weist die grösste Anzahl Subtypen auf. Subtypen mit besonderer Bedeutung sind octet-stream, applefile und mac-binhex40. Der Subtyp octet-stream bezeichnet einen Strom beliebiger, nicht näher definierter Daten und ist damit das Sammelbecken für alle Daten, deren Art unbekannt ist oder für die kein spezifischerer Medientyp existiert. Alle E-Mail Programme müssen in der Lage sein, mindestens diesen Medientyp zu „verarbeiten“, was heisst, eins zu eins in eine Datei zu speichern. Alle ihm nicht näher bekannten Medientypen, muss ein E-Mail Programm als application/octet-stream behandeln. Damit ist für alle Medientypen eine Minimalbehandlung (also das Speichern in eine Datei) gewährleistet. Der Subtyp applefile etikettiert eine AppleSingle Datei. Dieses Dateiformat, das dazu diente, traditionelle Mac Dateien mit ihren zwei Zweigen (Forks) als einen einzigen Datenstrom darzustellen und so sicher durch Nicht-Macintosh-Computer zu schleusen, findet heute kaum mehr Verwendung. AppleSingle Dateien können von den wenigsten Nicht-Macintosh-Computern interpretiert werden. Häufiger genutzt und auch von Fremdsystemen etwas verbreiteter verstanden sind oder waren BinHex kodierte Mac-Dateien. Für sie existiert der MIME-Subtyp mac-binhex40. Auch sie finden seit Mac OS X aber kaum mehr Verwendung.
Der Haupttyp message etikettiert E-Mail Mitteilungen und dient damit dem „Verkapseln“ von E-Mail Mitteilungen in andere E-Mail Mitteilungen. Wichtige Subtypen sind partial, external-body und delivery-status. Mit dem Subtyp partial ist es möglich, grosse E-Mails in mehrere kleine Mails aufzusplitten, die dann am Bestimmungsort wieder zu einem einzigen grossen Mail zusammen gesetzt werden. Mit Hilfe des Subtyps external-body kann auf das Mitsenden von bestimmten Daten verzichtet werden, die auf andere Weise verfügbar sind. Die „fehlenden“ Daten werden erst am Bestimmungsort direkt von der angegebenen Quelle via FTP, TFTP, Mail, HTTP oder lokalem Dateizugriff besorgt und in die Mitteilung hinein kopiert. (Der Subtyp delivery-status kann an dieser Stelle noch nicht erklärt werden. Dafür muss auf Begriff zurück gegriffen werden, welche erst im dritten Teil über das Envelope erläutert werden.)
Der Haupttyp multipart dient dazu, verschiedenartige Daten in eine Mitteilung zu „verkapseln“. Die wichtigen Subtypen sind mixed, alternative, digest und appledouble. Davon der wichtigste ist mixed. Mit ihm können ganz einfach verschiedene Daten (z.B. mehrere Grafiken oder andere Dateien), die keinerlei Verbindnung zueinander haben müssen, in eine Mitteilung gepackt werden. Dieser Subytp dient, ähnlich wie application/octet-stream, als Rückfall-Typ. Trifft ein empfangendes E-Mail Programm auf einen multipart Subtyp, den es nicht unterstützt, sollte es ihn als multipart/mixed betrachten und behandeln. Der Subtyp alternative dient dazu, die selben Daten in unterschiedlichen Formaten zu senden (z.B. einmal als Text und einmal als HTML). Der Empfänger bzw. das empfangende Programm kann sich aussuchen, welches der mitgesandten Formate es darstellt. Es sollte dabei die Daten nur in genau einem Format anzeigen. Der Subtyp digest dient dazu, mehrere E-Mail Mitteilungen in einer einzigen Mitteilung zusammen zu fassen. Diese Technik wird häufig in Mailing Listen verwendet. Der Subtyp appledouble ist für uns Macianer von Bedeutung. Er dient, wie die zwei weiter oben erwähnten Typen application/applefile und application/mac-binhex40 dem Versand von traditionellen Mac Dateien mit zwei Zweigen (Forks) und ist die dafür zu bevorzugende, da von Nicht-Macintosh-Computern am häufigsten und besten verstandene Methode. Im Gegensatz zu ersteren Methoden werden mit multipart/appledouble die beiden Zweige nicht in einen einzigen Datenstrom verpackt, sondern als voneinander getrennte Datenblöcke versandt. Dies führt bei Besitzern von Nicht-Macintosh-Computern mitunter zu Verwirrung, wenn ihr E-Mail Programm die beiden Zweige als zwei separate Dateien anzeigt. Jede Datei scheint dann doppelt vorhanden zu sein, jeweils in einer meist kleineren „Version“ (= Ressourcenzweig), die sich auf dem Fremdsystem (für uns logischerweise) nicht öffnen lässt, und einer meist grösseren „Version“ (= Datenzweig), die sich normal öffnen lässt.

Quintessenz
Der Macianer stellt sein E-Mail Programm mit Vorteil so ein, dass jenes Mac-Dateien bei Bedarf als multipart/appledouble versendet.
Der Windowsianer ist sich bewusst, dass ihm sein E-Mail Programm Dateien, welche von einem Macianer gesendet wurden, möglicherweise doppelt anzeigt. Öffnen kann er nur eine davon. Die „andere Datei“ enthält zusätzliche Informationen, mit welcher nur ein Macintosh-, nicht aber ein Windows-Computer etwas anfangen können. Dies ist „normal“ und kein Grund zur Beunruhigung. Vor allem ist es kein Fehler des Absenders, sondern eine suboptimale Vorgehensweise des empfangenden E-Mail Programms bei der Anzeige des MIME-Typs multipart/appledouble.
_______
Complete liberty of contradicting and disproving our opinion, is the very condition which justifies us in assuming its truth for purposes of action; and on no other terms can a being with human faculties have any rational assurance of being right. (John Stuart Mill - On Liberty)
Re: [Vorschlag] E-Mail, das unbekannte Bekannte
Antwort #2: April 17, 2006, 23:34:38
Der Header

Ähnlich wie ein herkömmlicher papierener Brief weist auch ein E-Mail einen Briefkopf auf, in welchem interessante Dinge wie Absender, Adressat und Datum zu finden sind. Dieser Briefkopf wird bei einem E-Mail Header genannt. Er besteht aus mehreren Teilen, die Felder genannt werden. Ein Feld besteht aus einem Feldnamen, gefolgt von einem Doppelpunkt (Colon), dem Feldinhalt und einem CRLF. Dazwischen darf sich grundsätzlich beliebig Leerraum befinden. Felder können sich auch über mehrere Zeilen erstrecken. Sogenannte Folgezeilen, welche noch zum Feld in der Zeile oberhalb gehören, beginnen mit Leerraum.
Es existieren die folgenden standardisierten Felder (diese werden weiter unten noch näher vorgestellt): From, Sender, Reply-To, To, Cc, Bcc, Message-ID, In-Reply-To, References, Date, Received, Return-Path, Subject, Comments, Keywords und Encrypted (veraltet). Dabei müssen in einem E-Mail mindestens die Felder Date und From sowie mindestens eines der Adressatenfelder To, Cc oder Bcc vorhanden sein. (Zudem müssen während der Reise des E-Mails Received Felder hinzu kommen. Mehr dazu aber im dritten Teil über das Envelope.) Neben diesen Standardfeldern gibt es für E-Mail Software die Möglichkeit, eigene erweiternde Header-Felder zu verwenden. Diese erweiternden Felder müssen das Präfix X- im Feldnamen tragen. Ein häufig anzutreffendes erweiterndes Feld ist z.B. X-Mailer, in welchem vermerkt wird, mit welcher Software das E-Mail erstellt worden ist. Naheliegenderweise können diese nicht-standardisierten, erweiternden Felder häufig nur von der einfügenden Software interpretiert werden und Fremdsoftware weiss damit oft nichts anzufangen.
In Feldnamen findet die Gross-/Kleinschreibung keine Beachtung. Es folgt eine kurze Vorstellung der Standard-Felder:

From
Das From Feld enthält in der Regel eine einzige Mailbox, welche die Person oder den Prozess identifiziert, welche(r) das E-Mail erstellt hat. Also z.B:
From: rodion@raskolnikow.ru
Obwohl selten angetroffen, ist im From Feld auch eine kommaseparierte Mailboxliste erlaubt:
From: rodion@raskolnikow.ru, dmitrij@rasumichin.ru
Enthält das From Feld mehr als eine Mailbox, so muss der Header zwingend ein Sender Feld enthalten.

Sender
Dieses Feld gibt den Versender eines E-Mails an. Es mag auf den ersten Blick redundant mit dem From Feld erscheinen. Der Versender einer Mitteilung braucht jedoch nicht zwangsläufig auch der Ersteller zu sein. So kann zum Beispiel eine Sekretärin im Auftrag und Namen ihres Chefs ein Mail versenden:
From: bond@secretservice.gov.uk
Sender: moneypenny@secretservice.gov.uk
Das Feld darf nur eine einzige Mailbox enthalten. Es ist ursprünglich dafür gedacht, am „Abgangsort“ und nicht durch nachfolgende Empfänger eingefügt zu werden. Einige Mailing Listen benutzen das Feld hingegen um anzuzeigen, dass das Mail durch eine Mailing Liste verteilt worden ist. Dabei handelt es sich jedoch technisch gesehen um ein regelwidriges Vorgehen, da es die Nutzung des Feldes zum ursprünglich vorgesehenen Zweck sabotiert.

Reply-To
In jenem Feld wird angegeben, wohin eine allfällige Antwort auf das betreffende Mail gesendet werden soll. Es wird häufig durch Benutzer mit mehreren Computern eingesetzt, welche die Antworten auf ihre E-Mails auf einem einzigen Computer erhalten möchten:
From: peter_parker@home.net
Reply-To: spiderman@savetheworld.com
Dem Feld wird beim Beantworten von Mails durch die meisten E-Mail Programme standardmässig Vorrang vor dem From Feld eingeräumt. Es wird häufig auch von Mailing Listen eingesetzt, um sicherzustellen, dass auch Antworten wieder über die Liste erfolgen und nicht direkt an den ursprünglichen Autor gehen. Das Feld darf, wie das From Feld, auch mehrere durch Komma getrennte Mailboxen enthalten.

Die Absenderangaben in E-Mails sorgen bei Empfängern immer wieder für Verwirrung: „Ich habe ein dubioses E-Mail von Tante Gertha erhalten, und die will sich nicht daran erinnern, ein  solches Mail geschickt zu haben.“ Hier hilft es, sich erneut die nicht-virtuelle Analogie vorzustellen: den papierenen Brief. Ich werde als normaler ehrlicher Mensch zwar mich selbst als Absender im Briefkopf vermerken, und nicht etwa meinen Cousin Alphons oder das Finanzamt. Es ist aber für jeden ohne Weiteres möglich, im Briefkopf einen anderen, falschen Absender anzugeben. Genau so ist es leicht möglich, die Angaben in den From, Sender und Reply-To Feldern zu fälschen. Das E-Mail muss also keinesfalls von Tante Gertha stammen, auch wenn ihre E-Mail Adresse im From Feld steht. Zuverlässigere Informationen über die Herkunft eines E-Mails lassen sich aus den Received Feldern heraus lesen. Dazu später mehr.

To
In jenem Feld stehen der oder die primäre(n) Empfänger des E-Mails. Also z.B.
To: alexej@karamasow.ru, dmitrij@karamasow.ru

Cc
Das Cc Feld dient der Angabe eines oder mehrerer sekundärer Empfänger. Das Cc steht für carbon copy (= Durchschlag). Die unter Cc aufgeführten Empfänger sollen die Mitteilung lediglich „zur Kenntnis“ erhalten. Von ihnen erwartet der Sender keine Reaktion.

Bcc
Steht für blind carbon copy (= versteckter Durchschlag) und hat eine ähnliche Funktion wie Cc, mit dem Unterschied, dass die unter To und Cc aufgeführten Empfänger die unter Bcc aufgeführten nicht sehen können.
Wie E-Mail Programme mit dem Feld umzugehen haben ist nicht sehr detailliert geregelt und lässt Raum für unterschiedliche Interpretationen. Dementsprechend finden sich unter den E-Mail Programmen die folgenden drei Vorgehensweisen:
a) Das E-Mail Programm merkt sich die Adressen im Bcc Feld und löscht dieses anschliessend. Es sendet nun das E-Mail ohne Bcc Feld an alle in den To, Cc und Bcc aufgeführten Empfänger einzeln.
b) Das E-Mail Programm löscht das Bcc Feld und sendet diese Version ohne Bcc Feld an alle in den To und Cc Feldern aufgeführten Empfänger. Anschliessend wird das komplette Mail inklusive Bcc Feld an alle im Bcc Feld aufgeführten Empfänger verschickt. Bei diesem Vorgehen kriegen somit alle Bcc Empfänger mit, welche anderen Bcc Empfänger das Mail auch erhalten haben.
c) Die dritte Möglichkeit ist eine Kombination der ersten beiden. Das E-Mail Programm sendet zuerst eine Version ohne Bcc Feld an alle in den To und Cc Feldern aufgeführten Empfänger. Anschliessend sendet es das Mail einzeln an alle im Bcc Feld aufgeführten Empfänger, wobei immer nur der jeweilige Empfänger im Bcc Feld aufgeführt wird.
Ähnlich wie bei den Absenderangaben kommt es auch bei Empfängerangaben immer wieder zu Verwirrung und erstaunten Fragen, gerade bei Spam und von Viren versandten E-Mails: „Wie konnte dieses E-Mail zu mir gelangen, wo meine E-Mail Adresse doch in den To, Cc und Bcc Feldern nirgendwo vermerkt ist?“ Auch hier hilft es wieder, sich den Papierbrief vorzustellen. Wenn ich einen Brief an Tante Gertha schreibe, dann werde ich als höflicher junger Mann selbstverständlich oben in meinem Brief gemäss den üblichen Gepflogenheiten die Anschrift von Tante Gertha vermerken. Auf die Zustellung des Briefes hat diese Angabe jedoch keinen Einfluss (ausser natürlich, wenn ich einen Fensterumschlag verwenden würde). Vermerke ich auf dem Umschlag die Anschrift von Onkel Zülfü, dann geht der Brief an Onkel Zülfü, und nicht an Tante Gertha, obwohl ich auf dem eigentlichen Brief die Anschrift von Tante Gertha vermerkt habe. Genau so verhält es sich auch bei E-Mail. Aber mehr zum Umschlag gibts im dritten Teil.

Message-ID
Das Message-ID Feld enthält eine Kennung, welche das betreffende E-Mail eindeutig identifiziert, z.B:
Message-ID: <20060122130128.8913.qmail@serv20.anyhoster.de>

In-Reply-To
Das In-Reply-To Feld enthält Informationen zum Identifizieren jener Mitteilung, auf welche mit dem betreffenden Mail geantwortet wird. Es dient den Mail-Programmen zusammen mit dem References Feld zur baumartigen Darstellung von Konversationssträngen. Die Syntax kann (theoretisch) unterschiedlich aussehen, wobei mir die zweite und dritte Variante in der Realität noch nie unter die Augen gekommen ist:
In-Reply-To: <20060122130128.8913.qmail@serv20.anyhoster.de>
In-Reply-To: Your message of „Sun, 07 Mar 1999 10:23:23 -0700.“ <20060122130128.8913.qmail@serv20.anyhoster.de>
In-Reply-To: Joe‘s message of Sun, 07 Mar 1999 10:23:23 -0700

References
Dieses Feld dient als Ergänzung zum In-Reply-To Feld. Es führt nicht nur die Mitteilung auf, auf die unmittelbar geantwortet wird, sondern alle vorangegangenen Mails eines Diskussionsstranges:
In-Reply-To: <06AC49D2-4EC2-4C19-877C-E4A7D59F78D7@spray.se>
References: <082B0B84-285C-4985-B1E2-92BC96B047E7@spray.se>
   <abd4da256bad2e736b5cb5774ebfbd07@physics.uc.edu>
   <F6EE2BEC-A031-4F5D-9297-90EEFE001A2D@spray.se>
   <06AC49D2-4EC2-4C19-877C-E4A7D59F78D7@spray.se>

Date
Enthält das Datum und die Zeit wann das E-Mail erstellt worden ist. Vereinzelt gibt es Software, welche darin Datum und Zeit vermerkt, wann das E-Mail verschickt worden ist. Dieses Vorgehen ist allerdings nicht regelkonform.

Received
Vertiefter auf diese Felder kommen wir im dritten Teil zu sprechen. Vorläufig können wir uns die Received Felder als etwas wie einen Poststempel auf unserem elektronischen Brief vorstellen. Im Unterschied zu einem papierenen Brief,  auf welchem nur jenes Postamt seinen Stempel anbringt, das den Brief vom Absender entgegen nimmt, bringt auf unserem elektronischen Brief jedes „Postamt“ (= SMTP Server), bei welchem das Mail vorbei kommt, ein solches Feld und damit seinen virtuellen Stempel an.

Return-Path
Auch bei diesem Feld hängen wir ohne die Kenntnisse aus dem dritten Teil noch etwas in der Luft. Es wird erst vom letzten „Postamt“ in das E-Mail eingefügt, welches darin den auf dem Umschlag angegebenen Absender vermerkt.

Subject
Beinhaltet den Betreff, also eine kurze Beschreibung, worum es im E-Mail geht. Es darf alle 7-Bit Zeichen enthalten, inklusive einzelne CR und LF. Die CRLF Kombination ist hingegen nicht erlaubt. (Bezüglich 8-Bit Zeichen und Kodierung im Betreff siehe weiter unten folgenden Abschnitt über „MIME und Header“.)

Comments
Diese Feld findet relativ selten Verwendung. Es erlaubt das Hinzufügen eines beliebigen Kommentars zu einer E-Mail Mitteilung. Bei verschlüsselten E-Mail wird es mitunter dazu genutzt anzugeben, wo der öffentliche Schlüssel des Absenders erhältlich ist:
Comments: Public Key at http://beispiel.de/~bob/public-key.pgp

Keywords
Dieses Feld würde es erlauben, einem E-Mail Schlüsselwörter zuzuordnen, die zum Beispiel für themenspezifische Suchen verwendet werden können. Das Feld wird hingegen kaum benutzt.

Encrypted
Dieses Feld wurde zwar einst definiert. Es hat jedoch nie wirklich seinen Einsatz gefunden und gilt heute als „veraltet“. Es findet, auch bei verschlüsselten E-Mails, keine Verwendung.

Resent-*
Von den From, Sender, To, Cc, Bcc, Date, Message-ID und Reply-To Feldern existieren zusätzlich Varianten, welche bei einem „Zweitversand“ (resend - was nicht einer Weiterleitung = forward entspricht) eingefügt werden: Resent-From, Resent-Sender usw. Bei diesem Resend-Vorgang bleibt, abgesehen davon, dass diese Resent- Felder eingefügt werden, der gesamte Rest des E-Mails unverändert.

Wie wir gesehen haben, beinhaltet eine Reihe der nun vorgstellten Header Felder E-Mail Adressen. Unerwähnt blieb bisher, was das genau ist und wie sie auszusehen haben. Schauen wir uns daher die E-Mail Adressen noch etwas genauer an. Primär wird zwischen zwei Arten von E-Mail Adressen unterschieden: Mailboxen und Gruppenlisten.
Mit der ersten Art, den Mailboxen, sind die meisten Benutzer vertraut. Es existieren zwei Untervarianten: Einfache Adressen und Routing-Adressen. Eine einfache Adresse setzt sich wie folgt zusammen: lokalteil @ domain
Der Lokalteil kann aus einem oder mehreren sogenannten Atoms (beliebige Folgen beliebiger Zeichen, jedoch keine Sonder- und Leerzeichen enthaltend) oder in Anführungszeichen gesetzten Zeichenketten bestehen. Der grösste Teil der E-Mail Adressen besteht aus durch Punkte separierten Atoms, z.B. steve@apple.com oder bill.gates@microsoft.com. Möglich sind aber auch Adressen wie „Emile M.Cioran“@penseur.fr. Gemäss dem Standard würde im Lokalteil die Gross-/Kleinschreibung eigentlich eine Rolle spielen und demnach bob@example.com nicht identisch sein mit Bob@example.com. In der Realität wird die Gross-/Kleinschreibung jedoch von fast ausnahmslos aller E-Mail Software ignoriert. Der Domain Teil wird meist als ausgeschriebener Domainname (Full Qualified Domain Name; FQDN) angegeben, der aus durch Punkte separierten Atoms besteht: tuba.orchestra.com oder cello.org. In Ausnahmefällen möglich ist (oder wäre) gemäss Standard jedoch auch die Angabe einer „aufgelösten“ Domain in eckigen Klammern, was sich z.B. so präsentieren kann: info@[80.67.17.24]. Diese Form der Domain Angabe funktioniert im heutigen Internet Umfeld jedoch kaum noch richtig.
Die zweite Art zur Angabe einer Mailbox ist die Routing-Adresse. Sie steht zwischen <> Zeichen und wurde eigentlich dazu geschaffen, um den genauen Weg eines E-Mails vorzugeben. Eine Routing-Adresse mit Routing Angaben sähe Beispielsweise wie folgt aus: <@c.beispiel.de,@b.beispiel.de,@a.beispiel.de:guido@a.beispiel.de>. Routing Angaben werden jedoch von einem Grossteil der E-Mail Software nicht wirklich ausgewertet und sollten vermieden werden. Dennoch finden Routing-Adressen recht häufig Verwendung, allerdings ohne Routing Angaben. Sie haben nämlich den Vorteil, dass es erlaubt ist, ihnen eine beliebige Phrase voranzustellen. Das wird häufig dazu genutzt, um der E-Mail Adresse den Namen des Adressinhabers in zur menschlichen Lektüre bestimmter Form voranzustellen. So begegnen wir recht häufig solchen Adressangaben: Dirk Diggler <dirk@beispiel.de> oder „Jack Bauer“ <jack@twentyfour.com>.
Mailboxen bezeichnen jeweils einen einzelnen Empfänger. Die zweite Variante der Adressangabe, die Gruppenlisten, ermöglichen es, mehrere Empfänger als eine Einheit zu behandeln. Eine Gruppenliste besteht aus einem Gruppennamen und einer zwischen : und ; Zeichen gesetzten Liste von Mailboxen, z.B:
To: Black and White Team: laurel@doof.de, hardy@dick.de;
Gruppenlisten werden höchst selten zu ihrem eigentlichen Zweck eingesetzt. Viel häufiger begegnen wir ihnen, wenn es darum geht, die Empfänger einer Nachricht zu verbergen. Bei diesem Einsatz der Gruppenlisten macht man es sich zu Nutzen, dass der Teil zwischen den : und ; Zeichen optional ist. So ist das folgende Beispiel eine gültige Gruppenliste:
To: Undisclosed-Recipients:;
Und genau dieser Gruppenliste begegnen wir ab und zu. Sie wird von vielen E-Mail Programmen automatisch eingefügt, wenn wir ein E-Mail erstellen, das nur im Bcc Feld Adressen enthält. Wir erinnern uns, ein gültiges E-Mail muss mindestens ein To, Cc oder Bcc Feld enthalten. Das Bcc Feld wird aber, wie wir ebenfalls gesehen haben, in der Regel vom versendenden Programm sogleich wieder gelöscht. Ein E-Mail ohne To und Cc wäre fortan also ohne To, Cc und Bcc Feld unterwegs und würde somit die Standards verletzen. Zu diesem Zweck fügen viele Programme ein To Feld mit einer leeren Gruppenliste ein. (Einen echten Nutzen, ausser eben, dass das E-Mail wieder standardkonform wird, bringt dies natürlich nicht.)

MIME und Header
Die im ersten Teil über den Mail Body behandelten MIME-Erweiterungen haben in zweierlei Hinsicht Auswirkungen auf den Header eines E-Mails. Zum einen ermöglichen die Erweiterungen in beschränktem Ausmass auch im Header ein Ausbrechen aus der 7-Bit Limitierung, zum anderen fügen sie weitere Felder in den Header ein. Möglich ist im Header die Q Kodierung (eine Variante der quoted-printable Kodierung)  und die B Kodierung (die base64 nutzt). Erlaubt ist sie primär an folgenden Orten: in den Subject und Comments Standard-Feldern sowie in allen erweiternden Feldern (X-); weiter möglich ist sie im beigestellten Namen (Phrase) einer Routing-Adresse, im Gruppennamen einer Gruppenliste, im Keywords und im In-Reply-To Feld. Entsprechende Beispiele mit der jeweiligen dekodierten Auflösung:

Subject: =?iso-8859-1?q?J=FCrgens?= Einladung
Subject: Jürgens Einladung

From: =?iso-8859-1?q?J=FCrgen Muster?= <juergen@muster.de>
From: Jürgen Muster <juergen@muster.de>

To: =?iso-8859-1?q?J=FCrgens?= Witzliste:;
To: Jürgens Witzliste:;

Keywords: =?iso-8859-1?q?B=F6hser?= Junge
Keywords: Böhser Junge

X-Stuff: =?us-ascii?b?SW50ZXJuZXQgRW1haWw=?=
X-Stuff: Internet Email

Nutzt ein E-Mail Programm beim Erstellen von E-Mails die MIME-Erweiterungen, dann fügt es folgende Header Felder ein, um dem empfangenden Programm wichtige Informationen für die Dekodierung mitzuteilen.

MIME-Version
Dies ist das einzige obligatorische MIME Header Feld. Es muss also zwingend im Header eines E-Mails vorhanden sein muss, wenn im E-Mail MIME Kapselung zum Einsatz gelangt. Es gibt die Version der MIME-Erweiterungen an. Gegenwärtig gibt es nur eine Version:
MIME-Version: 1.0

Content-Type
In diesem Feld wird der MIME-Medientyp der Daten deklariert, die in der MIME-Kapsel enthalten sind. Je nach Medientyp kann das Feld neben der Bezeichnung des Medientyps auch noch zusätzliche Parameter enthalten. Beispiele:
Content-Type: text/plain
Content-Type: text/plain; charset=“us-ascii“
Content-Type: message/external-body;
            access-type=mail-server; server=“lists@beispiel.de“

Content-Transfer-Encoding
In diesem Feld wird die verwendete Kodierungsart (zur Erinnerung: 7bit, 8bit, Binary, Base64 und Quoted-Printable) angegeben.
Content-ID
Dient dazu, der MIME Kapsel eine eindeutige ID zuzuweisen, ähnlich wie das Feld Message-ID der eindeutigen Identifizierung von ganzen Mail Mitteilungen dient.

Content-Description
Das Feld erlaubt, der MIME Kapsel Erläuterungen beizufügen, falls sich der Inhalt dem Empfänger nicht von selbst erschliesst.

Content-Disposition
Mit diesem Feld lässt sich bestimmen, ob die in der MIME-Kapsel enthaltenen Daten bevorzugt direkt in der Textabfolge, also "inline", dargestellt werden sollen (kann z.B. bei Grafiken sinnvoll sein) oder als "angehängtes" Icon (attachment). Beispiele:
Content-Disposition: inline
Content-Disposition: attachment; filename=wuw.pdf

Content-MD5
In diesem Feld kann ein mit dem MD5 Algorithmus (Message Digest Algorithm 5) generierter Hash (Prüfsumme) der in der MIME-Kapsel enthaltenen Daten mitgeschickt werden. Anhand dieser Prüfsumme kann das empfangende Programm die Integrität der Daten überprüfen und allfällige auf dem Transport entstandene unbeabsichtigte Schäden und Datenveränderungen feststellen. (Aber Vorsicht, es dient nicht zum Entdecken oder Verhindern von Veränderungen, die mit Absicht vorgenommen werden.)

Content-Language
In diesem Feld kann die (menschliche) Sprache angegeben werden, in welcher die Informationen der in der MIME-Kapsel enthaltenen Daten gehalten sind. Dies können gleichzeitig mehrere Sprachen sein. Beispiele:
Content-Language: de
Content-Language: en, fr
Content-Language: i-navaho, en-US
Content-Language: de-CH 
« Letzte Änderung: April 22, 2006, 14:25:18 von warlord »
_______
Complete liberty of contradicting and disproving our opinion, is the very condition which justifies us in assuming its truth for purposes of action; and on no other terms can a being with human faculties have any rational assurance of being right. (John Stuart Mill - On Liberty)
Re: [Vorschlag] E-Mail, das unbekannte Bekannte
Antwort #3: April 17, 2006, 23:53:48
Das Envelope

Am Betrieb des Internet Dienstes E-Mail sind drei verschiedene "Arten" von Software beteiligt. Die Fachleute sprechen von drei verschiedenen Agenten, oder eben auf Englisch von Agents: da gibt es den Mail User Agent (MUA), den Mail Transfer Agent (MTA) und den Mail Delivery Agent (MDA).
Allerdings ist diese Dreiteilung der Funktionalität etwas theoretisch. Real existierende Software beinhaltet meist die Funktionalität von zwei Agents. So muss unsere E-Mail Software auf unserem Mac sowohl die Aufgaben eines MUA, wie auch die eines MTA beherrschen. Und die bei den Providern eingesetzte Mail Server Software kombiniert meist die Funktionalität eines MTA und MDA in einer einzigen Software. Etwas vereinfacht wird daher häufig (auch hier nachfolgend) bei clientseitiger Software von einem Mail User Agent (MUA) und bei serverseitiger Software von einem Mail Transfer Agent (MTA) gesprochen.

Der Transport eines E-Mails vom erstellenden MUA über (allenfalls mehrere) MTA bis ins Postfach des Empfängers erfolgt mit dem SMTP Protokoll (Simply Mail Transfer Protocol). (Einzig den letzten Teil seiner Reise, nämlich vom Postfach in den MUA des Empfängers, absolviert ein Mail nicht mit SMTP, sondern mit POP oder IMAP. Diese beiden Protokolle sind jedoch nicht Gegenstand dieses Artikels.) Bei SMTP handelt es sich um ein sogenanntes "store-and-forward" Protokoll. Das heisst, das Mail kann bis zu seiner Zustellung ins Bestimmungs-Postfach eine ganze Kette von Servern durchreisen. Jeder dieser Server speichert das eingegangene Mail in einer Art Warteschlange, in welcher es die Versuche des Servers abwartet, das Mail an den nächsten Server weiter zu reichen. Gelingt dies nicht sofort, weil der nächste Server nicht erreichbar oder überlastet ist, verbleibt das Mail in dieser Warteschlange, bis der nächste Server wieder erreichbar ist und das Mail an ihn weiter gereicht werden kann. (Wobei natürlich kein Mail ewig in der Warteschlange verbleibt. Nach einer gewissen Zeit gibt ein Server seine Versuche auf, das Mail an den nächsten Server weiter zu reichen. Diese Zeitspanne ist unterschiedlich und hängt von der Konfiguration des Servers ab. Sie beträgt aber meistens mehrere Tage.)
Ein Server (sowie auch unser eigenes E-Mail Programm) "verpackt" ein Mail für den Transfer zum nächsten Server in ein Envelope, vergleichbar mit einem Umschlag bei einem papierenen Brief. Wie auch beim papierenen Brief trägt bei der elektronischen Post dieses Envelope die für die Beförderung und Zustellung notwendigen und massgeblichen Absender- und Bestimmungsangaben. Entsprechende Angaben im Brief bzw. im E-Mail selbst haben auf die Zustellung keinen Einfluss. So wird insbesondere das To Feld in einem Mail Header von einem MTA nicht beachtet.

Eine detaillierte Beschreibung von SMTP würde den Rahmen dieses Artikels sprengen. Wir schauen uns nun aber in stark vereinfachter Form an, wie unser E-Mail Programm das von uns erstellte Mail an den SMTP-Server unseres Providers weiterleitet, nachdem wir auf den "Senden" Knopf gedrückt haben. Praktisch das selbe wird dann auch der SMTP-Server des Providers tun, um das Mail an die nächste Station weiter zu reichen. Der Server muss sich einfach im Gegensatz zu unserem E-Mail Programm, das sich immer nur an "seinen" immer gleichen Server zu wenden braucht, zusätzlich noch "Gedanken" darüber machen, an welchen Server es das Mail weiterreichen muss. Dieser Prozess liegt jedoch definitiv jenseits des Rahmens dieses Artikels.
SMTP ist ein text-orientiertes, kommando-basiertes Protokoll. Der Client sendet ein Kommando, der Server verarbeitet es und sendet dann seine Antwort. Die Antwort des Servers besteht aus einem maschinenlesbaren Code aus 3 Ziffern und einem zur menschlichen Lektüre bestimmten ergänzenden Kommentar:
250 Requested mail action okay, completed
Die erste Ziffer des Antwortcodes gibt dabei letztlich über Erfolg oder Misserfolg Auskunft: 1 steht für eine vorläufige positive Antwort, 2 für eine definitiv positive Antwort (Aktion ausgeführt), 3 für einen positiven Zwischenbericht, 4 für einen negativen Zwischenbericht (Server probiert weiter) und 5 für eine definitive negative Antwort (Server hat aufgegeben).

Nach dem Drücken des "Senden" Knopfes kontaktiert unser E-Mail Programm den eingestellten SMTP-Server unseres Providers (in der Regel) auf TCP Port 25. Ist der Server zur Erbringung seiner Dienste bereit, antwortet er mit einer Begrüssung, in welcher er sich selbst vorstellt:
220 smtp.beispiel.de Service ready
Unser E-Mail Programm sendet nun seinerseits eine Begrüssung, in welcher es sich vorstellt:
helo 1-1-168-192.beispiel.de
Der Server quittiert:
250 smtp.beispiel.de
Unser E-Mail Programm muss nun mit dem Befehl mail den ersten Teil des Envelopes übertragen, nämlich die Absenderangaben:
mail from:<john.doe@beispiel.de>
Diese Angabe entnimmt es in der Regel dem From Feld im Header bzw. den Einstellungen, die wir für den betreffenden Mail Account gemacht haben. An die hier angegebene Adresse werden Probleme bei der Zustellung zurück gemeldet. (Ein Programm zum Versenden von Spam verhält sich natürlich etwas anders. Es wird hier in der Regel nicht die Adresse des tatsächlichen Absenders, sondern eine fremde oder nicht existierende Adresse eintragen.)
Ist der Server bereit, Mails von diesem Benutzer entgegen zu nehmen, antwortet er:
250 ok
Nun muss unser E-Mail Programm mit dem Befehl rcpt den zweiten Teil des Envelopes, nämlich die Bestimmungsangaben übermitteln:
rcpt to:<steve@apple.com>
Der Server bestätigt:
250 ok
Unser E-Mail Programm wiederholt den Befehl nun für jeden Empfänger, an den das Mail geschickt werden soll. Die Empfängerangaben übernimmt unser E-Mail Programm logischerweise aus den von uns ausgefüllten Headerfeldern To, Cc und Bcc. (Auch hier verhält sich ein Programm zum Versenden von Spam oder auch ein sich selbst reproduzierender Virus etwas anders. Diese entnehmen die Adressaten ihren Datenbanken und angefertigten Listen und die Angaben im Mail Header stimmen häufig nicht damit überein.) Gemäss Standard muss ein SMTP-Server in seinem forward-path mindestens 100 Mailboxen speichern können. Somit müsste der rcpt Befehl bei Bedarf mindestens 100 mal wiederholt werden können. Allerdings verletzen viele Provider diesen Standard und beschränken den forward-path und damit die gleichzeitig mögliche Anzahl Empfänger auf weniger als 100. Ein MUA müsste in solchen Fällen den Versand auf mehrere SMTP Sessions aufteilen, was die meisten normalen (nicht auf Serienversand spezialisierten) MUA überfordert.
Sind alle Empfänger übermittelt, teilt unser E-Mail Programm dem Server mit dem Befehl data mit, dass es nun das eigentliche Mail (inkl. Header) senden möchte:
data
Der Server antwortet darauf:
354 Start mail input; end with >CRLF>.<CRLF>
Nun kann unser MUA das eigentliche Mail übermitteln. Das Ende der Übermittlung zeigt es mit einem einzigen Punkt auf einer Zeile an. Der Server quittiert sodann:
250 ok
Das Ende der Session zeigt unser E-Mail Programm mit dem Befehl quit an:
quit
Der Server quittiert und bricht die Verbindung ab:
221 smtp.beispiel.de Service closing transmission channel

Was der Server nun tut, unterscheidet sich (hoffentlich  ;) ) von dem, was die Post bei papierenen Briefen tut. Der Server "öffnet" nämlich das Envelope und "entnimmt" ihm das darin enthaltene Mail. Mehr noch, er fügt dem Mail sogar etwas hinzu. Wir haben im Abschnitt über den Header bereits kurz die Received Felder kennen gelernt. Der Server fügt nun im Header des E-Mails ein solches Received Feld ein, in welchem er seine Behandlung des Mails protokolliert. Das schaut zum Beispiel so aus:
Received: from smtp.beispiel.de by smtp.apple.com with SMTP id HAA197482 for <steve@apple.com>; Mon, 4 Oct 1999 08:33:45 -0700
Jeder MTA, welcher das E-Mail entgegen nimmt, muss im Header ein solches Feld einfügen. Und da diese Felder für die Diagnose von E-Mail Problemen meist der wichtigste Ansatzpunkt sind, werden wir uns gleich noch etwas intensiver damit beschäftigen.
Befindet sich das Postfach des Empfänger nicht auf dem Server, so "verpackt" er das mit einem Received Feld ergänzte Mail wieder in ein Envelope und reicht es an den nächsten Server weiter. Befindet sich das Postfach auf dem Server (bzw. verlässt das Mail aus einem anderen Grund die SMTP-Welt), so fügt jener dem Header des Mails ein weiteres Feld bei:
Return-Path: <john.doe@beispiel.de>
Darin gibt der Server die auf dem Envelope angegebene Absenderadresse (also die im SMTP mail Befehl angegebene Adresse; mail from:<john.doe@beispiel.de) an. Anschliessend legt der Server das Mail ohne das Envelope ins Postfach des Empfängers.
 
Daraus ergibt sich, was viele Benutzer immer wieder verwirrt: das Envelope, den Umschlag, der die Angaben über Absender und vor allem Empfänger enthält, kriegt ein Benutzer gar nie zu Gesicht. Hingegen sind die dort vermerkten Absenderangaben in der Regel im Return-Path Feld ersichtlich. Die Empfängerangaben sind für den Endempfänger nicht mehr ersichtlich. Eines ist jedoch klar, mindestens unsere korrekte E-Mail Adresse muss da vermerkt gewesen sein, sonst wäre das Mail nicht in unserem Postfach gelandet.

Die Received Felder
Diese Felder verdienen eine spezielle Aufmerksamkeit, weil sie meist die einzigen Anhaltspunkte bezüglich Herkunft, eingeschlagenenem Weg und allfälligen Zustellproblemen sind. Das Feld kann folgende Unterfelder enthalten: from, by, via, with, id, for und die Zeit und das Datum. Ausser Zeit und Datum sind alle Unterfelder optional, müssen also nicht zwingend enthalten sein. Schauen wir sie uns etwas näher an:

From
Dieses Unterfeld enthält den Namen des übergebenden (sendenden) Computers. Dabei wird jener Name übernommen, mit welchem sich der Computer im helo SMTP Befehl vorgestellt hat. Die meisten MTA fügen jedoch in Klammern noch zusätzliche Informationen, wie die IP Adresse und das Resultat eines damit vorgenommenen DNS Lookups, ein:
from 1-1-168-192.beispiel.de (1-1-168-192.beispiel.de [192.168.1.1])
Diese zusätzlichen Angaben können beim Aufspüren und Beheben von E-Mail Problemen sehr hilfreich und nützlich sein.

By
Gibt den Namen des empfangenden Computers an. (Er ist also derjenige, welcher das betreffende Received Feld eingefügt hat.)

Via
Dieses Unterfeld war ursprünglich dafür vorgesehen, das physikalische Netz zu bezeichnen, über welches die Übermittlung erfolgt, z.B. ARPANET oder Phonenet. Im heutigen Internet wäre UUCP eigentlich der einzige gültige Wert für dieses Unterfeld. Wenn es denn überhaupt Verwendung findet, wird es heute jedoch meist zur Angabe der verwendeten Serversoftware genutzt.

With
Gibt das verwendete Protokoll an, das für die Übermittlung zwischen den zwei Computern verwendet worden ist. Das wird also meist SMTP bzw. ESMTP sein.

Id
Enthält eine eindeutige Bezeichnung, welche der MTA dem Mail zugeordnet hat. Die Information kann nützlich sein, da die meisten MTAs Logdateien führen und es diese ID somit erlaubt, das Mail den Logeinträgen zuzuordnen.

For
In diesem Unterfeld wird (bzw. werden) die im (in den) rcpt SMTP Befehl(en) angegebene(n) Empfängeradresse(n) aufgeführt.

Häufig fügen MTAs zudem als Kommentar in Klammern noch weitere Informationen ein, die bei der Analyse von Problemen hilfreich sein können.

Wozu können die Informationen in den Received Felder dienlich sein? Zum einen können sie bei der Aufklärung von Zustellverzögerungen hilfreich sein. Nehmen wir als Beispiel an, wir würden uns darüber wundern, dass E-Mails von einer bestimmten Stelle immer ausserordentlich lange benötigen, um bei uns anzukommen. Da die Received Felder jeweils einen „Zeitstempel“ enthalten, dürften wir darin ein paar Antworten auf unsere Fragen finden. Unser angenommenes Beispiel enthält vier Received Felder von den folgenden Maschinen mit den jeweilen Zeitstempeln:

oboe.beispiel.de   Mon, 17 Apr 2006 12:56:24 -0000
tuba.beispiel.de   Mon, 17 Apr 2006 12:51:02 -0000
exthub.beispiel.de   Sun, 16 Apr 2006 06:26:41 -0000
wilber.extern.de   Sun, 16 Apr 2006 06:25:10 -0000

Die Zeitspanne zwischen unseren beiden Maschinen exthub und tuba war also weitaus am Grössten. Das heisst, wir müssten nun bei unserer Suche nach den möglichen Ursachen der Verzögerungen primär diese beiden Maschinen näher unter die Lupe nehmen.
Allerdings gilt es bei solchen Analysen immer zu berücksichtigen, dass es keine Garantie gibt, dass die Zeitstempel auch tatsächlich korrekt sind. Es kann durchaus sein, dass auf einem Server die Zeit und oder die Zeitzone nicht korrekt eingestellt ist und das Gerät somit irreführende Zeitstempel anbringt.

Weiter können die Received Felder Hinweise auf E-Mail Spoofing geben. Der Internet Dienst E-Mail beinhaltet keine eingebaute Authentifizierung. Wie wir schon gesehen haben, ist es somit möglich, die Absenderangaben in E-Mails beliebig zu fälschen. Man nennt dies Spoofing. Trivialere (und damit die meistens verwendeten) Spoofing Techniken können anhand der Received Felder erkannt werden. Nehmen wir z.B. an, der Header eines erhaltenen E-Mails beinhalte die folgenden Felder:

Received: from ictus.beispiel.de (ictus.beispiel.de [10.2.3.1]) by tuba.beispiel.de
        with ESMTP id BAA64342 for <bob@tuba.beispiel.de>; Sun, 16 Apr 2006 12:13:14 -0000
Received: from bells.beispiel.de (bubezleeb@heim13.unixy.de) by ictus.beispiel.de
        id DAA45365; Sun, 16 Apr 2006 12:12:50 -0000

Interessant sind hier die vom MTA zusätzlich eingefügten Angaben in Klammern. Im oberen Received Feld wurde zusätzlich die IP Adresse der sendenden Maschine und deren (Reverse-) DNS Auflösung eingefügt. Diese Informationen in den Klammern stimmen mit den im helo Befehl gemachten Angaben überein. Hier scheint somit alles in Ordnung zu sein.
Eine etwas andere Geschichte sind die Angaben im unteren Received Feld. Hier hatte der einfügende Server (ictus.beispiel.de) ein anderes Bild von der sendenden Maschine, als ihm im helo Befehl präsentiert worden war. Ein Indiz dafür, dass hier etwas faul sein könnte.
Beim unteren Received Feld fällt auf, dass der in Klammer eingefügte Hostname eher wie eine E-Mail Adresse aussieht. Das ist ein Hinweis darauf, dass hier das ident Protokoll benutzt wurde, das dazu dient, den Benutzernamen auf der anderen Seite der Verbindung herauszufinden. Es ist eher selten implementiert. In unserem Beispiel war es allerdings implementiert und die dadurch gewonnenen Informationen bestätigen die Wahrscheinlichkeit, dass es sich um Spoofing handelt.

Sind in den Received Feldern die Unterfelder from und by jeweils vorhanden, dann müssten diese Angaben eigentlich eine konsistente ununterbrochene Kette bilden. D.h. die Maschine im by Unterfeld des ersten (untersten) Received Feldes müsste im from Unterfeld des zweiten Received Feldes erscheinen, die Maschine im by Unterfeld des zweiten Received Feldes im from Unterfeld des dritten Received Feldes usw. Gibt es Lücken in dieser Kette, ist dies ein Indiz dafür, dass zusätzliche unechte Received Felder eingefügt worden sind, um die Herkunft des Mails zu verschleiern. Nachfolgend ein (real existierendes) Beispiel aus meinem Spam Mail Ordner:

Received: (qmail 98205 invoked from network); 16 Apr 2006 02:45:26 -0000
Received: from unknown (HELO t-online.de) (66.10.10.146)
  by warlord.li with SMTP; 16 Apr 2006 02:45:26 -0000
Received: from unknown (32.33.11.32)
   by mail.naihautsui.co.kr with ASMTP; Sat, 15 Apr 2006 17:30:17 -1000
Received: from 128.80.13.212 ([128.80.13.212]) by mtu23.bigping.com with ESMTP; Sat, 15 Apr 2006 17:17:16 -1000
Received: from unknown (HELO qnx.mdrost.com) (74.44.127.221)
   by rly04.hottestmile.com with ASMTP; Sat, 15 Apr 2006 17:05:39 -1000
Received: from 23.130.108.157 ([23.130.108.157]) by snmp.otwaloow.com with QMQP; Sat, 15 Apr 2006 16:49:55 -1000
Received: from unknown (HELO nntp.pinxodet.net) (53.8.27.146)
   by smtp.mixedthings.net with ESMTP; Sat, 15 Apr 2006 16:40:54 -1000

Der Absender dieses Mails hat sich offensichtlich die Mühe gemacht, sich fünf Received Felder aus dem Finger zu saugen und in sein Mail einzufügen. Allzu grosses Geschick hat er dabei allerdings nicht bewiesen. Nach der Lektüre des Artikels fallen uns da doch zumindest einige der vielen Fehler auf, die ihm unterlaufen sind (wenn er damit denn wirklich die Herkunft zu verschleiern versucht hat), oder?
_______
Complete liberty of contradicting and disproving our opinion, is the very condition which justifies us in assuming its truth for purposes of action; and on no other terms can a being with human faculties have any rational assurance of being right. (John Stuart Mill - On Liberty)