feat(email): extract forensic metadata from EML evidence #89

New issue

Closed

opened 2026-07-22 15:41:09 +02:00 by fy59 · 0 comments

fy59 commented

2026-07-22 15:41:09 +02:00

Owner

feat(email): extract forensic metadata from EML evidence

Description :

Contexte

Une enquête peut contenir un courriel original importé au format EML. Ses
en-têtes peuvent fournir des informations utiles pour identifier
l'infrastructure utilisée, vérifier l'authenticité apparente du message et
faire émerger de nouvelles entités.

L'analyse doit préserver la preuve originale et ne doit effectuer aucune
connexion réseau.

Objectif

Permettre de sélectionner une preuve EML, d'en extraire localement les
métadonnées techniques, puis de réviser les résultats avant toute intégration
dans le graphe.

Données à extraire

adresse déclarée dans From ;
adresse Reply-To, si présente ;
destinataires To et Cc ;
sujet ;
date déclarée ;
Message-ID ;
en-têtes Received dans leur ordre d'origine ;
domaines et adresses IP observés ;
résultats SPF, DKIM et DMARC présents dans les en-têtes ;
nom du logiciel d'envoi lorsqu'il est déclaré.

Contraintes de conservation

Le fichier EML original reste strictement inchangé.
Son empreinte SHA-256 n'est jamais recalculée pour remplacer celle enregistrée.
L'analyse est réalisée uniquement sur une lecture locale.
Les en-têtes bruts utiles restent consultables.
Aucun lien, pixel distant ou contenu externe n'est chargé.
Aucun outil réseau n'est lancé automatiquement.

Révision avant intégration

Une fenêtre doit présenter :

les métadonnées extraites ;
les anomalies ou champs absents ;
chaque proposition d'entité ;
chaque proposition de relation ;
une sélection explicite des éléments à intégrer.

Aucune entité ni relation ne doit être créée sans confirmation.

Entités proposées

Selon les résultats :

email_address ;
domain_name ;
ip_address ;
éventuellement person ou organization uniquement si l'information est
explicitement déclarée, sans la considérer comme vérifiée.

Relations proposées

Exemples :

sent_from;
reply_to;
received_by;
uses_domain;
mentions;
linked_to_evidence.

Les libellés doivent rester factuels et ne pas attribuer automatiquement le
message à une personne.

Traçabilité

Toutes les entités créées doivent être liées à la preuve EML.
La provenance doit indiquer l'en-tête ayant produit chaque proposition.
Les valeurs doivent être normalisées pour détecter les doublons.
L'ordre des en-têtes Received doit être conservé.
Un échec d'intégration doit annuler toute la transaction.

Critères d'acceptation

L'action n'est disponible que pour une preuve EML.
Un EML valide peut être analysé localement.
Les en-têtes repliés sur plusieurs lignes sont correctement reconstruits.
Les encodages MIME des en-têtes sont décodés sans modifier les octets originaux.
Les adresses email, domaines et IP sont normalisés.
Les doublons existants sont proposés comme éléments réutilisés.
L'utilisateur choisit explicitement les résultats à intégrer.
Les entités intégrées sont reliées à la preuve source.
Un EML invalide produit un message compréhensible sans écriture partielle.
Des tests utilisent des fixtures EML synthétiques sans données personnelles.
La compilation et la suite complète des tests réussissent.

feat(email): extract forensic metadata from EML evidence Description : ## Contexte Une enquête peut contenir un courriel original importé au format EML. Ses en-têtes peuvent fournir des informations utiles pour identifier l'infrastructure utilisée, vérifier l'authenticité apparente du message et faire émerger de nouvelles entités. L'analyse doit préserver la preuve originale et ne doit effectuer aucune connexion réseau. ## Objectif Permettre de sélectionner une preuve EML, d'en extraire localement les métadonnées techniques, puis de réviser les résultats avant toute intégration dans le graphe. ## Données à extraire - adresse déclarée dans `From` ; - adresse `Reply-To`, si présente ; - destinataires `To` et `Cc` ; - sujet ; - date déclarée ; - `Message-ID` ; - en-têtes `Received` dans leur ordre d'origine ; - domaines et adresses IP observés ; - résultats SPF, DKIM et DMARC présents dans les en-têtes ; - nom du logiciel d'envoi lorsqu'il est déclaré. ## Contraintes de conservation - Le fichier EML original reste strictement inchangé. - Son empreinte SHA-256 n'est jamais recalculée pour remplacer celle enregistrée. - L'analyse est réalisée uniquement sur une lecture locale. - Les en-têtes bruts utiles restent consultables. - Aucun lien, pixel distant ou contenu externe n'est chargé. - Aucun outil réseau n'est lancé automatiquement. ## Révision avant intégration Une fenêtre doit présenter : - les métadonnées extraites ; - les anomalies ou champs absents ; - chaque proposition d'entité ; - chaque proposition de relation ; - une sélection explicite des éléments à intégrer. Aucune entité ni relation ne doit être créée sans confirmation. ## Entités proposées Selon les résultats : - `email_address` ; - `domain_name` ; - `ip_address` ; - éventuellement `person` ou `organization` uniquement si l'information est explicitement déclarée, sans la considérer comme vérifiée. ## Relations proposées Exemples : - `sent_from`; - `reply_to`; - `received_by`; - `uses_domain`; - `mentions`; - `linked_to_evidence`. Les libellés doivent rester factuels et ne pas attribuer automatiquement le message à une personne. ## Traçabilité - Toutes les entités créées doivent être liées à la preuve EML. - La provenance doit indiquer l'en-tête ayant produit chaque proposition. - Les valeurs doivent être normalisées pour détecter les doublons. - L'ordre des en-têtes `Received` doit être conservé. - Un échec d'intégration doit annuler toute la transaction. ## Critères d'acceptation - L'action n'est disponible que pour une preuve EML. - Un EML valide peut être analysé localement. - Les en-têtes repliés sur plusieurs lignes sont correctement reconstruits. - Les encodages MIME des en-têtes sont décodés sans modifier les octets originaux. - Les adresses email, domaines et IP sont normalisés. - Les doublons existants sont proposés comme éléments réutilisés. - L'utilisateur choisit explicitement les résultats à intégrer. - Les entités intégrées sont reliées à la preuve source. - Un EML invalide produit un message compréhensible sans écriture partielle. - Des tests utilisent des fixtures EML synthétiques sans données personnelles. - La compilation et la suite complète des tests réussissent.

fy59 closed this issue

2026-07-22 16:09:22 +02:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#89

No description provided.