Suche

E-Mail Details

Eine E-Mail besteht aus zwei Teilen, dem was die Person nachher im Postfach bekommt und einem sogenannten Umschlag (wie bei einem Brief) der zum Transport der E-Mail wichtig ist.

Die eigentliche E-Mail besteht wiederum aus zwei Teilen, die getrennt betrachtet werden müssen: Dem Kopf einer E-Mail und dem Nachrichtenteil.

Also besteht eine E-Mail aus insgesamt drei Teilen:

  • Envelope (Umschlag) der wenige Informationen zum Transport beinhaltet (From, To, Message-ID)
  • E-Mail-Header (Kopf) der u.a. die menschenlesbaren Infomationen die Absendeadresse, Zieladresse, Betreff etc. beinhaltet
  • E-Mail-Message (Nachricht) die den eigentlichen Inhalt einer E-Mail beinhaltet

Envelope (Umschlag)

Der Envelope einer E-Mail wird benötigt um eine E-Mail eindeutig zu identifizieren, und um deren Absende- und Empfangsadresse zu definieren.

Die eindeutige Identifikation erfolgt durch eine sogenannte "Message-ID" die auch im E-Mail-Header verzeichnet ist, dient zum einen den Weg einer E-Mail bei komplexeren Systemen eindeutig nachzuvoll ziehen. Zum anderen reagieren auch manche Postfachserver darauf, wenn mehrfach eine E-Mail mit gleicher Message-ID eintrifft nur eine zuzustellen. deswegen sollte eine Message-ID möglichst auch eindeutig sein.

Die Absendeadresse wird benutzt wenn eine E-Mail Probleme der Zustellung hat (Postfach voll oder Empfangsadresse nicht gültig oder erreichbar). Dann wird die E-Mail wieder an die Absendeadresse zurück gesendet. Daher muss die Absendeadresse immer valide und erreichbar sein.
Die Absendeadresse kann eine andere sein, als die Absendeadresse die im E-Mail-Header zu sehen ist. Bei E-Mailprogrammen ist diese identisch. Aber bei anderen Systemen ist es manchmal praktisch, wenn diese nicht identisch ist, sondern man - z.b. bei Massenmails - diese Envelope-From-Adresse anders setzt, damit man bei technischen Rückläufern diese in ein anderes Postfach leitet.

Die Empfangsadresse ist in der Regel immer identisch wie im E-Mail-Header die "To"-Adresse(n). Außer bei BCC: Hier wird beim Envelope auch die Zieladresse der BCC-Adresse angegeben, aber im E-Mail-Header wird die BCC-Adresse nirgends verzeichnet. Daher sieht auch keine andere Person wem man noch die E-Mail mittels BCC (BlindCarbonCopy) angeschrieben hat.
Auch hier sollte die Adresse natürlich valide sein, aber da diese schwieriger zu prüfen ist, kann es also sein, dass manche E-Mail als nicht zustellbar an die Absendeadresse zurück gehen muss.

Der Envelope wird nur so lange beibehalten, bis eine E-Mail zum Zielserver (Postfachserver) kommt. Dort wird diese in das Postfach eingeliefert und der Umschlag weggeworfen.

E-Mail-Header

Der E-Mail-Header ist in jeder E-Mail vorhanden, wird aber von allen E-Mailprogrammen mehr oder weniger verstckt, da hier zahlreiche Informationen sind, die für normale Anwender:innen kaum zu interpretieren sind. Unter Kopfzeilen sichtbar machen kann man nachlesen wie man diese sich anzeigen lassen kann.

Alle Informationen des E-Mail-Header werden zeilenweise angegeben. Ist eine Zeile zu lang, wird diese umgebrochen, aber die nächste Zeile beginnt mit mindestens einem Leerzeichen. D.h. eine neue Zeile fängt erst mit einem Zeichen an der ersten Stelle an. Als erstes erfolgt der Feldname (wie Subject) und dann ein Doppelpunkt. Dahinter der Inhalt des Feldes.
Die erste leere Zeile trennt den E-Mail-Header von der E-Mail-Message.

Wichtig ist hierbei, dass alle Zeilen eines E-Mail-Headers gefälscht sein können!

In einer Kopfzeile sind u.a. folgende Informationen vorhanden:

  • From (Von): beinhaltet die Absendeadresse
  • To (Zu): beinhaltet die Empfangsadresse(n)
  • Subject (Betreff): der Betreff einer E-Mail
  • Date (Datum): Datum und Uhrzet wann die E-Mail gesendet wurde (meist in internationalen Format)
  • Message-ID
  • Reply-To: Eine Antwortadresse die - wenn vorhanden - von E-Mailprogrammen zum Antworten verwendet wird, statt der "From"-Adresse
  • Received: Hier gibt es in der Regel mehrere Zeilen. Diese sind meistens (nicht immer!) von unten nach oben zu lesen. Denn jeder E-Mailserver durch den die E-Mail "durchging" verzeichnet von wem er die E-Mail empfangen hat und wann.
  • Content-Type: Welche Zeichenkodierung im Nachrichtenteil verwendet wird
  • Content-Transfer-Encoding: Auch ein Teil der Zeichenkodierung im Nachrichtenteil

Bei E-Mailprogrammen werden meist nur folgende Felder angezeigt: From, To, Subject, Date

Interessant sind beispielsweise die "Received"-Zeilen. Diese zeigen - zumindestens ab dem Eintreffen der E-Mail bei einem vertrauenswürdigen Server (hier an der Universität) von welchem Server diese ursprünlgich kamen und wie lange sie danach gebraucht hat um ins Postfach einzugehen. Ersteres kann man dazu benutzen um eine E-Mail von der Vertrauenswürdigkeit einzuschätzen (beispielsweise eine E-Mail die von der Deutschen Bahn angeblich kam, sollte an Server bevor es an die Universität ging, auch irgendwas mit deutschebahn.de haben). Die Zeiten hingegen sind immer ein guter Beleg dafür ob eine verspätet eingegangene E-Mail im Mailgateway der Universität so lange hin, oder bereits vorher es ein Problem gab.

Eine Fälschung einer E-Mail kann man sehr gut anhand genauerer Analyse des E-Mail-Headers vornehmen:

  • Ist die Absendeadresse korrekt? Hier mehr zu E-Mailadresse im Detail. Dies sieht man manchmal nur wenn man den E-Mail-Header sich genauer betrachtet
  • Ist die Empfangsadresse korrekt? Auch hier hilft der Blick in den E-Mail-Header
  • Sind die beteiligten Server korrekt? Also die Received-Zeilen. Aber hier kann man auch leicht in die Irre geführt werden, da manche der US-amerikanischen Firmen über E-Mailserver senden die leider auch Spam senden.

Beispiel E-Mail-Header

Received: from mail-relay.hrz.tu-darmstadt.de (mail-relay.hrz.tu-darmstadt.de [IPv6:2001:41b8:83f:1610::1])
   (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
   key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
   client-signature RSA-PSS (2048 bits) client-digest SHA256)
   by TU-EX.ads.tu-darmstadt.de (2001:41b8:815:5b40::)
   for <vorname.nachname@tu-darmstadt.de>; Wed, 5 Apr 2023 06:50:22 +0200 (CEST)
Received: from mail.server.org (mail.server.org [1.2.3.4])
   by mail-relay.hrz.tu-darmstadt.de (8.15.2/8.15.2/HRZ/PMX) with ESMTPS id 3354oKu3007473
   (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
   for <vorname.nachname@tu-darmstadt.de>; Wed, 5 Apr 2023 06:50:20 +0200
Received: from [4.3.2.1] (local-pc [4.3.2.1])
   (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
   key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits))
   (No client certificate requested)
   (Authenticated sender: auth-id)
   by mail.server.org (mail.server.org) with ESMTPSA id 496DB1B469767
   for <vorname.nachname@tu-darmstadt.de>; Wed, 5 Apr 2023 06:49:19 +0200 (CEST)
Content-Type: multipart/mixed; boundary="PpCtVWkClWYqeMdlC99PNuaW"
Message-ID: <bfe77cd7-c013-781a-1803-6ae1d81b600d@domain.de>
Date: Wed, 5 Apr 2023 06:49:19 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/1.2.3
From: "Nachname, Vorname" <name@domain.de>
Subject: Test einer E-Mail
To: Vorname Nachname <vorname.nachname@tu-darmstadt.de>

Dabei gibt es ingesamt 3 Received-Zeilen, sowie Content-Type, Message-ID, Date, MIME-Version, User-Agent, From, Subject, To

Hier wurde eine E-Mail gesendet wie folgt (anhand der Received-Zeilen):

  • vom lokalen Rechner mit der IP-Adresse [4.3.2.1] an einen Provider mittels Authentifikation mail.server.org (Zeit: 5 Apr 2023 06:49:19 +0200 (CEST))
  • von dort ging es dann weiter vom Server "mail.server.org" [1.2.3.4] an die Universität "mail-dispatcher.hrz.tu-darmstadt.de" (Zeit: 5 Apr 2023 06:50:20 +0200)
  • vom mail-relay.hrz.tu-darmstadt.de [2001:41b8:83f:1610::1] an Groupware "TU-EX.ads.tu-darmstadt.de" (Zeit: 5 Apr 2023 06:50:22 +0200 (CEST))

D.h. es die E-Mail brauchte insgesamt 63 Sekunden um anzukommen. Die größte Verzögerung gab es beim externen Server ("mail.server.org" [1.2.3.4]) von nach 61 Sekunden. Danach ging es binnen 2 Sekunden weiter Universität-intern.

E-Mail-Nachricht

Die E-Mailnachricht kann ganz normaler Text sein. Also mit oder ohne erzwungen Umbrüchen, mit oder ohne kodierten Sonderzeichen (äöüß), oder komplett in einem scheinbaren Kauderwelch (genauer Base64-codiert).

Wie der Nachrichtenteil kodiert wurde wird in dem E-Mail-Header hauptsächlich in dem Feld "Content-Type" beschrieben. Also erstes steht dort ein sogenannter Mime-Type (siehe Wikipedia). Dieser beschreibt allgemein was für eine Art von Text kommt. Danach ist in der Regel ein Zeichensatz angegeben.
Also beschreibt "Content-Type: text/plain; charset=UTF-8" dann der Nachrichtenteil ein Text, genauer ein Plaintext ist der im Zeichenformat "UTF-8" kodiert ist.

Eine sehr häufige Sonderform des Mime-Types ist "multipart/alternative" oder ""multipart/mixed. Diese beschreibt das der Nachrichten Text aus mehreren Teilen bestehen kann. Und jeder Teil hat eigene Zeichekodierung bzw. Form. Hinter einem solchem Mime-Type steht noch ein "Boundary". Dies kennzeichnet die Grenzen der jeweiligen Bestandteile einer E-Mailnachricht. Die Zeichenfolge eines Boundary muss in einer E-Mail einmalig sein und besteht in der Regel aus eine langen Zeichenkette.
Dieses Boundary taucht dann wieder in dem Nachrichtenteil auf und zwar in folgender Form immer alleine in einer Zeile: mit zwei Minuszeichen ("-") vorweg als Beginn eines neuen Abschnitts. Mit zwei Minuszeichen vorweg und abschließend als Ende aller diesbezüglichen Abschnitte.
Nach jedem Abschnitt (mit zwei Minuszeichen vorweg) ist wieder eine Art "Kopf" des Bereichs. Der Kopf ist beendet wenn auch hier wieder eine leere Zeile kommt. Nach dem Abschnitssanfang kommt wieder ein "Content-Type" mit einen Mime-Type etc. der den Abschnitt beschreibt.

Abschnitte können Text-formatiert sein ("Content-Type: text/plain") oder HTML-Formatiert sein ("Content-Type: text/html") oder auch sogenannte Anhänge sein ("Content-Type: text/rtf" oder "Content-Type: image/jpeg" oder "Content-Type: application/msword" usw.). Text- bzw. HTML-Formatierte Bereiche zeigen E-Mailprogramme in der Regel an. Alle anderen werden als sogenannte Anhänge angezeigt.

Jetzt muss man noch wissen, dass das E-Mailformat sehr alt ist und nur nach und nach erweitert wurde. Ursprünglich wurden E-Mails nur als Text (ohne Anhänge, Formatierungen etc.) im ASCII-Format versendet. Alle weiterten Möglickeiten wie Anhänge, Bilder, Formatierungen usw. wurden erst nach und nach in das bestehende Protokoll eingebaut. Daher werden E-Mailnachrichten (fast) immer noch im ASCII-Format versendet. So werden Texte meist mit dem Zusatz "Content-Transfer-Encoding: quoted-printable" gekennzeichnet um beispielsweise deutsche Umlaute (äöüß) zu maskieren. Binäre Anhänge werden immer in einem Base64-Format umgewandelt eingefügt ("Content-Transfer-Encoding: base64"). Hierbei werden 8-bit Zeichen konsequent Buchstaben gewandelt (und zum lesen wieder zurück gewandelt). Dabei werden Anhänge zum versenden etwa 1/7 größer als zuvor.

Beispiel E-Mail-Nachricht

--PpCtVWkClWYqeMdlC99PNuaW
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hallo,

hier ein Beispiel einer E-Mail die mit einem Anhang versendet wird.

Mit freundlichen Grüßen

Dirk Weikard



--PpCtVWkClWYqeMdlC99PNuaW
Content-Type: application/pdf; name="Beispieltext.pdf"
Content-Disposition: attachment; filename="Beispieltext.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nL1YS2/cNhBGXk66DpJsEyd9XPYoHZbl+3ENEBTorcXe2p5StCcH
XKS5yn6r4OfoT2N0zavxKJgSGgzHqftl6rfwxOGkeKZnxkgbwNI/T7/s4HRmNKTM6S9IkufL
[...weitere Zeilen...]
QjQ2Mz5dCj4+CnN0YXJ0eHJlZgoxNTkyNgolJUVPRgo=

--PpCtVWkClWYqeMdlC99PNuaW--

Die E-Mail besteht auf zwei Bereichen.
Im ersten Bereich wird nur Text übertragen in UTF-8-Format und es wird im 8-bit-Format transferiert, d.h. ohne weitere Änderung.
Im zweiten Bereich wird ein PDF übertragen (und als Anhang dargestellt). Der Name des PDFs heißt "Beispieltext.pdf" und wird als Base64 transferiert.

[zurück zum Index]

^