Die Naivität des Internets: Wie SMTP die E-Mail für Jahrzehnte zur Sicherheitskatastrophe machte

Autor: DerSchneider

Einleitung

Früher konnte jeder eine E-Mail verschicken, die aussah, als käme sie direkt von der Bundeskanzlerin. Mit drei Terminal-Befehlen war eine Nachricht im Namen von chef@apple.com unterwegs – und viele Mailserver stellten sie anstandslos zu. Was heute wie ein Albtraum für jede Compliance-Abteilung klingt, war jahrzehntelang der Normalzustand des Internets. Die Wurzel des Übels: das Simple Mail Transfer Protocol (SMTP), ein Protokoll, das in einer Zeit entworfen wurde, als das Internet ein überschaubares akademisches Netzwerk war, in dem sich alle kannten. Niemand kam auf die Idee, Absendeadressen zu fälschen – weil es schlicht keinen Grund gab.

Dieser Artikel erzählt die Geschichte einer der folgenreichsten Sicherheitslücken der Digitalisierung, ihrer jahrzehntelangen Ausbeutung und der schrittweisen, aber nie vollständig abgeschlossenen Reparatur durch drei miteinander verwobene Technologien: SPF, DKIM und DMARC. Es ist eine Geschichte über Naivität, milliardenschweren Betrug und die Erkenntnis, dass Sicherheit im Internet selten aus einem genialen Einfall besteht – sondern aus Schichten.

1. SMTP: Ein Protokoll aus der Zeit der akademischen Idylle

1.1 Die Geburtsstunde eines Klassikers

Das Simple Mail Transfer Protocol wurde im August 1982 als RFC 821 von Jonathan B. Postel standardisiert. Sein erklärtes Ziel: „to transfer mail reliably and efficiently“. Sicherheit war kein Thema. Authentifizierung? Fehlanzeige. Verschlüsselung? Nicht vorgesehen. Das Protokoll reflektierte die Welt, in der es entstand: das ARPANET, ein Netzwerk von Universitäten und Forschungseinrichtungen, in dem die Teilnehmer einander kannten und vertrauten.

Diese Vertrauensseligkeit ist der Grund, warum SMTP bis heute als „naivstes Protokoll des Internets“ gilt. Es legt keinen Authentifizierungsmechanismus fest – und öffnete damit Fälschern und Spammern grundsätzlich Tür und Tor.

1.2 Die fatale Trennung: Envelope Sender vs. From-Header

Um zu verstehen, warum SMTP so leicht zu missbrauchen ist, muss man zwei Konzepte unterscheiden, die die meisten Menschen nicht auseinanderhalten:

Diese beiden Felder sind vollständig voneinander unabhängig. Ein Angreifer kann eine E-Mail mit dem Envelope Sender angreifer@evil.com verschicken, aber im From-Header ceo@apple.com eintragen. Der Empfänger sieht ceo@apple.com – und der Mailserver sagt nichts dagegen. Diese Unabhängigkeit ist das Kernproblem, das jahrzehntelang ausgenutzt wurde.

1.3 Die Kosten der Naivität

Die Folgen waren verheerend. Phishing, CEO Fraud, Business Email Compromise – alles Angriffsformen, die auf der Fälschung von Absenderadressen basieren. Die Schäden gehen in die Milliarden. Und das alles, weil ein Protokoll aus dem Jahr 1982 einfach jedem glaubte, der eine E-Mail verschicken wollte.

2. SPF: Der erste Schritt aus der Naivität

2.1 Die Idee: Wer darf in meinem Namen sprechen?

Das Sender Policy Framework (SPF) war der erste ernsthafte Versuch, das Problem der gefälschten Absenderadressen zu lösen. Die Grundidee ist elegant: Eine Domain kann im DNS (Domain Name System) hinterlegen, welche Mailserver überhaupt berechtigt sind, E-Mails in ihrem Namen zu verschicken.

Ein SPF-Eintrag für apple.com könnte beispielsweise festlegen: „E-Mails von uns kommen nur von diesen fünf Servern“. Wenn nun eine E-Mail behauptet, von apple.com zu kommen, aber von einem Server irgendwo anders abgeschickt wird, schlägt die SPF-Prüfung fehl.

2.2 Die Geschichte eines langen Weges

Die erste öffentliche Erwähnung des Konzepts gab es bereits im Jahr 2000, blieb aber weitgehend unbeachtet. 2002 veröffentlichte Dana Valerie Reese eine erste SPF-ähnliche Spezifikation, am nächsten Tag folgte Paul Vixie mit seiner eigenen Version. Diese Posts entfachten großes Interesse und führten zur Gründung der IETF Anti-Spam Research Group. 2014 wurde SPF schließlich als RFC 7208 als „proposed standard“ veröffentlicht.

2.3 Die Schwäche von SPF

SPF hat eine frühe Schwäche, die man kennen muss: Es prüft nur den Envelope Sender, also den technischen Absender auf Protokollebene – nicht den From-Header, den der Empfänger sieht. Ein Angreifer konnte also weiterhin einen gefälschten From-Header verwenden, solange der Envelope Sender von einer IP kam, die für die Absenderdomain autorisiert war. SPF allein war kein vollständiger Schutz.

3. DKIM: Kryptografie für die E-Mail

3.1 Digitale Unterschriften für Nachrichten

DomainKeys Identified Mail (DKIM) ging einen Schritt weiter. Statt sich auf IP-Adressen zu verlassen, setzt DKIM auf asymmetrische Kryptografie. Der sendende Mailserver signiert die E-Mail mit einem privaten Schlüssel – einem geheimen kryptografischen Wert, den nur dieser Server kennt. Den zugehörigen öffentlichen Schlüssel veröffentlicht die Domain im DNS.

Wenn der empfangende Server eine E-Mail bekommt, schaut er im DNS der behaupteten Absenderdomain nach, holt sich den öffentlichen Schlüssel und prüft damit die Signatur. Stimmt sie, weiß er: Diese Mail wurde tatsächlich von einem Server verschickt, der den privaten Schlüssel dieser Domain besitzt. Zusätzlich wurde die Mail auf dem Weg nicht verändert – jede nachträgliche Änderung würde die Signatur ungültig machen.

3.2 Die Entstehung eines Standards

DKIM entstand 2007 aus der Zusammenführung von Yahoos „DomainKeys“ und Ciscos „Identified Internet Mail“. Es wurde im selben Jahr als RFC 4871 standardisiert, im September 2011 in RFC 6376 aktualisiert und mit den RFCs 8301 sowie 8463 weiter verfeinert. Die Entwicklung war das Ergebnis einer einjährigen Zusammenarbeit zahlreicher Branchenakteure, darunter AOL, Google, Microsoft und Yahoo.

3.3 Der Vorteil gegenüber SPF

DKIM ist nicht IP-basiert. Jedes beliebige System im Internet kann im Namen einer Senderdomain senden, solange sein kryptografischer Schlüssel im DNS der Senderdomain hinterlegt ist. Anders als SPF bleibt die DKIM-Signatur auch bei Weiterleitungen gültig, solange der Nachrichteninhalt und die signierten Header unverändert bleiben. Das macht DKIM besonders wertvoll für Mailinglisten und komplexe E-Mail-Routen.

4. DMARC: Die Klammer, die alles zusammenhält

4.1 Das Problem der fehlenden Policy

SPF und DKIM waren gute Schritte, aber sie lösten das Problem nicht vollständig. Sie sagten dem empfangenden Server zwar, ob etwas stimmt oder nicht – aber sie sagten ihm nicht, was er im Fehlerfall tun soll. Und sie schlossen immer noch nicht die Lücke zwischen dem technischen Absender und dem sichtbaren From-Header.

Genau hier kommt DMARC ins Spiel. Domain-based Message Authentication, Reporting and Conformance – sperrig, aber jeder Teil des Namens ist wichtig.

4.2 Die drei Säulen von DMARC

DMARC tut drei Dinge:

1. Richtlinie: Es legt fest, was mit einer Mail passiert, die SPF oder DKIM nicht besteht. Die Domain kann sagen: „Schickt diese E-Mail in Quarantäne (Spamordner)“ oder „Lehnt sie komplett ab“.
2. Ausrichtungsprüfung (Alignment): DMARC erzwingt, dass der sichtbare From-Header zur Domain passen muss, die entweder SPF oder DKIM verifiziert haben. Damit wird die alte Lücke zwischen Envelope Sender und From-Header geschlossen.
3. Berichte: Domaininhaber bekommen regelmäßig Berichte darüber, wer versucht hat, in ihrem Namen Mails zu verschicken. Das gibt Unternehmen Sichtbarkeit darüber, ob ihre Domains aktiv missbraucht werden.

4.3 Die Geburt eines Standards

Die Entwicklung von DMARC begann 2010, als sich fünfzehn führende Unternehmen – darunter PayPal, Microsoft, Google und Yahoo – zusammenschlossen, um ein Protokoll gegen betrügerische E-Mails zu entwickeln. Die erste DMARC-Spezifikation wurde am 30. Januar 2012 veröffentlicht.

DMARC kombiniert also zwei bestehende Technologien (SPF und DKIM) zu einem kohärenten Regelwerk. Es gibt Domaininhabern echte Kontrolle darüber, was mit gefälschten Mails in ihrem Namen passiert.

5. Die drei Protokolle im Zusammenspiel

5.1 Ein Stufenmodell der Sicherheit

Die drei Protokolle bauen aufeinander auf und bilden gemeinsam das Rückgrat der modernen E-Mail-Authentifizierung:

Die Botschaft ist klar: Sicherheit im Internet funktioniert nicht durch einen einzigen genialen Einfall, sondern durch Schichten.

5.2 Was heute noch schiefgehen kann

Trotz dieser drei Schutzmechanismen ist die E-Mail-Sicherheit nicht perfekt. Angreifer nutzen weiterhin:

• Typosquatting: Domainnamen, die wie gmail.com aussehen, aber gmall.com heißen.
• Internationalisierte Domainnamen (IDN): Zeichen aus anderen Schriftsystemen, die identisch aussehen (z.B. kyrillisches „а“ vs. lateinisches „a“).
• SMTP Smuggling: Schwachstellen in SMTP-Servern, die es erlauben, E-Mails mit gefälschten Adressen zu verschicken.

6. Fazit und Ausblick: Von der Naivität zur Verantwortung

Die Geschichte der E-Mail-Sicherheit ist eine Geschichte der nachträglichen Reparatur. Ein Protokoll aus dem Jahr 1982, entworfen für eine Welt des Vertrauens, wurde über vier Jahrzehnte hinweg mit Sicherheitsmechanismen überzogen, die es nie vorgesehen hatte. SPF, DKIM und DMARC sind keine genialen Würfe aus einer Hand – sie sind das Ergebnis von jahrelanger Arbeit, von Branchenkonsortien und von der schmerzhaften Erkenntnis, dass das Internet kein geschlossener akademischer Raum mehr ist.

Dennoch: Die Reparatur ist nicht abgeschlossen. Die Einführung von DMARC verlief lange Zeit schleppend. Erst in den letzten Jahren haben große E-Mail-Anbieter wie Google und Yahoo begonnen, strengere Richtlinien durchzusetzen. Und Angreifer finden immer neue Wege, die verbleibenden Lücken zu missbrauchen.

Was bleibt, ist eine Erkenntnis, die weit über die E-Mail hinausgeht: Sicherheit muss von Anfang an mitgedacht werden. Nachträgliche Flickwerk ist möglich, aber es ist teuer, komplex und nie vollständig. Das naive Protokoll von 1982 hat uns das auf schmerzhafte Weise gelehrt.

Quellen

1. Postel, J. (1982). Simple Mail Transfer Protocol. RFC 821. Internet Engineering Task Force. https://www.rfc-editor.org/info/rfc821 
2. Email (in)security. (2020). CYLAB. https://cylab.be/blog/60/email-insecurity 
3. Hintergrund: Sicherheitslücken beim Mail-Transfer via SMTP. (2000). Heise Online. 
4. Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. RFC 7208. Internet Engineering Task Force. 
5. DomainKeys Identified Mail (DKIM) Signatures. RFC 6376. Internet Engineering Task Force. 
6. Domain-based Message Authentication, Reporting, and Conformance (DMARC). RFC 7489. Internet Engineering Task Force. 
7. What is DMARC? – A Bit of History. (2025). EasyDMARC. https://easydmarc.com/blog/what-is-dmarc-a-bit-of-history/ 
8. Die Geschichte von DMARC. (2025). Skysnag. https://www.skysnag.com/de/blog/history-of-dmarc-email-authentication/ 
9. DomainKeys Identified Mail (DKIM). eco – Verband der Internetwirtschaft. https://www.eco.de/download/260129/ 
10. Sender Policy Framework. Wikipedia. https://en.m.wikipedia.org/wiki/Sender_policy_framework