Analyseur d'importation EML/MIME

Collez la source brute d'un courriel .eml (RFC 822 / MIME) ou sélectionnez un fichier .eml pour repérer les structures interprétées différemment ou rejetées par Outlook, l'importation Gmail, Apple Mail, Thunderbird et les outils IMAP génériques.

Collez le contenu que vous souhaitez analyser

Traitement effectué localement dans votre navigateur. Votre fichier n’est jamais téléversé.

Comment utiliser cet outil outil

Collez la source .eml brute ou sélectionnez un fichier .eml ; l'analyse se fait dans le navigateur et rien n'est envoyé.
Sélectionnez « Vérifier la compatibilité d'importation ».
Examinez chaque élément signalé : défaut de portabilité et clients/importateurs susceptibles de diverger.
Utilisez les réécritures proposées lorsqu'elles existent : normaliser les fins de ligne en CRLF et encoder les en-têtes selon RFC 2047 sont des corrections mécaniques sûres. Les autres problèmes sont expliqués, car aucune correction sûre ne peut être devinée.

Hypothèses

Reconnaît huit cas : limites multipart absentes/mal formées, en-tête MIME-Version manquant dans un message à structure MIME, Content-Transfer-Encoding incompatible avec le corps réel, valeurs d'en-tête non ASCII non encodées, lignes dépassant les 998 octets de RFC 5322, fins de ligne LF seules, en-têtes critiques dupliqués et chaînes de boundary faibles susceptibles de correspondre au contenu.
Analyseur RFC 822/MIME tenant compte des lignes, développé pour cet outil ; reconnaît le pliage des en-têtes et les limites multipart nécessaires à ces vérifications, pas davantage.
Les en-têtes critiques vérifiés pour les doublons sont Content-Type, From, To, Subject, MIME-Version, Content-Transfer-Encoding, Message-ID et Date.

Sources et données de référence

Méthodologie

Le texte brut est analysé en en-têtes (dépliage RFC 822) et arbre de parties MIME ; les paramètres boundary de Content-Type servent à localiser les séparateurs. Les exigences RFC 5322/2045-2049/2047 et les différences de tolérance réelles des clients/importateurs sont vérifiées. Une réécriture n'est proposée que pour une transformation déterministe et sûre : fins de ligne CRLF et encodage RFC 2047 d'une valeur d'en-tête non ASCII brute. Les autres cas sont signalés sans inventer de boundary ni choisir entre des en-têtes dupliqués.

Exemple détaillé

Content-Type multipart sans paramètre boundary

Données d’entrée: Content-Type: multipart/mixed (sans boundary="...")

Résultat: Un analyseur MIME strict a besoin de boundary pour localiser les parties. Erreur, car la structure ne peut pas être analysée ; aucune correction, car la valeur ne peut pas être inventée sans risque.

Fins de ligne LF seules dans tout le fichier

Données d’entrée: En-têtes et corps séparés par \n plutôt que \r\n

Résultat: RFC 5322 exige des fins CRLF. Certains analyseurs stricts interprètent mal ou rejettent les LF seuls, bien que beaucoup de clients modernes les normalisent. Information avec réécriture sûre en CRLF.

En-tête Subject avec caractères non ASCII bruts

Données d’entrée: Subject: Notes de réunion au café

Résultat: Les messages RFC 822/5322 traditionnels utilisent des en-têtes ASCII sur 7 bits. La RFC 6532 autorise les en-têtes UTF-8 directs lorsque le chemin de réception prend en charge SMTPUTF8. Les mots codés RFC 2047 restent le choix le plus compatible avec les systèmes anciens. Le cas est signalé comme un avertissement de compatibilité et une réécriture RFC 2047 déterministe et réversible est proposée.

Conseils pratiques

Incluez un paramètre boundary dans chaque Content-Type multipart ; le corps doit employer `--boundary` et terminer par `--boundary--`.
Incluez `MIME-Version: 1.0` dans les messages utilisant MIME, même si certains clients le déduisent : cela supprime une ambiguïté.
Préférez une chaîne boundary longue et peu prévisible pour réduire le risque de collision avec le contenu.
Pour une large compatibilité avec les systèmes de messagerie anciens limités à ASCII, encodez le texte non ASCII des en-têtes selon la RFC 2047. Les en-têtes UTF-8 directs sont valides si le chemin de réception prend en charge les RFC 6532 et SMTPUTF8.

Erreurs fréquentes

Supposer qu'un .eml avec fins LF seules fonctionnera partout parce qu'un client moderne l'ouvre : certains analyseurs stricts exigent CRLF.
Traiter Content-Transfer-Encoding comme décoratif : une partie déclarée base64 sans corps base64 valide peut échouer au décodage ou s'afficher comme des données illisibles.

Questions fréquentes

Pourquoi un paramètre boundary manquant est-il une erreur, mais MIME-Version absent un avertissement ?

Sans boundary, un analyseur strict ne peut pas localiser les parties ; l'analyse échoue. L'absence de MIME-Version enfreint RFC 2045, mais des clients tolérants déduisent souvent MIME des autres en-têtes, ce qui réduit l'effet pratique.

Pourquoi l'outil réécrit-il les en-têtes non ASCII mais ne corrige-t-il pas un boundary absent ?

Encoder un en-tête selon RFC 2047 est une transformation déterministe et sans perte des octets présents. Inventer un boundary ou choisir entre deux en-têtes dupliqués exige une intention inconnue.

L'outil décode-t-il ou affiche-t-il le contenu des pièces jointes ?

Non. Il inspecte les en-têtes et marqueurs structurels (limites, déclarations d'encodage, longueurs de ligne) sans décoder ni afficher les pièces jointes, sauf court extrait nécessaire à l'explication d'un défaut précis comme le premier caractère invalide d'un bloc base64 mal formé.

Pourquoi ce fichier EML ne s'ouvre-t-il ou ne s'importe-t-il pas dans Outlook ?

Ce vérificateur cherche des défauts structurels précis, dont des limites MIME multipart absentes ou mal formées et des divergences d'encodage de transfert, qui gênent l'analyse fiable. Il ne teste pas Outlook et ne diagnostique pas tous les problèmes d'importation ; un fichier peut passer ces contrôles et échouer pour une autre raison.

Dernière vérification : 2026-09-25

Analyseur RFC 822/MIME spécialisé et limité, pas bibliothèque complète : reconnaît les huit cas cités, pas les autres bizarreries (cas limites de jeux de caractères hors UTF-8, signatures S/MIME, parties calendrier/iCal, structures multipart/related profondément imbriquées). La longueur de ligne approche les octets par comptage UTF-8, exact pour la grande majorité des messages réels.

Cet outil fournit une estimation indicative fondée sur les hypothèses indiquées ci-dessus.

Les préférences de thème et d’outils, ainsi que les listes enregistrées et récemment utilisées, sont stockées uniquement dans ce navigateur.