Grundlagen E-Mail

Eine kurze Übersicht zu den wichtigsten Begriffen und Techniken bei E-Mail. Ohne dabei zu sehr ins Detail zu gehen. 

Grundlegendes zu E-Mail

E-Mails gibt es mittlerweile seit über 40 Jahren im Internet und in dieser Zeit wurden sehr viele Erweiterungen, Ergänzungen und Änderungen eingeführt. In Summe kann es daher sehr kompliziert werden, wenn es um das Erzeugen, Versenden, Empfangen und Anzeigen von E-Mails geht. Dieser Artikel soll in aller Kürze auf die wichtigsten Punkte eingehen, um ein gewisses Grundverständnis zu vermitteln.

Aufbau einer E-Mail

Wird ausführlich im RFC 5322 beschrieben. 

Eine E-Mail besteht aus 2 Teilen: Dem Header (der Briefkopf) und dem Body (der eigentliche Inhalt des Briefes).

Der Header enthält z.B. 

  • eine Absenderadresse
  • Betreff
  • Datum
  • Empfängeradresse(n)

Diese werden in der Regel vom Mailprogramm auch so angezeigt. 

Darüber hinaus gibt es noch andere Informationen im Header, die erst in der erweiterten bzw. "Experten"-Ansicht angezeigt werden. Dort finden sich Hinweise zum Spam-Status (X-Spam-Flag), dem Übertragungsweg der E-Mail (Received) und einige andere Informationen.

Der Body einer E-Mail kann dann selbst wieder aus mehreren Teilen bestehen:

  • reine Textfassung der Mail
  • HTML-Fassung der Mail
  • Anhang
  • S/MIME-Signatur
  • ...

Kleines Beispiel zum Aufbau einer E-Mail

Zunächst die Ansicht im Mailprogramm:

Die selbe Mail im "Quellcode":

Message-ID: <b73c0774-9ca4-42f2-9710-f6454b4be667@example.com>
Date: Wed, 31 Jan 2024 10:10:47 +0100
User-Agent: Mozilla Thunderbird
From: Anzeigename eines Benutzers <benutzer@example.com>
Subject: Das ist die Betreffzeile der Beispielmail
To: =?UTF-8?Q?ein_Empf=C3=A4nger?= <empfaenger@example.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Und ab hier steht der Inhalt/Body der E-Mail

Versand einer E-Mail

Wird ausführlich im RFC 5321 beschrieben.

Zum Transport einer Mail zwischen zwei Servern wird das Protokoll SMTP (simple mail transfer protocol) verwendet.

Um in der Analogie zum Brief zu bleiben: Beim Versand wird die E-Mail in einen "Umschlag" gesteckt. Dieser Umschlag hat dann ebenfalls:

  • eine Absenderadresse (diese ist in der Regel identisch zur Absenderadresse im Header, muss es aber nicht sein!)
  • eine oder mehrere Empfängeradresse(n) (diese sind in der Regel identisch zu der/den Empfängeradresse(n) im Header, müssen es aber nicht sein! z.B. wenn manche der Empfänger als Blindkopie/BCC eingetragen sind)
  • für den reinen Transport einer E-Mail sind ausschließlich die Adressen im Umschlag von Belang. Die Header-Adressen werden erst bei den Prüfungen gegen gefälschte Adressen von Interesse bzw. am Ende beim Empfänger zur Anzeige im Mail-Programm.

Für die nächsten Abschnitte ist es wichtig zu verstehen, dass zwischen den verschiedenen Absenderadressen unterschieden wird! 

  • Absenderadresse im Header einer E-Mail. ("Header-From" bzw. "RFC 5322-From"):
    Diese Adresse bekommt ein Empfänger einer E-Mail als Absender angezeigt. Drückt der Empfänger auf "Antworten", dann geht die Antwort-Mail normalerweise an diese Adresse, außer im Header steht auch noch eine Antwort-Adresse (Reply-To), denn geht die Antwort an diese Adresse.
  • Absenderadresse im Umschlag einer E-Mail. ("Envelope-From" bzw. "RFC 5321-From"):
    Diese Adresse bekommt ein Empfänger einer E-Mail (in der Regel) NICHT zu sehen. Sie wird nur für den Transport einer E-Mail zwischen Mailservern verwendet. Kommt es zu Zustellproblemen oder anderen Fehlern während des Transports einer E-Mail, dann gehen die Fehlermeldungen dazu an die Absenderadresse im Umschlag einer E-Mail.

Kleines Beispiel zum Transport einer E-Mail

Wie der Name schon sagt, ist SMTP ein sehr einfaches Protokoll. Die beiden beteiligten Server stehen dabei in einem Dialog und folgen einem Skript, so wie es im RFC 5321 definiert wurde. 

Im Beispiel ist der Text vom empfangenden Server in blau und der Text vom versendenden Server in orange dargestellt. In schwarzer Schrift sind Anmerkungen, die von uns nachträglich hinzugefügt wurden.

220 empfaenger-server.example.com ESMTP Postfix
HELO absender-server.example.com
250 empfaenger-server.example.com
MAIL FROM: <benutzer@example.com>          (Absenderadresse im Umschlag)
250 2.1.0 Ok
RCPT TO: <empfaenger@example.com>          (Emfpängeradresse im Umschlag)
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>

Message-ID: <b73c0774-9ca4-42f2-9710-f6454b4be667@example.com>
Date: Wed, 31 Jan 2024 10:10:47 +0100
User-Agent: Mozilla Thunderbird
From: Anzeigename eines Benutzers <benutzer@example.com>       (Absenderadresse im Header)
Subject: Das ist die Betreffzeile der Beispielmail
To: =?UTF-8?Q?ein_Empf=C3=A4nger?= <empfaenger@example.com>    (Emfpängeradresse im Header)
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0


Und ab hier steht der Inhalt/Body der E-Mail

.
250 2.0.0 Ok: queued as 9305154F54B
QUIT
221 2.0.0 Bye

Techniken zur Verhinderung von gefälschten Absendern bzw. Prüfung auf autorisierten Versand

Allen 3 genannten Techniken ist gemein, dass sie zur Prüfung nur den Teil "rechts vom @" einer Mailadresse betrachten. Also nur die Domain und nicht die gesamte Adresse.

Sender Policy Framework (SPF)

Wird ausführlich in RFC 7208 beschrieben.

Mit SPF kann ein Inhaber einer Maildomain festlegen, welche Mailserver autorisiert sind, im Umschlag (Envelope-From) Absenderadressen aus seiner Maildomain zu verwenden. Dazu wird ein sog. SPF-Record im DNS hinterlegt. Dieser führt dann die autorisierten IP-Adressen, Netze oder Servernamen auf. Ein empfangender Mailserver kann dann während der Übertragung einer Mail prüfen, ob der versendende Mailserver autorisiert ist, die Absenderadresse im Umschlag (Envelope-From) zu verwenden.

DomainKeys Identified Mail (DKIM)

Wird ausführlich im RFC 6376 beschrieben.

Mit DKIM kann ein Mailserver beim Versand von E-Mails diese kryptographisch signieren und so "Verantwortung" für die E-Mail übernehmen. Ein empfangender Mailserver kann dann diese Signatur überprüfen und dabei feststellen, ob die E-Mail auf dem Übertragungsweg verändert wurde und ob sie auch von demjenigen Server verschickt wurde, der die Signatur (angeblich) erstellt hat. Dazu werden wiederum spezielle Einträge im DNS hinterlegt. Stichworte sind hier public DKIM-Keys und Selektoren. DKIM für sich betrachtet hat erstmal nichts mit den Absenderadressen einer E-Mail zu tun. Diese Verknüpfung kommt erst durch die 3. Technik zustande:

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Wird ausführlich im RFC 7489 beschrieben.

Mit DMARC werden nun SPF, DKIM und die Domain der Absenderadressen abgeglichen. Bei DMARC legt wiederum der Inhaber einer Maildomain fest, wie ein empfangender Mailserver mit einer E-Mail umgehen soll, wenn die Prüfung auf Versand durch einen autorisierten Absenderserver fehl schlägt. Dazu frägt der empfangende Mailserver den DMARC-Record im DNS derjenigen Domain ab, die in der Header-From Absenderadresse steht.

 Im Wesentlichen besteht ein DMARC-Record im DNS aus 3 Teilen:

  • eine Policy: Diese legt fest, was ein empfangender Mailserver mit einer E-Mail tun soll, wenn die Prüfungen fehlgeschlagen sind. 
    • "none": Keine besondere Aktion. Diesen Wert wählt man in der Regel bei der Einführung von DMARC, bis man die Probleme gelöst hat, die DMARC auslösen kann. Einen Überblick zu den Problemen mit DMARC finden Sie in DMARC und damit verbundene Probleme.
    • "quarantine": Die E-Mail sollte in Quarantäne genommen oder in den Spam/Junk-Ordner zugestellt werden
    • "reject": Die E-Mail soll sofort abgelehnt werden
  • Modus für den Abgleich von Absenderdomain und Domain für SPF/DKIM:
    • "strict": Die Domain der Header-From Adresse muss exakt übereinstimmen mit der Domain, die für DKIM-Signatur oder für die SPF-Prüfung benutzt wurde, d.h. die Header-From Domain muss identisch mit der DKIM-Domain bzw. der Envelope-From Domain sein.
    • "relaxed": Die Domain der Header-From Adresse und die Domains der DKIM-Signatur bzw. der SPF-Prüfung müssen nur zur selben Organisations-Domain gehören. Für .com/.de-Domains gilt z.B. dass example.com, foo.example.com und bar.example.com alle zur Organisations-Domain  example.com gehören.
  • Reporting: Der Inhaber der Maildomain kann einstellen, dass er Berichte von empfangenden Mailservern erhalten möchte, wenn E-Mails bei der Überprüfung durchgefallen sind.

Eine E-Mail gilt bei DMARC als autorisiert versandt, wenn die folgenden 3 Bedingungen erfüllt sind:

  1. Zur Header-From Absenderdomain im DNS ein DMARC-Record eingetragen ist. 
    Wenn die Absenderdomain eine Subdomain ist, z.B. foo.example.com und es keinen DMARC-Record für foo.example.com gibt, dann wird auch noch bei der zugehörigen Organisations-Domain (in diesem Beispiel dann example.com) geprüft, ob dort ein DMARC-Record vorhanden ist, und falls ja, wird dieser verwendet. D.h. die Organisations-Domain kann einen Standard-DMARC-Record für sich und alle Subdomains vorgeben. Das erspart einem, für jede Subdomain extra einen DMARC-Record anlegen und pflegen zu müssen.
  2. SPF oder DKIM erfolgreich geprüft werden konnten, also
    1. Bei SPF die IP-Adresse des Absenderservers im SPF-Record zur Envelope-From Absenderdomain enthalten ist
    2. Bei DKIM die Überprüfung der Signatur ergibt, dass die E-Mail nicht verändert wurde und die Signatur zum public DKIM-Key im DNS der signierenden Domain passt
  3. der Abgleich (Alignment) von Header-From Absenderdomain entsprechend des Modus (strict/relaxed) eine Übereinstimmung ergibt
    1. bei SPF mit der Envelope-From Absenderdomain
    2. bei DKIM mit der signierenden Domain

Kleines Beispiel zur Überprüfung auf autorisierten Versand

Nehmen wir das SMTP-Beispiel von oben (ergänzt um eine DKIM-Signatur):

220 empfaenger-server.example.com ESMTP Postfix
HELO absender-server.example.com
250 empfaenger-server.example.com
MAIL FROM: <benutzer@example.com>          (für die Prüfung per SPF wird die Domain example.com verwendet)
250 2.1.0 Ok
RCPT TO: <empfaenger@example.com>          
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;    (DKIM-Signatur wurde von der Domain example.com mit dem Selektor pubkey1 erstellt)
 q=dns/txt; s=pubkey1; t=1706648971;
 [ ... ]Message-ID: <b73c0774-9ca4-42f2-9710-f6454b4be667@example.com>
Date: Wed, 31 Jan 2024 10:10:47 +0100
User-Agent: Mozilla Thunderbird
From: Anzeigename eines Benutzers <benutzer@example.com>       (für die Prüfung per DMARC wird die Domain example.com verwendet)
Subject: Das ist die Betreffzeile der Beispielmail
To: =?UTF-8?Q?ein_Empf=C3=A4nger?= <empfaenger@example.com>    
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0


Und ab hier steht der Inhalt/Body der E-Mail

.
250 2.0.0 Ok: queued as 9305154F54B
QUIT
221 2.0.0 Bye

In diesem einfachen Beispiel passt die jeweilige Domain für alle Checks (SPF, DMARC, DKIM) zusammen, da immer dieselbe Domain example.com verwendet wurde. Das ist der optimale Fall.