Zusammenfassung

  • Keith Moores RFC 2047 definiert eine eng begrenzte ASCII-Darstellung für Nicht-ASCII-Text an bestimmten Stellen von E-Mail-Kopfzeilen; Adressgrammatik und Authentifizierung bleiben davon unberührt.
  • Belastbare Auswertung trennt Rohkopf, Feldstruktur, Charset-Decodierung, angezeigten Namen, addr-spec, DKIM-Abdeckung und Signierdomain, statt sie zu einer Identitätsaussage zu verschmelzen.

Ein Softwarewechsel kann die sichtbare Vergangenheit verändern, ohne ein einziges Byte der archivierten Nachricht anzutasten. Der alte Client zeigte kryptische ASCII-Zeichen, der neue einen sauber gesetzten Namen. Wer nur die beiden Bildschirmansichten vergleicht, könnte eine Änderung am Absender vermuten. Tatsächlich hat sich womöglich nur die Decodier- oder Darstellungsregel geändert.

Für genau diese Repräsentationsgrenze veröffentlichte Keith Moore 1996 RFC 2047. Das Dokument führte encoded-words ein: in ASCII transportierbare Einheiten, die ein Charset, das Verfahren Q oder B und codierten Text benennen. Dadurch ließen sich etwa Namen und Betreffzeilen mit Zeichen außerhalb von ASCII über bestehende Nachrichteninfrastruktur übermitteln. Die RFC war weder Moores alleinige Erfindung von MIME noch ein Verfahren zur Absenderbeglaubigung. Ihr Wert lag in einer präzisen Erweiterung mit präzisen Grenzen.

Ein Encoded Word darf höchstens 75 Zeichen umfassen; für Kopfzeilen gilt die im Dokument behandelte Grenze von 76 Zeichen. Lange sichtbare Texte können deshalb auf mehrere Einheiten verteilt sein. Linearer Leerraum zwischen direkt benachbarten Encoded Words darf bei der Anzeige verschwinden. Trotzdem ist jede Einheit selbständig. Ein Decoder soll keinen verborgenen Zeichensatz- oder Codierzustand von einer Einheit zur nächsten fortschreiben.

Entscheidend ist, wann decodiert wird. Zuerst muss ein Feld nach seiner eigenen Syntax geparst werden. Erst danach dürfen an den von RFC 2047 vorgesehenen Positionen Encoded Words erkannt und für die Anzeige umgewandelt werden. Zulässig sind sie im Text bestimmter unstrukturierter Felder, in Kommentaren sowie als Wörter einer Phrase. Unzulässig sind sie innerhalb eines addr-spec, innerhalb eines bereits zitierten Strings, in Received-Feldern, in MIME-Parametern und in anderen nicht freigegebenen strukturierten Positionen.

Diese Reihenfolge schützt die Struktur. Enthält das decodierte Ergebnis ein @-Zeichen, einen Doppelpunkt oder Anführungszeichen, werden diese Zeichen nicht erneut als Kopfzeilensyntax interpretiert. Der Parser hat die Position bereits bestimmt; das Resultat ist dort Anzeigetext. Wer erst flächig decodiert und anschließend neu parst, lässt die Präsentationsschicht nachträglich die Nachrichtengrammatik umschreiben.

Der vollständige Weg beginnt bei den Rohbytes. Es folgen Feldgrenzen und Tokens, Charset und Transferdarstellung, decodierte Bytes, Unicode-Codepoints und Normalisierung sowie schließlich Layout und Schrift. Eine Änderung an jeder dieser Stufen kann einen anderen sichtbaren Namen ergeben. Deshalb ist ein aktueller Screenshot kein belastbarer Beleg dafür, wie ein historischer Client die Nachricht darstellte.

Fehlt das Charset, ist es unbekannt oder ist die Syntax fehlerhaft, reagieren Programme unterschiedlich. Sie können den Rohtext zeigen, Ersatzzeichen einsetzen, vorsichtig reparieren oder die Darstellung ablehnen. Forensische Wiederholbarkeit verlangt daher neben der Originalkopfzeile auch Clientversion, Decodierpolitik, Normalisierung und das tatsächlich gerenderte Ergebnis.

RFC 5322 hält die nächste Grenze fest. Ein Mailbox-Ausdruck kann einen menschenlesbaren display-name und einen addr-spec besitzen, der Mailbox und Domain syntaktisch bezeichnet. Der Anzeigename ist nicht die Adresse. Auch die formalen Rollen von From und Sender beschreiben den Aufbau einer Nachricht; ihre bloße Anwesenheit authentifiziert weder eine Person noch die Kontrolle über eine Mailbox.

RFC 6532 erlaubt in internationalisierten Umgebungen UTF-8 direkt in Kopfzeilen und empfiehlt NFC-Normalisierung. Das reduziert in manchen Fällen den Bedarf an Encoded Words, hebt die Trennung aber nicht auf. Visuell ähnliche Zeichen können aus unterschiedlichen Codepoints bestehen, und kanonisch verwandte Sequenzen können verschieden gespeichert sein. Normalisierung verbessert den Vergleich. Sie verleiht einem Namen keine Autorität.

DKIM liegt nochmals auf einer anderen Ebene. RFC 6376 signiert einen kanonisierten Nachrichtenkörper und ausgewählte Kopfzeilen. Die Signing Domain Identifier, SDID, benennt die Domain, die für die überprüfbare Signatur einsteht. Eine gültige Signatur macht den sichtbaren Namen nicht zur verifizierten Person. Sie garantiert nicht, dass jedes sichtbare Feld signiert wurde, und sie beweist nicht, dass die Domain im angezeigten From mit der Signierdomain identisch ist.

Darum muss die erste Frage nach einem grünen Prüfergebnis lauten: Welche Kopfzeilen und welche kanonisierten Bytes waren erfasst? Eine belastbare Beweiskette bewahrt Rohkopf, Parsing-Ergebnis, erlaubte Encoded-Word-Positionen, Charset und Verfahren, decodierte Bytes, Codepoints und Normalisierung, Anzeigename und addr-spec, signierte Feldliste, kryptografisches Ergebnis, SDID und UI-Transformation. Keine einzelne Schicht darf für die anderen sprechen.

Moores Beitrag bleibt aktuell, weil er Lesbarkeit ermöglichte, ohne Repräsentation mit Identität gleichzusetzen. Das Encoded Word kann ändern, was auf dem Bildschirm steht. Es kann nicht allein ändern, wer eine Mailbox beherrscht, welche Domain Verantwortung übernimmt oder welchem Menschen zu vertrauen ist.

Quellen