Tiefenanalyse von E-Mail-Adressen

• E-Mail-Adressen sind nicht bloß eine Kombination aus Benutzername und Domain, sondern ein System mit komplexen in RFC-Standards definierten Strukturen, Regeln und Sicherheitsfallen
• Im lokalen Teil (vor dem @) gibt es verschiedene gültige Formate, die allgemein kaum bekannt sind, darunter Anführungszeichen-Formate, Kommentare und Unicode; in den meisten realen Umgebungen werden sie jedoch nicht unterstützt
• Jede E-Mail hat zwei Absenderadressen: den Envelope Sender und den From-Header, und dieser Unterschied ist die grundlegende Ursache von Spoofing und Phishing
• Gmails Punkt-ignorierende Richtlinie, Plus-Adressierung und Domain-Aliase sowie andere anbieterspezifische Besonderheiten wirken sich direkt auf Sicherheit und Validierung aus
• Beim Aufbau von Systemen zum Sammeln oder Prüfen von E-Mail-Adressen ist es unerlässlich, die Lücke zwischen RFC-Standard und realem Verhalten genau zu verstehen

---

Grundstruktur

• Eine E-Mail-Adresse besteht aus drei Teilen: lokaler Teil (vor dem @), @ als Trennzeichen und Domain (nach dem @)
• Sie wirkt auf den ersten Blick einfach, doch in jedem Teil gibt es Regeln und Edge Cases, die Sicherheit, Privatsphäre und Validierung beeinflussen

Lokaler Teil (Local Part)

• Erlaubte Zeichen

  • Im standardmäßigen nicht in Anführungszeichen gesetzten Format (dot-atom) sind folgende Zeichen erlaubt: Buchstaben a-z, A-Z, Ziffern 0-9, Sonderzeichen . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • Die maximale Länge beträgt 64 Oktette (octets); bei Standard-ASCII entspricht das 64 Zeichen, bei Unicode im lokalen Teil entsteht jedoch ein Unterschied
    • Ein Oktett bezeichnet exakt eine 8-Bit-Gruppe und wird im Networking (IPv4) verwendet, um den Bereich 0–255 darzustellen
    • 64 Oktette entsprechen einem Datenblock von 512 Bit Länge

• Groß-/Kleinschreibung

  • Laut RFC 5321 ist der lokale Teil technisch gesehen case-sensitive, sodass [e-mail] und [e-mail] unterschiedliche Postfächer sein können
  • In der Praxis unterscheiden jedoch alle großen E-Mail-Anbieter nicht nach Groß- und Kleinschreibung, daher ist es ein sicherer Standard, vor dem Speichern oder Vergleichen auf Kleinbuchstaben zu normalisieren
  • Der Domain-Teil ist niemals case-sensitive

• Punkt-Adressierung

  • Punkte sind im lokalen Teil erlaubt, es gibt jedoch drei Einschränkungen: kein Punkt am Anfang, kein Punkt am Ende und keine aufeinanderfolgenden Punkte
  • Gmails Punkt-Normalisierung: Gmail ignoriert Punkte im lokalen Teil vollständig, sodass [e-mail], [e-mail] und [e-mail] alle im selben Posteingang landen
    • Kein RFC-Standard, sondern Gmail-spezifisches Verhalten
    • Ein realer Angriffsvektor, bei dem Angreifer mit punkt-variierenden Adressen separate Konten anlegen können, um Beschränkungen auf ein einzelnes Konto zu umgehen oder kostenlose Testphasen mehrfach zu erhalten

• Subadressierung (Plus-Adressierung)

  • Mithilfe eines Trennzeichens kann dem lokalen Teil ein Tag hinzugefügt werden; der Mailserver leitet dann an die Basisadresse zu und behält das Tag bei (RFC 5233)
  • Das häufigste Trennzeichen ist +; unterstützt unter anderem von Gmail, Outlook, ProtonMail und Fastmail
    • In einigen Yahoo-Konfigurationen und bestimmten Postfix-Setups wird - verwendet
    • Bei qmail ist = das Standardtrennzeichen, was erklärt, warum in VERP @ als = kodiert wird
  • Wichtige Anwendungsfälle:
    • Leak-Tracking: Registrierung mit einem dienstspezifischen Tag (z. B. [e-mail]), um bei Spam-Eingang die Quelle eines Leaks zu erkennen
    • Posteingangsfilterung: automatische Sortierung von E-Mails an bestimmte Tag-Adressen mithilfe von Mail-Regeln
    • Mehrere Konten: Bei Diensten, die das Pluszeichen nicht normalisieren, lassen sich mit einer E-Mail mehrere getrennte Konten anlegen
  • Viele E-Mail-Validatoren auf Websites lehnen + ab, doch das ist ein Bug im Validierungscode und keine Einschränkung der E-Mail selbst

• Quoted-String-Format

  • Wird der lokale Teil in doppelte Anführungszeichen gesetzt, werden die meisten Zeichenbeschränkungen gelockert, sodass Leerzeichen, @, aufeinanderfolgende Punkte sowie führende oder abschließende Punkte erlaubt sind
  • Beispiele: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • Praktisch alle E-Mail-Anbieter akzeptieren lokale Teile in Anführungszeichen jedoch nicht, daher laut RFC gültig, in der Praxis aber nutzlos

• Kommentare (Comments)

  • Kommentare in Klammern können am Anfang oder Ende des lokalen Teils stehen; der Mailserver entfernt sie, ohne dass dies die Zustellung beeinflusst
  • Nach RFC 5322 technisch gültig, heute jedoch nicht mehr in Gebrauch
  • Validatoren, die Klammern ablehnen, sind strenger als RFC-konform

• Unicode im lokalen Teil (EAI)

  • Die in RFC 6530, 6531 und 6532 definierte Internationalisierung von E-Mail-Adressen (EAI) erlaubt UTF-8-Zeichen im lokalen Teil
  • In der SMTP-Sitzung muss die Erweiterung SMTPUTF8 verwendet werden, und sowohl sendender als auch empfangender Server müssen sie unterstützen
  • Stand 2026 ist die Verbreitung begrenzt; da Unicode-Zeichen 2 bis 4 Oktette belegen, kann die Grenze von 64 Oktetten schon vor 64 sichtbaren Zeichen erreicht werden

• Historische Formate

  • Bang Path (UUCP): Eine Routing-Methode aus der Zeit vor DNS in Netzwerken per Modem verbundener Unix-Maschinen, bei der mit ! getrennte Hostnamenpfade (machine1!machine2!user) verwendet wurden; deshalb ist ! in der Liste erlaubter Zeichen enthalten. Heute vollständig außer Gebrauch
  • Percent Hack: Ein Relay-Routing-Trick in der Form [e-mail]; das Zeichen % bleibt im lokalen Teil weiterhin gültig, obwohl dieser Routing-Mechanismus in RFC 5321 abgeschafft wurde
  • Source Routing: Eine explizite Liste von Relay-Hops im SMTP-Befehl RCPT TO (@relay1,@relay2:user@domain). In RFC 5321 abgeschafft

• VERP (Variable Envelope Return Path)

  • Eine Technik in Massenmail-Systemen, um den genauen Empfänger nachzuverfolgen, der einen Bounce ausgelöst hat
  • Dabei wird die Empfängeradresse in den Envelope Sender (MAIL FROM) kodiert, wobei @ der Empfängeradresse durch = ersetzt wird
    • Beispiel: bounces+alice=[e-mail]
  • Mailchimp, SendGrid und Amazon SES verwenden VERP oder Varianten davon für Bounce-Verarbeitung in großem Maßstab

• SRS (Sender Rewriting Scheme)

  • Ein Adressformat, das erscheint, wenn ein Server beim Weiterleiten von E-Mails den Envelope Sender umschreibt, damit SPF-Prüfungen bestehen
  • Form: SRS0=HASH=TT=originaldomain.com=[e-mail]
  • Bei Weiterleitung über mehrere Hops: SRS1=HASH=[e-mail]
  • Eine strukturell gültige E-Mail-Adresse, aber ein Artefakt der Infrastruktur und keine von Menschen verwendete Adresse
  • Die HASH-Komponente ist ein HMAC über Zeitstempel und Ursprungsadresse und dient dazu, Fälschungen zu verhindern sowie die Gültigkeitsdauer des Tokens zu begrenzen

Domain-Teil (Domain Part)

• Regeln für Labels

  • Eine Domain besteht aus durch Punkte getrennten Labels; in jedem Label sind die lateinischen Buchstaben a-z, Ziffern 0-9 und der Bindestrich - erlaubt.
  • Ein Label darf nicht mit einem Bindestrich beginnen oder enden, und auf der 3. bis 4. Position sind keine aufeinanderfolgenden Bindestriche erlaubt (Ausnahme: Punycode-Labels, die mit xn-- beginnen).
  • Ein Label darf maximal 63 Zeichen lang sein, die gesamte Domain maximal 253 Zeichen, und die gesamte E-Mail-Adresse (addr-spec) maximal 254 Zeichen.

• Subdomains

  • Eine Domain kann mehrere Ebenen haben; abgesehen von der Gesamtlänge der Domain von 253 Zeichen gibt es keine harte technische Begrenzung für die Tiefe von Subdomains.
  • Übliche Verwendung: Mail-Infrastruktur (mail., smtp., mx.), organisatorische Trennung (sales.company.com), Versand durch ESPs (email.company.com)

• IP-Adress-Literale

  • Statt eines Domainnamens kann eine IP-Adresse in eckigen Klammern verwendet werden: user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • Nach RFC 5321 ist dies gültig, wird von öffentlichen Mailservern aber fast nie akzeptiert und dient für interne Mailsysteme und SMTP-Tests.

• Domains mit nur einem Label

  • Domains ohne Punkt (z. B. user@localhost) sind in manchen Kontexten technisch gültig, werden von öffentlichen Mailservern jedoch abgelehnt.
  • postmaster@localhost ist auf Unix-artigen Systemen ein konventioneller Sonderfall für lokale Systemmails.

• Internationalisierte Domainnamen (IDN) und Punycode

  • Da DNS nur ASCII unterstützt, werden Nicht-ASCII-Zeichen mit Punycode (RFC 3492) kodiert, und alle kodierten Labels beginnen mit dem Präfix xn--.
  • E-Mail-Clients zeigen die Domain in der nativen Schrift an, SMTP überträgt sie jedoch in Punycode-Form.
  • Homograph-Angriffe: Es können Domains registriert werden, die bekannten Domains ähneln, indem visuell identische Zeichen aus anderen Unicode-Schriften verwendet werden. Browser haben Schutzmechanismen, die bei verdächtigen IDNs Punycode anzeigen, aber E-Mail-Clients besitzen solche Schutzmechanismen meist nicht, wodurch der Angriff per E-Mail wirksamer ist.

• Abschließender Punkt (Trailing Dot)

  • In DNS endet jede Domain technisch mit einem abschließenden Punkt, der die Root-Zone darstellt; bei E-Mails ist dieser jedoch immer implizit und wird weggelassen.
  • Die meisten Validatoren lehnen die Form [e-mail]. ab.

• MX-Records

  • Die Domain einer E-Mail-Adresse ist nicht zwingend der Ort des Mailservers; sendende Server fragen MX-(Mail Exchanger)-DNS-Records ab, um den tatsächlichen Hostnamen des Mailservers zu ermitteln.
  • Eine niedrigere Prioritätszahl bedeutet eine höhere Priorität; wenn es überhaupt keinen MX-Record gibt, erfolgt ein Fallback auf den A-Record der Domain.
  • Falls eine Domain niemals E-Mails empfangen soll, kann ein Null-MX-Record (MX 0 .) veröffentlicht werden, um sendenden Servern explizit mitzuteilen, keine Zustellung zu versuchen (RFC 7505).

Top-Level-Domains (TLD)

• Ursprüngliche generische TLDs

  • Die 7 gTLDs des frühen Internets: .com (kommerziell, heute uneingeschränkt, betrieben von Verisign), .net (Netzwerke, uneingeschränkt), .org (Organisationen, uneingeschränkt), .edu (akkreditierte Bildungseinrichtungen in den USA, eingeschränkt), .gov (US-Regierung, eingeschränkt), .mil (US-Militär, eingeschränkt), .int (vertragsbasierte internationale Organisationen, stark eingeschränkt)
  • .arpa ist eine von der IANA verwaltete Infrastruktur-TLD, die für Reverse-DNS-Abfragen verwendet wird.

• Ländercode-TLDs (ccTLD)

  • Zweibuchstabige Codes auf Basis der Ländercodes ISO 3166-1 alpha-2, insgesamt etwa 250
  • Einige ccTLDs wurden für andere Branchen umgewidmet:
    • .io (Britisches Territorium im Indischen Ozean → Tech-Unternehmen), .tv (Tuvalu → Medien/Streaming), .ai (Anguilla → AI-Unternehmen), .co (Kolumbien → Alternative zu .com), .me (Montenegro → persönliche Websites), .ly (Libyen → URL-Shortener), .sh (St. Helena → Softwareprojekte)
  • Wer eine umgewidmete ccTLD nutzt, unterliegt technisch weiterhin der Registry-Jurisdiktion des betreffenden Landes; die Domain wird also von der Registry des Ursprungslandes und nicht von ICANN kontrolliert.

• Gesponserte TLDs (sTLD)

  • TLDs mit Sponsoring-Organisation und Zulassungsvoraussetzungen: .aero (Luftverkehr, gesponsert von SITA), .coop (Genossenschaften), .museum (Museen), .jobs (Beschäftigung), .xxx (Erwachsenenbereich), .post (Postwesen), .cat (katalanische Sprache/Kultur)

• Neue generische TLDs (seit 2012)

  • 2012 öffnete ICANN die Bewerbung für neue gTLDs; dadurch wurden mehr als 1.200 neue TLDs delegiert.
  • Wichtige Auswirkung auf die E-Mail-Validierung: Validatoren, die die TLD-Länge auf 4 bis 6 Zeichen beschränken, gehen kaputt (.photography, .international, .construction usw.).
  • Für Entwickler relevant: .app, .dev, .web, .code / kommerziell: .shop, .store, .online / Inhalte: .blog, .news, .media / Business: .tech, .agency, .cloud
  • Neue gTLDs sind wegen niedriger Registrierungsgebühren und schwacher Missbrauchsrichtlinien einiger Registries überproportional bei Spam und Phishing vertreten.

• Marken-TLDs

  • Bei der ICANN-Erweiterung 2012 beantragten große Unternehmen eigene TLDs: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • Die meisten werden nicht für öffentliche E-Mail-Adressen genutzt, sondern vor allem für interne Zwecke oder gar nicht.

• Geografische und Stadt-TLDs

  • Eigene TLDs für Städte und Regionen: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • Für die Registrierung ist in der Regel ein Nachweis der Verbindung zur jeweiligen Region erforderlich.

• Internationalisierte TLDs

  • In vielen Ländern gibt es TLDs in Nicht-ASCII-Schriften; in DNS werden sie mit Punycode kodiert.
    • .xn--p1ai (Russland, kyrillische Schrift), .xn--fiqz9s (China, vereinfachte Schriftzeichen), .xn--mgberp4a5d4ar (Saudi-Arabien, arabische Schrift), .xn--h2brj9c (Indien, Devanagari-Schrift)

• Reservierte und dokumentierte TLDs

  • TLDs, die in RFC 2606 und RFC 6761 für Tests und Dokumentation reserviert sind:
    • .test (existiert niemals im öffentlichen DNS und ist daher sicher für Softwaretests), .example (für Dokumentationsbeispiele), .invalid (wenn eine Domain sicher nicht auflösbar sein soll), .localhost (für Loopback)
  • Die IANA hat example.com, example.net und example.org für Dokumentation und Beispiele registriert, sodass sie bedenkenlos in Codebeispielen verwendet werden können, ohne dass E-Mails echte Postfächer erreichen.

• Ausgemusterte TLDs

  • ccTLDs, die nach dem Verschwinden eines Landes entfernt wurden: .yu (Jugoslawien, 2010 gelöscht), .cs (Tschechoslowakei, 1995 gelöscht), .dd (Ostdeutschland, 1990 gelöscht), .tp (Osttimor, nach Ersetzung durch .tl 2015 vollständig gelöscht)
  • Ausnahme: .su (Sowjetunion) existiert trotz der Auflösung 1991 weiterhin als aktive Domain; die IANA diskutiert seit Jahren über einen Übergang, lässt sie aber aktiv.

Second-Level-Domains bei ccTLDs

• Viele ccTLDs fügen zwischen dem registrierbaren Namen und der TLD eine funktionale Kategorie auf zweiter Ebene hinzu
  • Vereinigtes Königreich: .co.uk, .org.uk, .gov.uk / Australien: .com.au, .edu.au / Japan: .co.jp, .ac.jp / Indien: .co.in, .gov.in / Brasilien: .com.br, .gov.br
• Wenn ein E-Mail-Authentifizierungssystem die Organisationsdomäne ermitteln muss, wirkt sich das auf Validierung und Erkennung der Organisationsdomäne aus

• Public Suffix List (PSL)

  • Eine von der Community auf publicsuffix.org gepflegte Liste, die alle Domainsuffixe erfasst, unter denen Internetnutzer direkt Namen registrieren können
  • Enthält sowohl offizielle Delegierungen (.co.uk, .com.au) als auch private Registries (github.io, wordpress.com, herokuapp.com)
  • Verwendet Wildcard-Notation (z. B. *.ck), Ausnahmen werden mit ! markiert (z. B. !www.ck)
  • Wird von E-Mail-Validatoren und Spam-Filtern verwendet, um aus dem vollständigen Domain-String die Organisationsdomäne zu identifizieren
  • Kein IETF-Standard, aber der De-facto-Standard für dieses Problem

Formate von E-Mail-Adressen

• Basisadresse (Bare Address)

  • addr-spec in der Form local@domain, verwendet in SMTP-Befehlen und einfachen Kontexten

• Angle-Bracket-Format

  • In SMTP werden bei den Befehlen MAIL FROM und RCPT TO Adressen in spitze Klammern gesetzt: MAIL FROM:<[e-mail]>
  • Die spitzen Klammern sind Teil der SMTP-Befehlssyntax und nicht Teil der Adresse selbst

• Format mit Anzeigename (Display Name Format)

  • In Nachrichten-Headern (From, To, Cc) kann vor der Adresse in spitzen Klammern ein menschenlesbarer Name stehen: "John Doe" <[e-mail]>
  • Enthält der Anzeigename Sonderzeichen, sind Anführungszeichen erforderlich
  • Display-Name-Spoofing: Der Absender kann den Anzeigenamen beliebig setzen, wodurch Angriffe wie "PayPal Security <[e-mail]>" <[e-mail]> möglich sind
    • Da viele E-Mail-Clients in der Posteingangsliste nur den Anzeigenamen zeigen, ist dies eine der häufigsten Phishing-Techniken

• Gruppensyntax (Group Syntax)

  • In RFC 5322 definiertes Format für benannte Gruppen mit mehreren Empfängern: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • Muster für nicht offengelegte Empfänger: To: undisclosed-recipients:; — eine leere Gruppensyntax, bei der sich die tatsächlichen Empfänger im SMTP-Umschlag (RCPT TO) befinden und im Nachrichten-Header nicht sichtbar sind

• Kodierte Anzeigenamen

  • In älteren E-Mail-Systemen werden Nicht-ASCII-Zeichen in Anzeigenamen als RFC-2047-Encoded-Words verarbeitet: =?charset?encoding?encoded_text?=
  • Die Kodierung ist B (base64) oder Q (quoted-printable)
  • Mit moderner SMTPUTF8-Unterstützung kann UTF-8 direkt im Header ohne diesen Kodierungs-Wrapper verwendet werden

Zwei Absender in jeder E-Mail

• Envelope Sender / MAIL FROM

  • Wird im SMTP-Befehl MAIL FROM: gesetzt und ist nicht Teil des Nachrichteninhalts selbst
  • Wird für das Bounce-Routing verwendet, ist das Prüfziel bei SPF-Checks und wird vom endgültigen empfangenden Server als Return-Path:-Header gespeichert
  • Auch als envelope from, reverse path oder RFC5321.MailFrom bezeichnet

• From-Header

  • Die Adresse im From:-Header der Nachricht, die E-Mail-Clients als Absender anzeigen
  • Das Ziel, das DMARC zusammen mit SPF- oder DKIM-Alignment schützt
  • Kann vom Absender frei gesetzt werden und wird auf den meisten Mailservern nicht eindeutig verifiziert
  • Diese beiden Adressen können völlig unterschiedlich sein, und das ist ein normales und erwartbares Szenario:
    • Bei Massenversand durch einen ESP ist MAIL FROM [e-mail], der From-Header dagegen [e-mail]
    • Bei Mailinglisten ist MAIL FROM die Bounce-Adresse der Liste, der From-Header der ursprüngliche Verfasser
    • Bei E-Mail-Weiterleitung schreibt der weiterleitende Server MAIL FROM per SRS um, während der From-Header den ursprünglichen Absender beibehält
  • Wenn für eine Domain kein DMARC gilt, kann jeder Nachrichten mit einem völlig unabhängigen MAIL FROM senden und diese Domain im From-Header eintragen

• Sender-Header

  • Identifiziert den tatsächlichen Versender, wenn der eigentliche Einreicher der Nachricht von der From-Adresse abweicht: Sender: [e-mail]

• Reply-To-Header

  • Gibt an, wohin Antworten gehen sollen, und kann sich von der From-Adresse unterscheiden
  • Kann auch als Phishing-Vektor missbraucht werden: Ein Angreifer setzt From auf vertrauenswürdig wirkend und Reply-To auf seine eigene Adresse

• Null Sender

  • MAIL FROM:<> ist eine gültige und wichtige SMTP-Konstruktion; ein leerer Envelope Sender wird für Bounce-Nachrichten, automatische Antworten und Nachrichten verwendet, die nicht selbst Bounces erzeugen dürfen
  • Verhindert endlose Bounce-Schleifen, in denen zwei Systeme fortlaufend Fehlermeldungen austauschen

Rollenbasierte Adressen (Role-Based Addresses)

• Von RFC 5321 vorgeschrieben

  • postmaster@domain: Gemäß RFC 5321 muss jede Domain, die E-Mails annimmt, ohne Ausnahme E-Mails an diese Adresse akzeptieren

• Von RFC 2142 empfohlen

  • abuse@domain (Spam-/Missbrauchsmeldungen), hostmaster@domain (Verwaltung der DNS-Zone), security@domain (Offenlegung von Schwachstellen/Sicherheitsmeldungen), webmaster@domain (Probleme mit dem Webserver), noc@domain (Netzwerkbetrieb)

• Übliche Rollenadressen

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ usw.; kein offizieller Standard, aber weit verbreitet
  • Rollenadressen werden meist von mehreren Personen gemeinsam genutzt, daher können beim Versenden sensibler Informationen mehrere Teammitglieder sie einsehen
  • abuse@ und postmaster@ empfangen Beschwerde-E-Mails und sind daher Ziele für Social Engineering

• Catch-All-Adressen

  • Keine spezielle Form einer E-Mail-Adresse, sondern eine Konfiguration des Mailservers, bei der auch für Local Parts ohne eigenes Postfach die Zustellung akzeptiert wird
  • Anwendungsfälle: Tippfehler abfangen, Entwicklertests, dienstspezifische eindeutige Adressen ohne formales Alias-System erzeugen
  • Nachteile: Da an jeden Local Part zugestellt wird, führt das zu großen Spam-Mengen, und eine Validierung der Adressgültigkeit per SMTP-Probing ist nicht möglich (alle Probes erhalten eine Erfolgsantwort)

Anbieterspezifische Besonderheiten

• Gmail

  • Punkt-Normalisierung: Alle Punkte im lokalen Teil werden ignoriert
  • Plus-Addressing: Das Trennzeichen + wird unterstützt
  • @googlemail.com: historischer Alias von @gmail.com aufgrund eines Markenstreits in Deutschland und Großbritannien; beide Domains leiten an denselben Posteingang weiter
  • Zeichenbeschränkungen: Im lokalen Teil sind nur lateinische Buchstaben, Ziffern und Punkte erlaubt (einschließlich + für Plus-Addressing). Der vollständige RFC-Zeichensatz wird nicht unterstützt
  • Längenbeschränkung des lokalen Teils: mit 30 Zeichen deutlich niedriger als das RFC-Maximum von 64

• Microsoft (Outlook, Hotmail, Live)

  • Keine Punkt-Normalisierung: [e-mail] und [e-mail] sind getrennte Postfächer
  • Domain-Aliasse: @hotmail.com, @live.com und @outlook.com können bei der Alias-Konfiguration auf dasselbe Konto verweisen
  • Plus-Addressing wird unterstützt

• Apple (iCloud)

  • Domain-Aliasse: @icloud.com, @me.com und @mac.com landen im selben Posteingang (Umbenennungsverlauf des Dienstes von .mac → .me → .icloud)
  • Plus-Addressing wird unterstützt
  • Hide My Email: erzeugt zufällige Aliasse in der Form [e-mail], damit für jeden Dienst oder jede App ein eigener Alias verwendet werden kann und die echte Adresse verborgen bleibt

• ProtonMail / Proton

  • Domain-Aliasse: @proton.me, @protonmail.com und @pm.me führen zum selben Posteingang
  • Plus-Addressing wird unterstützt

• E-Mail-Alias-Dienste

  • Getrennt von Wegwerf-E-Mails gibt es Dienste, die permanente und kontrollierbare Weiterleitungsadressen erzeugen:
    • SimpleLogin (gehört zu Proton): leitet benutzerdefinierte oder zufällige Aliasse an beliebige Postfächer weiter
    • Addy.io (früher AnonAddy): ähnlich wie SimpleLogin, mit Self-Hosting-Möglichkeit
    • Firefox Relay (Mozilla): begrenzte zufällige Aliasse im kostenlosen Tarif
    • DuckDuckGo Email Protection: Aliasse mit @duck.com
  • Für Absender entstehen Adressen, die strukturell nicht von echten Postfächern zu unterscheiden sind
  • Der wesentliche Unterschied zu Wegwerf-E-Mails: Aliasse sind dauerhaft und kontrollierbar; einzelne Aliasse können deaktiviert, dienstspezifische Absender nachvollzogen und Nachrichten an beliebige Postfächer weitergeleitet werden

Wegwerf- und temporäre E-Mail-Adressen

• Sie bieten Postfächer ohne Registrierung, die meist nach kurzer Zeit ablaufen; bekannte Beispiele sind Mailinator, Guerrilla Mail, 10 Minute Mail und TempMail
• Die meisten verwenden Catch-all-Routing, sodass jeder lokale Teil unter dieser Domain im Postfach ankommt
• Viele Postfächer sind öffentlich, sodass jede Person mit Kenntnis der Adresse die Nachrichten lesen kann
• Es gibt Sperrlisten bekannter Wegwerf-Domains (am häufigsten referenziert wird das GitHub-Repository disposable-email-domains), diese sind jedoch immer unvollständig; zur Umgehung von Sperren werden fortlaufend neue Domains eingesetzt

Validierung

• Technische Gültigkeit vs. praktische Gültigkeit

  • Nach RFC gültig, aber von realen Servern fast nie akzeptiert: Leerzeichen in Anführungszeichen (" "@example.com), @ in Anführungszeichen ("user@name"@example.com), IP-Literal-Domains (user@[192.168.1.1]), einzelne Zeichen/einzelne Labels (a@b)
  • Nach RFC gültig und in der Praxis akzeptiert: [e-mail], [e-mail], [e-mail], [e-mail]
  • Für die meisten Anwendungen ist ein praktischer Validator besser als ein vollständig RFC-konformer Validator: Grundstruktur prüfen, sinnvolle Zeichensätze validieren und optional einen DNS-MX-Lookup für die Domain durchführen

• Häufige Fehler in Validatoren

  • + im lokalen Teil abgelehnt: [e-mail] ist vollkommen gültig; dies ist ein sehr häufiger Fehler
  • _ im lokalen Teil abgelehnt: ebenfalls gültig
  • % im lokalen Teil abgelehnt: ein gültiges Zeichen; veraltet ist nur die Nutzung von Percent-Hack-Routing
  • TLD-Länge auf 4 bis 6 Zeichen beschränkt: blockiert Hunderte neuer gTLDs wie .photography, .international und .construction
  • Validierung mit fest einkodierter TLD-Liste: Solche Listen ändern sich laufend, daher veralten Validatoren
  • Falsche Gesamt-Längenbeschränkung: Verwendung von 255 oder 256 statt 254. Das lange zitierte falsche Maximum 320 wurde in Erratum 1690 zu RFC 3696 auf 254 korrigiert
  • Großbuchstaben im lokalen Teil abgelehnt: nach RFC gültig
  • [e-mail] abgelehnt: gültig; Multi-Punkt-Domains mit sekundären ccTLD-Mustern sind normal
  • .dev, .app, .io als TLD abgelehnt: alle sind gültige delegierte TLDs

• Längenbeschränkungen

  Teil	Beschränkung
  Lokaler Teil	64 Oktette
  Domain-Label	63 Oktette
  Gesamte Domain	253 Oktette
  Gesamte Adresse (addr-spec)	254 Oktette

• Die Beschränkung des lokalen Teils gilt in Oktetten statt Zeichen; deshalb können EAI-Adressen mit mehrbyteigen Unicode-Zeichen optisch weniger als 64 Zeichen haben und dennoch das Oktett-Limit erreichen

• DNS-basierte Validierung

  • MX-Record-Prüfung: prüft, ob die Domain MX-Records hat; schnell und risikoarm. Domains, die auf A-Record-Fallback setzen (ohne konfigurierten MX), können diesen Test nicht bestehen
  • Null-MX-Prüfung: Hat eine Domain MX 0 ., dann empfängt sie ausdrücklich keine E-Mails
  • SMTP-RCPT-TO-Probing: verbindet sich mit dem Mailserver und sendet den Befehl RCPT TO, um zu prüfen, ob die Adresse akzeptiert wird; viele Server antworten jedoch für alle Adressen mit 250, um Address-Harvesting zu verhindern, daher ist dies nicht zuverlässig. Catch-all-Domains antworten immer positiv. Außerdem besteht das Risiko, dass die Probe-IP auf eine Blacklist gesetzt wird
  • Die einzige vollständig zuverlässige Methode zur Validierung einer E-Mail-Adresse ist es, eine echte Nachricht zu senden und den Eingang zu bestätigen; alles andere sind Heuristiken

Sicherheitsimplikationen

• Spoofing von Anzeigenamen

  • Jede Person kann den Anzeigenamen einer E-Mail frei festlegen; in Posteingangsansichten, die nur den Anzeigenamen zeigen, können Nutzer legitime Absender und Identitätsfälschungen nicht unterscheiden, solange sie nicht ausdrücklich die echte Adresse prüfen

• Homograph-Angriffe mit Punycode

  • Es ist möglich, Domains zu registrieren, die durch Zeichen aus anderen Unicode-Schriften visuell mit bekannten echten Domains identisch wirken
  • E-Mail-Clients zeigen dafür im Gegensatz zu Browsern normalerweise keine Warnung an

• Konto-Umgehung mit dem Gmail-Punkt-Trick

  • Da Gmail Punkte ignoriert, kann ein Angreifer sich mit punktierten Varianten einer bestehenden Gmail-Adresse bei Diensten registrieren und so Beschränkungen auf ein einzelnes Konto umgehen, kostenlose Testphasen mehrfach nutzen und E-Mails empfangen, die eigentlich für den ursprünglichen Kontoinhaber bestimmt sind

• Wiederverwendung von E-Mail-Adressen

  • E-Mail-Anbieter können aufgegebene Adressen neuen Nutzern neu zuweisen; der neue Kontoinhaber kann dann Passwort-Reset-Mails für Dienste empfangen, bei denen der frühere Inhaber registriert war, und so per Zurücksetzen des Passworts Konten übernehmen
  • Gmail hat erklärt, Adressen nicht neu zuzuweisen, aber einige andere Anbieter haben dies in der Vergangenheit getan

• Offenlegung von Subaddressing-Tags

  • Wer sich mit [e-mail] registriert, zeigt dem empfangenden Dienst die vollständige Adresse einschließlich des Tags
  • Dienste, die das Plus-Tag entfernen und gespeichert halten, legen die Basisadresse offen; Dienste, die die vollständige Adresse unverändert speichern, können in Kontoeinstellungen oder Datenexporten die verwendete Tracking-Strategie offenlegen