Eine Einführung zum Thema E-Mail und Absenderreputation

Am 3. August 1984 kam in Deutschland die erste E-Mail über das Internet an. Verschickt wurde sie am vorherigen Tag in den USA. Seitdem hat sich eine Menge verändert, vor allem die Geschwindigkeit. Aller Unkenrufe, dass die E-Mail tot sei, zum Trotz, setzt sie ihren Siegeszug fort. Im Gegensatz zu Slack, Microsoft Teams und Co. ist sie ohne Einschränkungen über Unternehmensgrenzen und vor allem Plattformen hinweg nutzbar. Obendrein ist sie nicht auf die Verfügbarkeit eines einzelnen Cloud-Dienstes angewiesen.

Im Trend aber nicht von Haus aus sicher

Die Anzahl der verschickten E-Mails pro Jahr nimmt weiterhin zu und liegt damit voll im Trend. Ein großer Nachteil dieses Mediums ist jedoch die von Haus aus fehlende Sicherheit. Das S in SMTP steht nun einmal nicht für Secure, sondern für Simple. Mittlerweile gibt es etliche Aufsätze und Erweiterungen, welche die Sicherheit maßgeblich erhöhen. Nicht alle davon erfordern Expertenwissen der Benutzer.

In dieser kleinen Artikelserie möchten wir Ihnen zeigen, auf was Sie sowohl beim E-Mail-Empfang als auch beim Versand achten müssen. Beginnen werden wir mit einer kurzen Erläuterung von wichtigen Begrifflichkeiten, um die Verständlichkeit der Artikel zu erhöhen.

Der Aufbau einer E-Mail

Eine E-Mail besteht im Wesentlichen aus drei Teilen: dem sogenannten Envelope, dem Header und dem Body.

1. Envelope
Wie bei der Briefpost auch, gibt es auch bei der elektronischen Post einen Umschlag, auf dem die Empfänger- und Absenderadresse notiert sind. Anhand dieser Adressen erfolgt die Zustellung des Briefes an den Empfänger, oder im Fehlerfall die Rücksendung an den Absender. Im Fall der E-Mail nennt man die diese Angaben Routinginformationen.

Der Envelope besteht aus der Absenderadresse, im Folgenden Envelope-FROM-Adresse genannt, und der Empfängeradresse, nachfolgend Envelope-TO-Adresse genannt. Die IP-Adresse des einliefernden Servers kann im weitesten Sinne ebenfalls zu den Envelope-Daten gezählt werden.

2. Header
Im Header befinden sich deutlich mehr Informationen, u.a. auch erneut Auskunft zum Absender und zum Empfänger. Im Gegensatz zu den Adressinformationen im Envelope, sind die Headeradressen jedoch nicht routingrelevant. Sie werden allerdings von den beteiligten E-Mail-Clients für die Anzeige der Adressdaten verwendet. Zur besseren Abgrenzung der Begrifflichkeiten wird im Folgenden vom Header-From und Header-To gesprochen.

Ein weiterer Unterschied zu den Adressen im Envelope ist der Displayname. Während im Envelope-From lediglich die E-Mail-Adresse, z.B. „stefan.cink@nospamproxy.com“ steht, kann diese Adresse im Header-From um ein Textfeld angereichert werden, in dem mehr oder weniger beliebiger Text stehen darf. Am Beispiel der vorgenannten E-Mail-Adresse könnte der Header-From wie folgt aussehen: „Stefan Cink” <stefan.cink@nospamproxy.com>.

Die Aufteilung der Adresse und des Displaynamens ist in der RFC 5322 normiert. Zwischen den spitzen Klammern <> muss die E-Mail-Adresse stehen, während der Displayname zwischen zwei Hochkommas „“ stehen muss. Wie bereits erwähnt, zeigen E-Mail-Clients lediglich die Adressinformationen aus dem Header der E-Mail an, viele von Ihnen beschränken sich darüber hinaus auf die Anzeige des Displaynamens. Im o.g. Beispiel würde man lediglich „Stefan Cink“ als Absenderinformation angezeigt bekommen.

Aus Platzgründen beschränken sich vor allem E-Mail-Clients auf Mobilgeräten auf die Anzeige des Displaynamens. Die Informationen aus dem Envelope bekommt der Empfänger in der Regel nicht zu Gesicht. Weitere Bestandteile des Headers sind die Betreffzeile, das Datum der E-Mail, die MessageID u.v.m.

3. Body
Der Body einer E-Mail enthält die eigentliche Nachrichteninformation inklusive aller Anhänge. Der Aufbau des Bodys ist ebenfalls in der RFC 5322 geregelt. In den Anfängen der E-Mail bestand eine Nachricht lediglich aus Text ohne Formatierungsmöglichkeiten, sogenannten PlainText-Mails. Dies hat sich in den letzten Jahren zugunsten von HTML-basierten Inhalten geändert.

Mit HTML ist es möglich, Texte in E-Mails farblich zu gestalten sowie Bilder zu verwenden. Der Vorteil liegt auf der Hand: Eine E-Mail sieht dadurch schöner und wertiger aus. Mittlerweile ist es so, dass der Body einer E-Mail häufig sowohl eine PlainText-Version, als auch eine HTML-Version der Nachricht enthält. Der E-Mail-Client kann dann selbst entscheiden, welche Version er anzeigen möchte, oder soll.

Bonus: MX-Record
Der MX-Record wird in den kommenden Blog-Beiträgen auch hin und wieder verwendet und bedarf daher einer kurzen Erklärung: Es handelt sich beim MX-Record um einen Eintrag in der DNS-Zone einer Domain und gibt den oder die Server an, die für den Empfang von E-Mails an die jeweilige Domain verantwortlich sind.

Die Mindeststandards beim E-Mail-Versand

Der Versand einer E-Mail wird von vielen Unternehmen nach wie vor deutlich unterschätzt. Es ist nicht damit getan, dem eigenen E-Mail-Server beizubringen, auf welchem Weg die Nachricht dem Empfänger zugestellt werden soll. Die zuverlässige Zustellung der E-Mail an den Empfängerserver ist aufgrund stark gestiegener Sicherheitsmechanismen auf der Empfängerseite keine Selbstverständlichkeit (mehr) und muss mit geeigneten Mitteln unterstützt werden.

Bei der Zustellung der E-Mail als solches unterscheidet man die direkte Zustellung und die Zustellung unter Zuhilfenahme eines externen Dienstleisters. Bei der direkten Zustellung findet der E-Mail-Server des Absenders mittels DNS-Auflösung selbständig den MX-Record der Zieldomain und stellt die Nachricht dem Server des Empfängers direkt zu. Bei der Zustellung über einen externen Dienstleister, wird die Zustellung an den MX der Zieldomain einem externen Dienstleister anvertraut. Das absendende Unternehmen weiß in diesem Fall nur, dass die E-Mail das Unternehmen erfolgreich verlassen hat, nicht aber, ob sie auch beim MX der Zieldomäne angekommen ist.

Beide Verfahren haben Vor-und Nachteile. Bei der direkten Zustellung ist es dem E-Mail-Administrator möglich sofort zu erkennen, ob eine E-Mail erfolgreich zugestellt werden konnte, oder nicht. Bei dieser Methode muss allerdings gewährleistet sein, dass die eigene IP-Adresse eine gewisse Reputation im Internet hat.

Die IP-Adresse

Zur IP-Adresse sollten folgende Punkte beachtet werden:

– Die IP-Adresse muss eine statische IP-Adresse sein. Die Zustellung über dynamische IP-Adressen funktioniert heutzutage aus Sicherheitsgründen so gut wie nicht mehr.

– Für die IP-Adresse muss es einen gültigen Reverse DNS-Eintrag geben. Nur damit kann der empfangende Host prüfen, wie der einliefernde Host heißt. Ohne RDNS-Eintrag ist die Zustellung zu den meisten MX ebenfalls nicht mehr möglich.

– Ist die IP-Adresse teil eines Subnetzes eines großen Cloud-Providers wie Microsoft Azure, AWS, o.ä. ist die Zustellung ebenfalls herausfordernd. Nicht selten werden Verbindungen aus diesen Bereichen pauschal negativ bewertet und der E-Mail-Administrator muss sich darum kümmern, dass die jeweilige IP-Adresse freigeschaltet wird.

Die Zustellung über einen externen Dienstleister entschärft das Zustellrisiko bzgl. der IP-Adresse, bringt aber den Nachteil mit sich, dass der Administrator nicht mehr selbst feststellen kann, ob die E-Mail in den Verfügungsbereich des Empfängers zugestellt wurde, oder nicht. Gerade bei der Fehlersuche ist das oft ein Problem.

Die Absenderreputation

Neben der Hygiene für die IP-Adresse gibt es noch weitere Hygienefaktoren, die Sie kennen und umsetzen sollten. Man spricht im Allgemeinen von der Absenderreputation. Sie zielt auf die Authentizität des Absenders, neben der Integrität und der mangelnden Inhaltsverschlüsselung, einer der drei maßgeblichen Schwachpunkte der E-Mail. Selbst für Laien ist es problemlos möglich eine E-Mail im Namen eines anderen zu verschicken. Um dieses Problem zu lösen, gibt es drei Technologien, die eng miteinander verbunden sind:

1. Technologie – Sender Policy Framework

Im Sender Policy Framework (SPF) gibt der Inhaber einer Domain in seiner DNS-Zone an, welche Server autorisiert sind, E-Mails im Namen der eigenen Domain zu versenden. Dazu erstellt er in der entsprechenden DNS-Zone einen sogenannten SPF-Record. Technisch gesehen handelt es sich hierbei um einen TXT Record, dessen Syntax in der RFC7208 exakt spezifiziert ist.

Bei der Zustellung einer E-Mail entnimmt der empfangende Server, die Absender-Domain aus dem Envelope Sender einer E-Mail. Anschließend wird im Rahmen einer DNS-Abfrage ermittelt, ob für die Domain ein SPF-Record existiert. Diese Prüfung wird optional zusätzlich für den Host-Eintrag des Absenders (EHLO-Client-ID) durchgeführt. Taucht die IP-Adresse oder der FQDN des einliefernden Servers nicht im SPF-Record auf, ist er für den Versand von E-Mails im Namen dieser Domain nicht autorisiert.

2. Technologie – DomainKeys Identified Mail

Bei DomainKeys Identified Mail (DKIM) wird ebenfalls ein TXT-Record in Form einer RFC normierten Syntax in der DNS-Zone der zu schützenden Domain erstellt. Zusätzlich kommt bei DKIM mit dem Public-Key-Verfahren eine kryptografische Komponente zum Tragen. Im Unterschied zu SPF wird bei DKIM die Absender-Domain aus dem Header-From der E-Mail untersucht. Vor der Erstellung des Records wird ein Schlüsselpaar, bestehend aus einem öffentlichen und einem privaten Schlüssel gebildet.

Der öffentliche Schlüssel wird in Kombination mit anderen Informationen als DKIM-Record in der DNS-Zone hinterlegt. Der private Schlüssel verbleibt ausschließlich auf dem Server, der für den Versand autorisiert werden soll. Mit Hilfe des privaten Schlüssels erzeugt der absendende Server für jede ausgehende E-Mail eine kryptografische Signatur, die sowohl Teile des Headers als auch den Inhalt der E-Mail umfasst.

Die erzeugte DKIM-Signatur wird als X-Header-Wert in den Header der jeweiligen E-Mail geschrieben. Der empfangende Server einer DKIM-geschützten E-Mail ermittelt dazu zunächst die Domain, die in der DKIM-Signatur der E-Mail angegeben ist, gefolgt vom sogenannten Selektor. Der Selektor ist fester Bestandteil einer DKIM-Signatur und gibt an, unter welchem Namen der passende öffentliche Schlüssel in der DNS-Zone der Absender-Domain zu finden ist.

Nachdem er den öffentlichen Schlüssel heruntergeladen hat, wird im Rahmen eines kryptografischen Vorgangs die Signatur geprüft. Schlägt diese Prüfung fehl, liegt entweder der falsche öffentliche Schlüssel vor oder die E-Mail wurde unterwegs verändert. Außerdem werden die Domains aus dem Header-From und dem Domain-Schalter der DKIM-Signatur miteinander verglichen.

Die DKIM-Signatur stellt somit zwei Dinge sicher: Zum einen weiß der empfangende Server, dass die E-Mail samt Inhalt auf dem Transportweg nicht verändert worden ist. Zum anderen weiß er, dass der Inhaber der im Header angegebenen Absender-Domain den Server autorisiert hat.

Im Unterschied zu kryptografischen Signaturen mittels S/MIME oder PGP sieht der Empfänger einer E-Mail die DKIM-Signatur nicht. Es ist ein rein serverbasiertes Verfahren. Erst wenn man sich den Header einer E-Mail anzeigen lässt, wird die DKIM-Signatur sichtbar.

3. Technologie – Domain-based Message Authentication, Reporting and Conformance

Weder SPF noch DKIM geben dem empfangenden Server einer E-Mail klare Anweisungen was mit E-Mails passieren soll, die die SPF und DKIM-Prüfung nicht erfolgreich bestanden haben. Diese Lücke schließt DMARC (Domain-based Message Autehntication, Reporting and Conformance). DMARC ergänzt die SPF- und DKIM-Prüfungen um das Alignment. Dieses stellt sicher, dass die Envelope-From-Adresse mit der Header-From-Adresse übereinstimmt. Diese Prüfung ist wichtig, weil die gängigsten E-Mail-Programme, wie bereits erwähnt, lediglich die Header-From-Informationen einer E-Mail anzeigen und der Empfänger somit leicht getäuscht werden kann. Genau diesen Umstand machen sich beispielsweise Angreifer zunutze, die einem Unternehmen mit der Chef-Betrugsmasche, die häufig auch CEO-Fraud genannt wird, Schaden zufügen wollen.

Eine weitere Besonderheit von DMARC ist die Berichtsfunktion. Sie sorgt dafür, dass der Inhaber einer Domain regelmäßig darüber informiert wird, welche Server in seinem Namen E-Mails versendet haben und ob die Prüfung beim Empfänger erfolgreich war, oder nicht. So bekommt er nicht nur einen guten Überblick über „seine“ E-Mails im Internet, sondern auch wertvolle Informationen, ob seine SPF und DKIM Einträge vollständig und syntaktisch korrekt sind.

Um DMARC zu aktivieren, hinterlegt der Inhaber einer Domain eine DMARC-Richtlinie in seiner DNS-Zone. Wie bei SPF und DKIM auch, wird die DMARC-Richtlinie in einem RFC normierten TXT-Record gespeichert. Sie beinhaltet die Information, welche Prüfungen vom Empfänger gemacht werden müssen (SPF und/oder DKIM). Zusätzlich wird festgelegt, wie sich der Empfänger verhalten soll, wenn die Prüfungen fehlschlagen: Annehmen, in Quarantäne stecken oder Abweisen sind die möglichen Aktionen.

Des Weiteren werden in der DMARC-Richtlinie E-Mail-Adressen hinterlegt, an die Berichte geschickt werden sollen. Diese werden von allen Servern im Internet erstellt, die DMARC beim E-Mail-Empfang unterstützen und auch E-Mails von der jeweiligen Domain erhalten haben. Die Berichterstattung erfolgt täglich. Um das Berichtsaufkommen im Zweifel nicht zu hoch werden zu lassen, kann in der DMARC-Richtlinie angegeben werden, dass z.B. nur für jede 10. Mail ein Bericht generiert werden soll.

E-Mail-Empfang – Authenticated Received Chain

Streng genommen gehört ARC (Authenticated Received Chain) eher in den Bereich des E-Mail-Empfangs, wird aber der Vollständigkeit halber hier schon einmal aufgeführt. ARC ist die jüngste Technologie im Bereich der Absenderreputation und soll hier nicht unberücksichtigt bleiben. Sie befindet sich seit Juli 2019 im Status „Experimental“. Der Verbreitungsgrad ist gerade bei den cloud-basierten Diensten von Google, Microsoft etc. relativ hoch, da es als Authentifizierungssystem ein bekanntes Problem bei der Verwendung von SPF, DKIM und DMARC im Rahmen von Mailinglisten oder anderen Weiterleitungsdiensten löst.

Genauer gesagt ermöglicht ARC, die ursprünglichen Authentifizierungsergebnisse einer E-Mail mit Hilfe einer Signatur zu konservieren. So kann ein empfangender Dienst eine E-Mail validieren, wenn die SPF- und DKIM-Einträge der E-Mail durch die Verarbeitung eines Zwischenservers ungültig werden. Der erste E-Mail-Server in einer E-Mail-Kette, der ARC unterstützt, fügt immer drei unterschiedliche Einträge in den E-Mail-Header:

1. ARC-Authentication-Results (AAR): Hier protokolliert der aufbringende Server die Ergebnisse seiner SPF, DKIM und DMARC Prüfungen in Kombination mit der jeweiligen Instanznummer.
2. ARC-Seal (AS): Das ARC-Siegel ist eine Kombination aus derselben Instanznummer aus Schritt 1., einer DKIM-ähnlichen Signatur der bisherigen ARC-Seal-Header und der Gültigkeit der bisherigen ARC-Einträge.
3. ARC-Message-Signature (AMS): Die eigentliche ARC-Signatur ist eine Kombination aus der Instanznummer aus Schritt 1. und einer DKIM-ähnlichen Signatur der gesamten Nachricht mit Ausnahme der ARC-Seal-Header. Die AMS beinhaltet, äquivalent zur DKIM-Signatur eine Angabe zur Domain, die das Siegel aufbringt, z.B. d=microsoft.com. Diesem Schalter muss der nachfolgende Dienst vertrauen. Es muss daher in jeder ARC-Prüfinstanz eine Liste mit Domains existieren, denen der Verwender vertraut.

Was haben Sie davon, wenn Sie die angesprochenen Technologien einsetzen?

Die erste Antwort auf die Frage, warum man sich um die Absenderreputation umfänglich kümmern muss, ist die Zustellqualität der eigenen E-Mails. Wie im Abschnitt „IP-Adresse“ schon kurz angedeutet, sind die Sicherheitsmechanismen im Bereich E-Mail in den letzten Jahren deutlich strenger geworden. E-Mails, die von einer dynamischen IP-Adresse verschickt werden, werden in aller Regel vom empfangenden Server abgelehnt. Auch die Überprüfung des RDNS-Eintrags einer IP-Adresse gehört zum guten Ton in der Spam-Prüfung.

Hat man die Hygiene der IP-Adresse auf das geforderte Niveau gebracht, gilt es SPF, DKIM und DMARC anzugehen. Es ist hinlänglich bekannt, dass E-Mails an Postfächer in Microsofts M365-Dienst pauschal in den Junk-Mail-Ordner des Empfängers, oder schlimmer, in die zentrale Quarantäne eingeordnet werden, wenn sie nicht mit einem der drei Verfahren authentifiziert werden konnte.

Aber nicht nur Microsoft agiert auf diese Art und Weise, etliche andere große E-Mail-Provider folgen diesem Beispiel. Es wäre also ärgerlich, wenn Ihre E-Mail aufgrund der fehlenden Mechanismen nicht direkt im Posteingang des Empfängers landet und damit wahrscheinlich unbeachtet bleibt.

Dass man mit fehlenden SPF, DKIM und DMARC Einträgen den „Bösen“ hinterherhängt, ist ein weiteres, durchaus schlagkräftiges Argument. Die Anzahl der Spam- und Virenmails, die mindestens ein Authentifizierungsmerkmal aufweisen, ist in der letzten Zeit deutlich gestiegen. Die Analysten aus dem NoSpamProxy-Team haben herausgefunden, dass mittlerweile 4 von 10 Spam- oder Virus-Mails mittels SPF authentifiziert sind. DKIM nutzt immerhin jede fünfte schadhafte E-Mail. Die Einführung der genannten Technologien ist längst nichts mehr, womit man sich hervorheben kann, sie ist zur Pflicht geworden.

NoSpamProxy und Vertical lassen Sie bei der Einführung dieser Technologien aber nicht alleine. Wir sind stets an Ihrer Seite und beraten Sie im Vorfeld, genauso wie bei der Implementierung und im Laufenden Betrieb.