{"id":6493,"date":"2026-07-13T06:45:16","date_gmt":"2026-07-13T06:45:16","guid":{"rendered":"https:\/\/technodidact.de\/?p=6493"},"modified":"2026-07-13T06:45:17","modified_gmt":"2026-07-13T06:45:17","slug":"die-naivitaet-des-internets-wie-smtp-die-e-mail-fuer-jahrzehnte-zur-sicherheitskatastrophe-machte","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/die-naivitaet-des-internets-wie-smtp-die-e-mail-fuer-jahrzehnte-zur-sicherheitskatastrophe-machte\/","title":{"rendered":"Die Naivit\u00e4t des Internets: Wie SMTP die E-Mail f\u00fcr Jahrzehnte zur Sicherheitskatastrophe machte"},"content":{"rendered":"

Autor: DerSchneider<\/strong><\/p>\n\n\n\n

\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Fr\u00fcher konnte jeder eine E-Mail verschicken, die aussah, als k\u00e4me sie direkt von der Bundeskanzlerin. Mit drei Terminal-Befehlen war eine Nachricht im Namen von chef@apple.com<\/em> unterwegs \u2013 und viele Mailserver stellten sie anstandslos zu. Was heute wie ein Albtraum f\u00fcr jede Compliance-Abteilung klingt, war jahrzehntelang der Normalzustand des Internets. Die Wurzel des \u00dcbels: das Simple Mail Transfer Protocol (SMTP), ein Protokoll, das in einer Zeit entworfen wurde, als das Internet ein \u00fcberschaubares akademisches Netzwerk war, in dem sich alle kannten. Niemand kam auf die Idee, Absendeadressen zu f\u00e4lschen \u2013 weil es schlicht keinen Grund gab.<\/p>\n\n\n\n

Dieser Artikel erz\u00e4hlt die Geschichte einer der folgenreichsten Sicherheitsl\u00fccken der Digitalisierung, ihrer jahrzehntelangen Ausbeutung und der schrittweisen, aber nie vollst\u00e4ndig abgeschlossenen Reparatur durch drei miteinander verwobene Technologien: SPF, DKIM und DMARC. Es ist eine Geschichte \u00fcber Naivit\u00e4t, milliardenschweren Betrug und die Erkenntnis, dass Sicherheit im Internet selten aus einem genialen Einfall besteht \u2013 sondern aus Schichten.<\/p>\n\n\n\n

\n\n\n\n

1. SMTP: Ein Protokoll aus der Zeit der akademischen Idylle<\/h2>\n\n\n\n

1.1 Die Geburtsstunde eines Klassikers<\/h3>\n\n\n\n

Das Simple Mail Transfer Protocol wurde im August 1982 als RFC 821 von Jonathan B. Postel standardisiert<\/a>. Sein erkl\u00e4rtes Ziel: \u201eto transfer mail reliably and efficiently\u201c<\/em><\/a>. Sicherheit war kein Thema. Authentifizierung? Fehlanzeige. Verschl\u00fcsselung? Nicht vorgesehen. Das Protokoll reflektierte die Welt, in der es entstand: das ARPANET, ein Netzwerk von Universit\u00e4ten und Forschungseinrichtungen, in dem die Teilnehmer einander kannten und vertrauten.<\/p>\n\n\n\n

Diese Vertrauensseligkeit ist der Grund, warum SMTP bis heute als \u201enaivstes Protokoll des Internets\u201c<\/em> gilt. Es legt keinen Authentifizierungsmechanismus fest \u2013 und \u00f6ffnete damit F\u00e4lschern und Spammern grunds\u00e4tzlich T\u00fcr und Tor.<\/p>\n\n\n\n

1.2 Die fatale Trennung: Envelope Sender vs. From-Header<\/h3>\n\n\n\n

Um zu verstehen, warum SMTP so leicht zu missbrauchen ist, muss man zwei Konzepte unterscheiden, die die meisten Menschen nicht auseinanderhalten:<\/p>\n\n\n\n

Begriff<\/th>Funktion<\/th>Sichtbarkeit<\/th><\/tr><\/thead>
Envelope Sender<\/strong> (auch: MAIL FROM, Return-Path)<\/td>Technischer Absender auf Protokollebene; wird vom Mailserver verwendet, um unzustellbare Nachrichten zur\u00fcckzusenden<\/td>F\u00fcr den Empf\u00e4nger unsichtbar<\/td><\/tr>
From-Header<\/strong><\/td>Die Absenderadresse, die im Mailprogramm des Empf\u00e4ngers angezeigt wird<\/td>F\u00fcr den Empf\u00e4nger sichtbar<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Diese beiden Felder sind vollst\u00e4ndig voneinander unabh\u00e4ngig<\/a>. Ein Angreifer kann eine E-Mail mit dem Envelope Sender angreifer@evil.com<\/em> verschicken, aber im From-Header ceo@apple.com<\/em> eintragen. Der Empf\u00e4nger sieht ceo@apple.com<\/em> \u2013 und der Mailserver sagt nichts dagegen. Diese Unabh\u00e4ngigkeit ist das Kernproblem, das jahrzehntelang ausgenutzt wurde.<\/p>\n\n\n\n

1.3 Die Kosten der Naivit\u00e4t<\/h3>\n\n\n\n

Die Folgen waren verheerend. Phishing, CEO Fraud, Business Email Compromise \u2013 alles Angriffsformen, die auf der F\u00e4lschung von Absenderadressen basieren<\/a>. Die Sch\u00e4den gehen in die Milliarden. Und das alles, weil ein Protokoll aus dem Jahr 1982 einfach jedem glaubte, der eine E-Mail verschicken wollte.<\/p>\n\n\n\n

\n\n\n\n

2. SPF: Der erste Schritt aus der Naivit\u00e4t<\/h2>\n\n\n\n

2.1 Die Idee: Wer darf in meinem Namen sprechen?<\/h3>\n\n\n\n

Das Sender Policy Framework (SPF) war der erste ernsthafte Versuch, das Problem der gef\u00e4lschten Absenderadressen zu l\u00f6sen. Die Grundidee ist elegant: Eine Domain kann im DNS (Domain Name System) hinterlegen, welche Mailserver \u00fcberhaupt berechtigt sind, E-Mails in ihrem Namen zu verschicken<\/a>.<\/p>\n\n\n\n

Ein SPF-Eintrag f\u00fcr apple.com<\/a><\/em> k\u00f6nnte beispielsweise festlegen: \u201eE-Mails von uns kommen nur von diesen f\u00fcnf Servern\u201c<\/em>. Wenn nun eine E-Mail behauptet, von apple.com<\/a><\/em> zu kommen, aber von einem Server irgendwo anders abgeschickt wird, schl\u00e4gt die SPF-Pr\u00fcfung fehl.<\/p>\n\n\n\n

2.2 Die Geschichte eines langen Weges<\/h3>\n\n\n\n

Die erste \u00f6ffentliche Erw\u00e4hnung des Konzepts gab es bereits im Jahr 2000, blieb aber weitgehend unbeachtet<\/a>. 2002 ver\u00f6ffentlichte Dana Valerie Reese eine erste SPF-\u00e4hnliche Spezifikation<\/a>, am n\u00e4chsten Tag folgte Paul Vixie mit seiner eigenen Version<\/a>. Diese Posts entfachten gro\u00dfes Interesse und f\u00fchrten zur Gr\u00fcndung der IETF Anti-Spam Research Group<\/a>. 2014 wurde SPF schlie\u00dflich als RFC 7208 als \u201eproposed standard\u201c<\/em> ver\u00f6ffentlicht<\/a>.<\/p>\n\n\n\n

2.3 Die Schw\u00e4che von SPF<\/h3>\n\n\n\n

SPF hat eine fr\u00fche Schw\u00e4che, die man kennen muss: Es pr\u00fcft nur den Envelope Sender<\/strong>, also den technischen Absender auf Protokollebene \u2013 nicht den From-Header, den der Empf\u00e4nger sieht<\/a>. Ein Angreifer konnte also weiterhin einen gef\u00e4lschten From-Header verwenden, solange der Envelope Sender von einer IP kam, die f\u00fcr die Absenderdomain autorisiert war. SPF allein war kein vollst\u00e4ndiger Schutz.<\/p>\n\n\n\n

\n\n\n\n

3. DKIM: Kryptografie f\u00fcr die E-Mail<\/h2>\n\n\n\n

3.1 Digitale Unterschriften f\u00fcr Nachrichten<\/h3>\n\n\n\n

DomainKeys Identified Mail (DKIM) ging einen Schritt weiter. Statt sich auf IP-Adressen zu verlassen, setzt DKIM auf asymmetrische Kryptografie<\/strong>. Der sendende Mailserver signiert die E-Mail mit einem privaten Schl\u00fcssel<\/strong> \u2013 einem geheimen kryptografischen Wert, den nur dieser Server kennt. Den zugeh\u00f6rigen \u00f6ffentlichen Schl\u00fcssel<\/strong> ver\u00f6ffentlicht die Domain im DNS<\/a>.<\/p>\n\n\n\n

Wenn der empfangende Server eine E-Mail bekommt, schaut er im DNS der behaupteten Absenderdomain nach, holt sich den \u00f6ffentlichen Schl\u00fcssel und pr\u00fcft damit die Signatur<\/a>. Stimmt sie, wei\u00df er: Diese Mail wurde tats\u00e4chlich von einem Server verschickt, der den privaten Schl\u00fcssel dieser Domain besitzt. Zus\u00e4tzlich wurde die Mail auf dem Weg nicht ver\u00e4ndert \u2013 jede nachtr\u00e4gliche \u00c4nderung w\u00fcrde die Signatur ung\u00fcltig machen.<\/p>\n\n\n\n

3.2 Die Entstehung eines Standards<\/h3>\n\n\n\n

DKIM entstand 2007 aus der Zusammenf\u00fchrung von Yahoos \u201eDomainKeys\u201c<\/em> und Ciscos \u201eIdentified Internet Mail\u201c<\/em><\/a>. 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\u00e4hrigen Zusammenarbeit zahlreicher Branchenakteure, darunter AOL, Google, Microsoft und Yahoo.<\/p>\n\n\n\n

3.3 Der Vorteil gegen\u00fcber SPF<\/h3>\n\n\n\n

DKIM ist nicht IP-basiert<\/a>. Jedes beliebige System im Internet kann im Namen einer Senderdomain senden, solange sein kryptografischer Schl\u00fcssel im DNS der Senderdomain hinterlegt ist. Anders als SPF bleibt die DKIM-Signatur auch bei Weiterleitungen g\u00fcltig, solange der Nachrichteninhalt und die signierten Header unver\u00e4ndert bleiben<\/a>. Das macht DKIM besonders wertvoll f\u00fcr Mailinglisten und komplexe E-Mail-Routen.<\/p>\n\n\n\n

\n\n\n\n

4. DMARC: Die Klammer, die alles zusammenh\u00e4lt<\/h2>\n\n\n\n

4.1 Das Problem der fehlenden Policy<\/h3>\n\n\n\n

SPF und DKIM waren gute Schritte, aber sie l\u00f6sten das Problem nicht vollst\u00e4ndig. Sie sagten dem empfangenden Server zwar, ob etwas stimmt oder nicht \u2013 aber sie sagten ihm nicht, was er im Fehlerfall tun soll<\/strong>. Und sie schlossen immer noch nicht die L\u00fccke zwischen dem technischen Absender und dem sichtbaren From-Header.<\/p>\n\n\n\n

Genau hier kommt DMARC ins Spiel. Domain-based Message Authentication, Reporting and Conformance \u2013 sperrig, aber jeder Teil des Namens ist wichtig.<\/p>\n\n\n\n

4.2 Die drei S\u00e4ulen von DMARC<\/h3>\n\n\n\n

DMARC tut drei Dinge:<\/p>\n\n\n\n

    \n
  1. Richtlinie<\/strong>: Es legt fest, was mit einer Mail passiert, die SPF oder DKIM nicht besteht. Die Domain kann sagen:\u00a0\u201eSchickt diese E-Mail in Quarant\u00e4ne (Spamordner)\u201c<\/em>\u00a0oder\u00a0\u201eLehnt sie komplett ab\u201c<\/em>.<\/li>\n\n\n\n
  2. Ausrichtungspr\u00fcfung (Alignment)<\/strong>: DMARC erzwingt, dass der sichtbare From-Header zur Domain passen muss, die entweder SPF oder DKIM verifiziert haben. Damit wird die alte L\u00fccke zwischen Envelope Sender und From-Header geschlossen.<\/li>\n\n\n\n
  3. Berichte<\/strong>: Domaininhaber bekommen regelm\u00e4\u00dfig Berichte dar\u00fcber, wer versucht hat, in ihrem Namen Mails zu verschicken. Das gibt Unternehmen Sichtbarkeit dar\u00fcber, ob ihre Domains aktiv missbraucht werden.<\/li>\n<\/ol>\n\n\n\n

    4.3 Die Geburt eines Standards<\/h3>\n\n\n\n

    Die Entwicklung von DMARC begann 2010, als sich f\u00fcnfzehn f\u00fchrende Unternehmen<\/strong> \u2013 darunter PayPal, Microsoft, Google und Yahoo \u2013 zusammenschlossen, um ein Protokoll gegen betr\u00fcgerische E-Mails zu entwickeln<\/a>. Die erste DMARC-Spezifikation wurde am 30. Januar 2012<\/strong> ver\u00f6ffentlicht<\/a>.<\/p>\n\n\n\n

    DMARC kombiniert also zwei bestehende Technologien (SPF und DKIM) zu einem koh\u00e4renten Regelwerk. Es gibt Domaininhabern echte Kontrolle dar\u00fcber, was mit gef\u00e4lschten Mails in ihrem Namen passiert.<\/p>\n\n\n\n

    \n\n\n\n

    5. Die drei Protokolle im Zusammenspiel<\/h2>\n\n\n\n

    5.1 Ein Stufenmodell der Sicherheit<\/h3>\n\n\n\n

    Die drei Protokolle bauen aufeinander auf und bilden gemeinsam das R\u00fcckgrat der modernen E-Mail-Authentifizierung:<\/p>\n\n\n\n

    Protokoll<\/th>Funktion<\/th>Schw\u00e4che allein<\/th><\/tr><\/thead>
    SPF<\/strong><\/td>IP-basierte Autorisierung des Envelope Senders<\/td>Pr\u00fcft nicht den From-Header<\/td><\/tr>
    DKIM<\/strong><\/td>Kryptografische Signatur der Nachricht<\/td>Sagt nicht, was im Fehlerfall zu tun ist<\/td><\/tr>
    DMARC<\/strong><\/td>Policy + Alignment + Reporting<\/td>Setzt SPF und DKIM voraus<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Die Botschaft ist klar: Sicherheit im Internet funktioniert nicht durch einen einzigen genialen Einfall, sondern durch Schichten.<\/strong><\/p>\n\n\n\n

    5.2 Was heute noch schiefgehen kann<\/h3>\n\n\n\n

    Trotz dieser drei Schutzmechanismen ist die E-Mail-Sicherheit nicht perfekt. Angreifer nutzen weiterhin:<\/p>\n\n\n\n