EML-/MIME-Importprüfung
Füge den Rohinhalt einer .eml-Nachricht (RFC 822/MIME) ein oder wähle eine .eml-Datei. Erkenne Strukturen, die sich zwischen Clients und Importwerkzeugen wie Outlook, Gmail-Import, Apple Mail, Thunderbird und generischen IMAP-Tools unterschiedlich verhalten können.
Die Verarbeitung erfolgt lokal in Ihrem Browser. Ihre Datei wird niemals hochgeladen.
Anleitung Tool
- Füge .eml-Inhalt ein oder wähle eine Datei. Die Analyse bleibt im Browser; der Inhalt wird nicht hochgeladen.
- Starte die Importkompatibilitätsprüfung.
- Prüfe markierte Strukturen und betroffene Clients/Importer.
- Sichere mechanische Vorschläge sind etwa CRLF-Zeilenenden und RFC-2047-Kodierung. Andere Probleme werden erläutert statt geraten.
Annahmen
- Geprüft werden acht Fälle: fehlende/fehlerhafte Multipart-Grenzen, fehlendes MIME-Version-Feld in MIME-Nachrichten, nicht passende Content-Transfer-Encoding, unkodierte Nicht-ASCII-Headerwerte, RFC-5322-Zeilen über 998 Oktetten, LF ohne CR, doppelte kritische Header und schwache Boundary-Zeichenfolgen.
- Ein zweckgebundener RFC-822-/MIME-Parser erkennt Header-Faltung und die für diese Prüfungen nötige Multipart-Struktur.
- Auf Duplikate geprüft werden Content-Type, From, To, Subject, MIME-Version, Content-Transfer-Encoding, Message-ID und Date.
Quellen und Referenzdaten
Methodik
Der Rohtext wird in Header und MIME-Teile aufgeteilt, RFC-822-Headerfaltung wird entfaltet und Multipart-Grenzen werden aus Content-Type-Parametern gelesen. Danach werden dokumentierte Anforderungen von RFC 5322/2045–2049 und bekannte Toleranzunterschiede geprüft. Nur CRLF-Normalisierung und RFC-2047-Kodierung eines Nicht-ASCII-Headers sind sichere Umschreibungen.
Rechenbeispiel
Multipart-Content-Type ohne Boundary-Parameter
Eingaben: Content-Type: multipart/mixed (kein boundary="...")
Ergebnis: Ein strikter MIME-Parser benötigt eine Boundary, um Teile zu finden. Der Fehler verhindert die strukturelle Analyse; ein Wert wird nicht erfunden.
LF statt CRLF im gesamten Nachrichtentext
Eingaben: Header und Body durch statt getrennt
Ergebnis: RFC 5322 fordert CRLF. Manche strikten Parser lehnen LF ohne CR ab; viele moderne Clients normalisieren es. Eine CRLF-Normalisierung wird angeboten.
Nicht-ASCII-Zeichen im Subject ohne Kodierung
Eingaben: Subject: Café-Notizen
Ergebnis: Traditionelle Nachrichten nach RFC 822/5322 verwenden 7-Bit-ASCII-Header. RFC 6532 erlaubt direkte UTF-8-Header, wenn der Empfangspfad SMTPUTF8 unterstützt. Für ältere Systeme bleiben RFC-2047-Encoded-Words die kompatiblere Wahl. Der Fall wird als Kompatibilitätshinweis markiert; eine deterministische, reversible RFC-2047-Umschreibung wird angeboten.
Praktische Hinweise
- Für jeden Multipart-Content-Type einen Boundary-Parameter und passende `--boundary`/`--boundary--`-Trenner verwenden.
- Bei MIME-Nachrichten `MIME-Version: 1.0` angeben.
- Lange, wenig wahrscheinliche Boundary-Zeichenfolgen wählen.
- Für breite Kompatibilität mit älteren, auf ASCII beschränkten Mailsystemen sollten Sie Nicht-ASCII-Text in Headern mit RFC 2047 kodieren. Direkte UTF-8-Header sind gültig, wenn der Empfangspfad RFC 6532 und SMTPUTF8 unterstützt.
Häufige Fehler
- Annehmen, LF-Zeilenenden funktionierten überall, weil ein moderner Mailclient die Datei öffnet.
- Content-Transfer-Encoding als dekorativ ansehen; ein als Base64 deklarierter, ungültiger Body kann beim Dekodieren scheitern.
Häufige Fragen
Warum ist eine fehlende Boundary ein Fehler, MIME-Version aber nur ein Hinweis?
Ohne Boundary kann ein strikter Parser die Nachrichtenteile nicht erkennen. Fehlende MIME-Version widerspricht RFC 2045, wird von toleranten Clients aber oft erschlossen.
Dekodiert das Werkzeug Anhänge?
Nein. Es prüft Header und Strukturmarker wie Grenzen, Kodierungsdeklarationen und Zeilenlängen. Der Anhanginhalt wird nicht angezeigt oder dekodiert.
Garantiert ein unauffälliges Ergebnis, dass Outlook die Datei importiert?
Nein. Es werden bestimmte Strukturprobleme geprüft, nicht Outlook ausgeführt und nicht alle Importursachen diagnostiziert.
Zuletzt geprüft:
Zweckgebundener RFC-822-/MIME-Parser, keine vollständige Mailbibliothek. Andere reale Sonderfälle wie S/MIME, Kalenderteile, tiefe multipart/related-Strukturen und Zeichensatzfälle außerhalb UTF-8 werden nicht analysiert. Zeilenlänge wird näherungsweise als UTF-8-Bytezahl bestimmt.
Dieses Tool liefert eine unverbindliche Schätzung auf Grundlage der oben genannten Annahmen.
Design- und Tool-Einstellungen sowie gespeicherte und zuletzt verwendete Listen werden nur in diesem Browser gespeichert.