E-Mail-Header-Analyse

Was ein E-Mail-Header zeigen kann – und was nicht

Internet-E-Mails bestehen aus benannten Headerfeldern, einer Leerzeile und dem Nachrichtentext. RFC 5322 definiert das Nachrichtenformat einschließlich der Feldfaltung: Eine mit Leerraum beginnende Zeile setzt das vorherige Feld fort. Der Analysator entfaltet solche Fortsetzungen vor der Auswertung. Er beendet die Analyse an der ersten Leerzeile; Nachrichtentext und Anhänge werden daher nicht untersucht.

Mail Transfer Agents stellen normalerweise bei jedem Serverübergang ein Received-Feld voran. Im Rohtext stehen diese Felder deshalb vom neuesten zum ältesten. Der Bericht dreht sie zu einer beim Ursprung beginnenden Zeitleiste um. Eine Zeitdifferenz erscheint nur, wenn sich beide benachbarten Zeitstempel auswerten lassen. Eine negative Differenz wird als mögliche Uhrabweichung gemeldet und verhindert die Berechnung der gesamten Laufzeit; sie wird niemals stillschweigend auf null gesetzt.

Authentifizierungsbereich richtig lesen

RFC 8601 definiert Authentication-Results. Ein empfangendes System fügt dieses Feld hinzu, um Ergebnisse wie spf=pass, dkim=pass oder dmarc=fail festzuhalten. Der Analysator behält doppelte Authentication-Results-Felder, weil eine Nachricht mehrere Verwaltungsdomains durchlaufen kann. Zugehörige Eigenschaften wie smtp.mailfrom, header.d und header.from bleiben so erhalten, wie sie gemeldet wurden.

Eine DKIM-Signature enthält Metadaten wie signierende Domain (d=), Selektor (s=), Algorithmus (a=), Identität (i=) und große kryptografische Werte (b= und bh=). Der Bericht erfasst nützliche Tags und ob Signaturwerte vorhanden sind, lässt die Signaturblöcke im JSON-Export aber bewusst weg. Es erfolgen weder DNS-Abfragen noch kryptografische Prüfungen.

RFC 8617 definiert Authenticated Received Chain (ARC). Eine ARC-Instanz ist strukturell vollständig, wenn sie ein ARC-Seal-, ein ARC-Message-Signature- und ein ARC-Authentication-Results-Element mit demselben i=-Wert enthält. „Vollständig“ beschreibt hier nur diese drei Elemente; die Kette ist dadurch weder validiert noch vertrauenswürdig.

Beispiel für eine Route

Angenommen, der Rohtext enthält zwei Received-Felder. Das untere Feld besagt, dass ein Ursprung die Nachricht um 10:00:03 +0000 an einen Relay übergab; das obere, dass der Relay den Empfänger um 10:00:10 +0000 erreichte. Der Bericht zeigt zuerst das Ursprungsereignis und berechnet ein beobachtetes Intervall von 7 Sekunden. Zeitzonenoffsets werden berücksichtigt: Auf 10:00:03 +0000 folgt bei 12:00:06 +0200 ein Abstand von 3 Sekunden, nicht zwei Stunden. Liegt der zweite normalisierte Zeitstempel fünf Sekunden früher, meldet der Bericht eine Uhrabweichung und lässt die Gesamtdauer offen.

Vertrauensgrenzen und häufige Fallstricke

RFC 5321 beschreibt den SMTP-Transport und die von Servern ergänzten Trace-Informationen. Header von außerhalb eines vertrauenswürdigen Mailsystems können frei erfunden sein. Beginnen Sie die Vertrauenskette bei einem Empfänger, den Sie kontrollieren, und gehen Sie nur so weit zurück, wie dessen Protokolle und Richtlinien es rechtfertigen. Unterschiedliche Domains in sichtbarem From und Return-Path sind bei Mailinglisten, Weiterleitungsdiensten und Transaktionsplattformen üblich; es handelt sich um eine Beobachtung, nicht um einen Nachweis für Identitätsmissbrauch.

Kodierte Betreffzeilen und Anzeigenamen können RFC-2047-codierte Wörter verwenden. Der Analysator decodiert gängige Base64- und Quoted-Printable-Formen in UTF-8, ISO-8859-1 und Windows-1252; nicht unterstützte Kodierungen bleiben mit einem Hinweis sichtbar. Sehr große Feld- und Stationssammlungen werden begrenzt, damit der Browser reagiert. Bewahren Sie für eine Vorfallanalyse die Originalnachricht separat auf: Die Exporte sind kompakte Berichte und enthalten absichtlich weder Rohdaten noch Nachrichtentext, Anhänge oder DKIM-Signaturblöcke.

Datenschutz und Exporte

Auswertung, Auswahl, Kopieren und Exporterstellung erfolgen lokal im aktuellen Tab. Funnel-Schritte verwenden tabgebundenen Sitzungsspeicher statt einer URL; rohe Headerdaten werden weder über Livewire gesendet noch in Navigationsparametern offengelegt. Die Eingabe ist auf 512 KiB begrenzt. Die Zeitleisten-CSV verwendet UTF-8 mit Byte Order Mark und CRLF-Zeilen; Zellen, die mit Tabellenformelzeichen beginnen, werden neutralisiert. JSON enthält die ausgelesenen Beobachtungen und den Berichtshinweis, nicht den Originalheader.