Analisi forense di email e header

1. Avvertenza preliminare

Le procedure descritte in questo capitolo devono essere eseguite solo su email, caselle, file, allegati, backup o archivi ricevuti lecitamente, con incarico professionale, autorizzazione dell’avente diritto, richiesta del cliente, incarico difensivo, aziendale o tecnico-peritale.

Questo capitolo non fornisce istruzioni per:

[ ] accedere abusivamente a caselle email;
[ ] violare password;
[ ] aggirare autenticazioni a due fattori;
[ ] entrare in account Gmail, Microsoft 365, Yahoo, PEC o IMAP senza consenso;
[ ] intercettare comunicazioni;
[ ] manipolare header;
[ ] creare email false;
[ ] falsificare Message-ID, mittenti o allegati;
[ ] sottrarre dati da server;
[ ] estrarre credenziali;
[ ] inviare email fraudolente;
[ ] aggirare SPF, DKIM o DMARC.

L’analisi forense di email e header deve rispettare autorizzazione, catena di custodia, hash e verbale tecnico, conservazione del messaggio originale, acquisizione completa, hash degli output, analisi tecnica documentata e indicazione dei limiti.

Non analizzare solo ciò che si vede nel corpo della mail: in una email la parte più importante può essere nascosta negli header, negli allegati, nei metadati e nella modalità di acquisizione.

2. Perché le email sono prove digitali complesse?

Una email sembra semplice: mittente, destinatario, oggetto, testo e allegati. Dal punto di vista tecnico, però, una email può contenere moltissime informazioni che non sono visibili nella normale schermata del client di posta.

[ ] From;
[ ] To;
[ ] Cc;
[ ] Bcc, se disponibile in fonte idonea;
[ ] Subject;
[ ] Date;
[ ] Message-ID;
[ ] Reply-To;
[ ] Return-Path;
[ ] Received;
[ ] Authentication-Results;
[ ] SPF;
[ ] DKIM;
[ ] DMARC;
[ ] MIME;
[ ] Content-Type;
[ ] boundary;
[ ] allegati;
[ ] encoding;
[ ] server attraversati;
[ ] IP pubblici o privati;
[ ] client usato;
[ ] webmail;
[ ] identificativi antispam;
[ ] link;
[ ] domini;
[ ] timestamp.

RFC 5322 definisce il formato dei messaggi Internet e la struttura generale degli header come campi composti da nome del campo, due punti e corpo del campo: questo è il punto di partenza per comprendere una email come oggetto digitale e non come semplice testo stampato.

Per questo, in una perizia informatica a Roma, l’email va trattata come reperto digitale, con triage iniziale della prova digitale, acquisizione, conservazione, analisi e spiegazione in relazione tecnica, CTP informatico e contestazione delle prove digitali.

3. Che cos’è l’analisi forense di una email?

L’analisi forense di una email è la verifica tecnica del messaggio, della sua origine dichiarata, del percorso di consegna, degli header, degli allegati, dei metadati, della casella o archivio di provenienza e dei limiti tecnici.

Può servire per capire:

[ ] se una email è davvero arrivata;
[ ] se il mittente visualizzato corrisponde al mittente tecnico;
[ ] se il dominio è stato falsificato;
[ ] se la mail è compatibile con phishing;
[ ] se ci sono incongruenze negli header;
[ ] quali server hanno gestito il messaggio;
[ ] se SPF, DKIM o DMARC risultano pass/fail;
[ ] se gli allegati sono integri;
[ ] se un PDF allegato è stato modificato;
[ ] se un link porta a truffa;
[ ] se l’orario è coerente;
[ ] se esistono copie in PST, OST, MBOX, EML o MSG;
[ ] se la mail è in una casella cloud;
[ ] se la mail è stata inoltrata o alterata;
[ ] se il materiale prodotto dalla controparte è completo.

La conclusione tecnica non deve limitarsi a “sembra autentica” o “sembra falsa”: deve indicare quali elementi supportano o indeboliscono una determinata ipotesi.

4. Casi tipici a Roma

In una consulenza informatica forense a Roma, le email sono spesso decisive in contenziosi civili, aziendali, familiari e commerciali.

[ ] contratti e accordi commerciali;
[ ] diffide;
[ ] licenziamenti;
[ ] dimissioni;
[ ] comunicazioni aziendali;
[ ] truffe BEC;
[ ] bonifici fraudolenti;
[ ] phishing bancario;
[ ] invio di allegati contestati;
[ ] contestazioni tra soci;
[ ] rapporti cliente-fornitore;
[ ] email offensive o minacciose;
[ ] accessi abusivi ad account;
[ ] furto identità digitale;
[ ] invio di file audio, video, immagini o PDF sospetti;
[ ] email prodotte in giudizio come prova.

Una email può essere collegata a truffe online, bonifici fraudolenti e financial cybercrime, accessi abusivi ad account email, social e cloud, PEC, ricevute, allegati e prova digitale, PDF, firme digitali e marche temporali, metadati, EXIF, XMP, C2PA e provenienza dei file, cloud forensics: Google, Microsoft, Dropbox e backup o timeline forense e ricostruzione cronologica degli eventi.

5. Prima domanda: che cosa mi sta consegnando il cliente?

Quando un cliente arriva con “una email”, il perito deve prima capire in che forma la sta consegnando.

[ ] stampa cartacea;
[ ] PDF stampato dalla mail;
[ ] screenshot della mail;
[ ] inoltro della mail;
[ ] file .eml;
[ ] file .msg;
[ ] file .mbox;
[ ] archivio .pst;
[ ] archivio .ost;
[ ] mailbox Thunderbird;
[ ] Apple Mail;
[ ] Gmail web;
[ ] Microsoft 365 / Outlook;
[ ] PEC;
[ ] server IMAP;
[ ] backup;
[ ] export Google Takeout;
[ ] export Microsoft Purview;
[ ] acquisizione cloud autorizzata;
[ ] report di tool forense.

Una stampa o uno screenshot della email non sono la email completa.

6. Formati email da conoscere

EML

Il file .eml è spesso il formato più utile per una singola email perché può conservare header completi, corpo, struttura MIME, allegati, encoding, Message-ID, Received, DKIM-Signature e Authentication-Results.

MSG

Il file .msg è tipico di Microsoft Outlook e può contenere messaggio, proprietà MAPI, allegati, corpo HTML/RTF, metadati Outlook e header Internet, se presenti.

PST e OST

Il .pst è un archivio Outlook; il .ost è una cache locale di Outlook/Exchange/Microsoft 365. Entrambi possono essere decisivi in indagini aziendali, ma vanno acquisiti con metodo e hash.

MBOX

MBOX è un formato archivio usato da vari client e sistemi. Va trattato come reperto email complessivo, non come singolo messaggio.

MIME

La struttura MIME gestisce parti del messaggio, allegati, HTML, testo semplice, immagini, codifiche e boundary. È essenziale per capire se un allegato è incorporato, remoto, codificato o realmente presente nel messaggio.

7. Triage iniziale dell’email

Il triage email è una fase specifica del triage iniziale della prova digitale. Serve a non perdere informazioni tecniche prima ancora di usare strumenti avanzati.

Domande da fare al cliente

La email è ancora nella casella?
È stata ricevuta o inviata?
È Gmail, Outlook, PEC, dominio aziendale o altro?
È stata inoltrata?
È stata stampata?
È stato salvato il file EML o MSG?
Sono presenti allegati?
L’allegato è ancora disponibile?
La mail è stata cancellata?
È in una casella personale o aziendale?
È disponibile accesso autorizzato alla casella?
Ci sono altre email nello stesso thread?
Ci sono risposte o inoltri?
Ci sono ricevute o log server?
È collegata a un pagamento, truffa, contratto o diffida?
Serve relazione tecnica per avvocato?

Cosa dire subito al cliente

Non inoltrare più volte la mail.
Non stampare soltanto.
Non cancellare la mail.
Non modificare gli allegati.
Non aprire link sospetti.
Non scaricare allegati su computer non sicuro.
Non rispondere al mittente sospetto.
Non svuotare il Cestino.
Non eliminare la casella.
Salvare, se possibile, il messaggio originale in formato EML o MSG.

8. Catena di custodia dell’email

La catena di custodia, hash e verbale tecnico deve documentare chi consegna la email, in quale formato, da quale fonte, con quali allegati, con quali hash e con quali limiti.

Codifica reperti

MQ-2026-0051-R01 = file EML email contestata
MQ-2026-0051-R02 = allegato PDF
MQ-2026-0051-R03 = screenshot Gmail consegnato dal cliente
MQ-2026-0051-R04 = export casella autorizzato

Registro minimo

REGISTRO CATENA DI CUSTODIA EMAIL

Data/Ora:
Operatore:
Reperto:
Fonte:
Formato:
Azione:
Strumento:
Output:
Hash:
Note:

Esempio

10/07/2026 10:20
Operatore: Marcello Quaranta
Reperto: MQ-2026-0051-R01
Fonte: Gmail del cliente
Formato: EML scaricato da Show original
Azione: acquisizione e calcolo hash
Strumento: browser + sha256sum
Output: 01_email_originale/email_contestata.eml
Hash: vedi manifest SHA-256
Note: cliente dichiara ricezione della mail in data __

9. Cartella di caso per email forensics

La cartella deve separare messaggi originali, allegati, header, autenticazioni, DNS, link, output strumenti, timeline e relazione.

MQ-2026-0051_Email_Forensics_Roma/
│
├── 00_incarico_e_verbali/
├── 01_email_originali/
│   ├── EML/
│   ├── MSG/
│   ├── MBOX/
│   ├── PST_OST/
│   └── Screenshot_PDF/
├── 02_allegati_originali/
├── 03_hash/
├── 04_header_raw/
├── 05_header_parsed/
├── 06_authentication/
│   ├── SPF/
│   ├── DKIM/
│   ├── DMARC/
│   └── ARC/
├── 07_dns_domain_ip/
├── 08_link_url/
├── 09_tool_output/
│   ├── Forensic_Email_Collector/
│   ├── Aid4Mail/
│   ├── MailXaminer/
│   ├── MxToolbox/
│   └── Thunderbird/
├── 10_metadati_allegati/
├── 11_timeline/
├── 12_screenshot_documentativi/
├── 13_note_analisi/
├── 14_relazione/
└── 15_allegati_relazione/

10. Acquisizione manuale: Gmail

Se il cliente usa Gmail o Google Workspace, bisogna evitare di lavorare solo su screenshot. La funzione “Mostra originale / Show original” consente di visualizzare il contenuto tecnico e gli header disponibili.

Procedura operativa autorizzata

1. Accedere alla casella solo con autorizzazione dell’avente diritto.
2. Aprire la mail.
3. Fotografare o documentare il contesto, se necessario.
4. Cliccare sui tre puntini.
5. Selezionare “Mostra originale / Show original”.
6. Salvare o copiare il contenuto completo.
7. Scaricare il messaggio originale, se disponibile.
8. Salvare il file in 01_email_originali/EML/.
9. Calcolare hash.
10. Annotare nel registro.

Cosa acquisire

[ ] messaggio originale;
[ ] header completo;
[ ] corpo;
[ ] allegati;
[ ] screenshot documentativo;
[ ] data e ora dell’acquisizione;
[ ] eventuale thread;
[ ] eventuale etichetta/cartella;
[ ] eventuali link.

11. Acquisizione manuale: Outlook e Microsoft 365

In Outlook e Microsoft 365 è possibile visualizzare i dettagli del messaggio e gli Internet headers. In ambito aziendale, però, può essere preferibile procedere con export amministrativi o strumenti di eDiscovery autorizzati.

Procedura Outlook web / new Outlook

1. Accedere solo con autorizzazione.
2. Aprire la mail.
3. Cliccare More actions.
4. Selezionare View.
5. Selezionare View message details.
6. Copiare gli header.
7. Salvare in 04_header_raw/.
8. Se possibile esportare il messaggio in formato EML/MSG.
9. Salvare allegati originali.
10. Calcolare hash.

Outlook desktop

1. Aprire messaggio in finestra separata.
2. Accedere alle proprietà del messaggio.
3. Copiare Internet headers.
4. Salvare il messaggio come MSG, se possibile.
5. Salvare allegati.
6. Calcolare hash.

Per Microsoft 365 aziendale, l’analisi può collegarsi a cloud forensics: Google, Microsoft, Dropbox e backup e a analisi di log aziendali, firewall, VPN e sistemi cloud.

12. Acquisizione da Thunderbird e client locali

Thunderbird e altri client possono conservare messaggi in archivi locali. Il profilo del client va acquisito come fonte digitale, preferibilmente su copia.

Cosa cercare

[ ] profilo Thunderbird;
[ ] cartelle locali;
[ ] MBOX;
[ ] file .msf;
[ ] account IMAP/POP;
[ ] cartelle archivio;
[ ] posta eliminata;
[ ] allegati;
[ ] messaggio sorgente;
[ ] header completi.

Procedura

1. Non modificare il profilo originale.
2. Creare copia forense della cartella profilo.
3. Calcolare hash.
4. Aprire la copia in ambiente controllato.
5. Esportare messaggi rilevanti in EML.
6. Salvare header raw.
7. Salvare allegati.
8. Documentare cartella di origine.
9. Annotare se IMAP o POP.
10. Conservare output.

13. Acquisizione da file PST, OST, MBOX, EML e MSG

PST e OST

PST e OST possono contenere cartelle, email, allegati, contatti, calendario e metadati. Devono essere copiati, sottoposti a hash e analizzati su copia di lavoro.

1. Identificare file PST/OST.
2. Copiare su supporto di lavoro.
3. Calcolare hash.
4. Non aprire direttamente l’originale.
5. Analizzare con strumento idoneo.
6. Esportare messaggi rilevanti.
7. Conservare struttura cartelle.
8. Conservare allegati.
9. Produrre report.

MBOX

MBOX può contenere molti messaggi concatenati. Va trattato come archivio email e non come singolo messaggio.

EML e MSG

Singoli messaggi EML o MSG vanno trattati come reperti autonomi, con hash, header, allegati e note di provenienza.

14. Forensic Email Collector

Forensic Email Collector è uno strumento professionale per acquisizioni forensi da provider cloud e server email. È utile quando bisogna acquisire mailbox in modo ordinato, con log e output documentabili.

Quando usarlo

[ ] Gmail / Google Workspace;
[ ] Microsoft 365;
[ ] IMAP;
[ ] server email aziendali;
[ ] caselle cloud;
[ ] necessità di preservare struttura e allegati;
[ ] necessità di report;
[ ] modern attachments;
[ ] acquisizione autorizzata.

Procedura generale

1. Preparare incarico/autorizzazione.
2. Creare cartella caso.
3. Configurare sorgente email.
4. Usare accesso consentito.
5. Definire ambito: data, casella, cartelle, query.
6. Avviare acquisizione.
7. Salvare log.
8. Salvare output.
9. Calcolare hash.
10. Documentare limiti.

15. Aid4Mail

Aid4Mail può essere usato per conversione, acquisizione, revisione, eDiscovery e analisi di archivi email come PST, OST, MBOX, EML, EMLX e account cloud.

Quando usarlo

[ ] PST;
[ ] OST;
[ ] MBOX;
[ ] EML;
[ ] EMLX;
[ ] Gmail;
[ ] Microsoft 365;
[ ] conversioni controllate;
[ ] produzione PDF/A;
[ ] esportazione CSV/JSON;
[ ] grandi volumi email.

Procedura generale

1. Acquisire archivio email.
2. Calcolare hash.
3. Creare copia di lavoro.
4. Importare in Aid4Mail.
5. Definire filtri.
6. Esportare messaggi pertinenti.
7. Preservare header e allegati.
8. Generare report.
9. Conservare log.
10. Annotare versione strumento.

16. MailXaminer e altri strumenti email forensic

MailXaminer e strumenti analoghi consentono di esaminare file email, allegati, contatti, calendari, ricerche keyword e report tecnici.

Uso tipico

[ ] analisi PST/OST;
[ ] analisi EML/MSG;
[ ] allegati;
[ ] calendario;
[ ] contatti;
[ ] ricerca keyword;
[ ] export report;
[ ] analisi header;
[ ] conversione output.

17. Header email: struttura di base

Un header email contiene campi tecnici che descrivono il messaggio, il percorso, l’autenticazione, la struttura MIME e talvolta i sistemi antispam o gateway attraversati.

From:
To:
Cc:
Subject:
Date:
Message-ID:
Reply-To:
Return-Path:
Received:
MIME-Version:
Content-Type:
Content-Transfer-Encoding:
DKIM-Signature:
Authentication-Results:
Received-SPF:
ARC-Seal:
ARC-Message-Signature:
ARC-Authentication-Results:
X-Headers:

18. Received header: la traccia dei server

I campi Received sono tra i più importanti perché possono aiutare a ricostruire il percorso tecnico della email.

Cosa possono indicare

[ ] server che ha ricevuto il messaggio;
[ ] server precedente;
[ ] protocollo;
[ ] indirizzo IP;
[ ] hostname;
[ ] data e ora;
[ ] ID di transazione;
[ ] percorso di consegna;
[ ] eventuali incongruenze.

Operativamente, i Received si leggono spesso dal basso verso l’alto, perché ogni server che riceve il messaggio aggiunge il proprio campo sopra quelli già presenti.

19. Message-ID

Il Message-ID è un identificativo del messaggio. Può aiutare a collegare risposte e thread, confrontare copie e ricercare lo stesso messaggio in mailbox diverse.

[ ] identificare il messaggio;
[ ] collegare risposte e thread;
[ ] confrontare copie;
[ ] cercare lo stesso messaggio in mailbox diverse;
[ ] verificare coerenza del dominio generatore;
[ ] individuare anomalie.

20. Return-Path, Reply-To e From

I campi From, Reply-To e Return-Path possono essere diversi. Questo è spesso decisivo nei casi di spoofing, phishing e frodi.

From: amministrazione@azienda-reale.it
Reply-To: truffatore@gmail.com
Return-Path: dominio-sospetto.example

21. SPF

SPF consente a un dominio di dichiarare quali host sono autorizzati a inviare email per suo conto. È un indicatore tecnico, non una prova assoluta dell’identità personale del mittente.

Dove si vede

Authentication-Results:
Received-SPF:

Possibili risultati

pass
fail
softfail
neutral
none
temperror
permerror

22. DKIM

DKIM associa una firma crittografica al messaggio e consente a un dominio firmatario di assumersi responsabilità tecnica per il messaggio firmato.

Dove si vede

DKIM-Signature:
Authentication-Results: dkim=pass/fail

Cosa controllare

[ ] dominio firmatario;
[ ] selector;
[ ] canonicalization;
[ ] header firmati;
[ ] body hash;
[ ] risultato;
[ ] allineamento con From;
[ ] eventuali modifiche del messaggio.

23. DMARC

DMARC usa SPF e DKIM con criteri di allineamento rispetto al dominio nel campo From. È particolarmente importante nei casi di spoofing e impersonificazione di dominio.

Cosa controllare

[ ] dmarc=pass/fail;
[ ] dominio From;
[ ] allineamento SPF;
[ ] allineamento DKIM;
[ ] policy dominio;
[ ] Authentication-Results;
[ ] eventuali report;
[ ] dominio organizzativo.

24. Authentication-Results

Il campo Authentication-Results riporta in modo strutturato i risultati dei controlli di autenticazione eseguiti dal sistema ricevente o da infrastrutture intermedie.

spf=pass/fail
dkim=pass/fail
dmarc=pass/fail
arc=pass/fail
smtp.mailfrom=
header.from=
header.d=

25. ARC

ARC, cioè Authenticated Received Chain, può essere utile nei casi di inoltri, mailing list, gateway aziendali e sistemi intermedi in cui SPF/DKIM/DMARC possono cambiare lungo il percorso.

[ ] inoltri;
[ ] mailing list;
[ ] sistemi intermedi;
[ ] help desk;
[ ] gateway aziendali;
[ ] casi in cui SPF/DKIM/DMARC cambiano lungo il percorso.

26. Link contenuti nella email

Le email di phishing contengono spesso link. Non devono essere cliccati direttamente in ambiente non controllato.

[ ] non cliccare direttamente;
[ ] copiare URL in modo sicuro;
[ ] acquisire il link come testo;
[ ] documentare anteprima;
[ ] verificare dominio;
[ ] controllare redirect in ambiente sicuro;
[ ] acquisire pagina web se necessario;
[ ] collegare a timeline;
[ ] non inserire credenziali;
[ ] non scaricare file senza ambiente controllato.

Le pagine collegate possono richiedere una vera acquisizione di pagine web, social e contenuti online e, nei casi di frode, collegarsi a truffe online, bonifici fraudolenti e financial cybercrime.

27. Allegati email

Gli allegati possono essere il cuore della prova e vanno trattati come reperti digitali separati, collegati al messaggio.

Tipi frequenti

[ ] PDF;
[ ] DOCX;
[ ] XLSX;
[ ] ZIP;
[ ] immagini;
[ ] audio;
[ ] video;
[ ] file HTML;
[ ] file ICS calendario;
[ ] fatture;
[ ] ricevute;
[ ] contratti;
[ ] firme digitali;
[ ] marche temporali;

Cosa fare

1. Salvare allegato originale.
2. Calcolare hash.
3. Non aprirlo direttamente se sospetto.
4. Analizzare metadati.
5. Verificare estensione reale.
6. Verificare MIME type.
7. Verificare firme o marcature.
8. Controllare macro o contenuti attivi, se necessario.
9. Collegare al messaggio.
10. Indicare posizione nel thread.

Gli allegati possono richiedere analisi dedicate: PDF, firme digitali e marche temporali, metadati, EXIF, XMP, C2PA e provenienza dei file, autenticità audio: tagli, montaggi e ricodifiche, autenticità video: frame, codec, tagli e montaggi o immagini, fotografie manipolate e contenuti generati con AI.

28. Email spoofing

Lo spoofing email consiste nel far apparire una email come proveniente da un mittente diverso da quello reale o da un dominio legittimo.

Cosa cercare

[ ] From incoerente;
[ ] Reply-To diverso;
[ ] Return-Path anomalo;
[ ] SPF fail;
[ ] DKIM assente o fail;
[ ] DMARC fail;
[ ] dominio simile;
[ ] typosquatting;
[ ] Received incoerenti;
[ ] server non coerenti;
[ ] link verso domini diversi;
[ ] lingua e contenuto sospetto.

29. Phishing e truffe via email

Una email di phishing può essere collegata a credenziali sottratte, bonifici fraudolenti, false fatture, cambio IBAN, malware, allegati malevoli, link a portali falsi o business email compromise.

Il capitolo è strettamente collegato a truffe online, bonifici fraudolenti e financial cybercrime, accessi abusivi ad account email, social e cloud e analisi di log aziendali, firewall, VPN e sistemi cloud.

30. Analisi DNS, MX, SPF e domini

In alcuni casi bisogna controllare DNS e record del dominio: MX, SPF, DKIM selector, DMARC, dominio From, dominio MAIL FROM, dominio Reply-To e domini presenti nei link.

Comandi DNS utili

dig MX example.com
dig TXT example.com
dig TXT _dmarc.example.com
dig TXT selector._domainkey.example.com

Su Windows

nslookup -type=mx example.com
nslookup -type=txt example.com
nslookup -type=txt _dmarc.example.com

31. Email ricevuta vs email inoltrata

Un errore frequente è analizzare una email inoltrata come se fosse l’originale. L’inoltro può modificare header, inglobare la mail come testo, perdere Received originali, separare allegati e cambiare la struttura MIME.

Procedura

1. Chiedere email originale.
2. Chiedere file EML/MSG.
3. Chiedere accesso autorizzato alla casella.
4. Distinguere email originale e email inoltrata.
5. Calcolare hash separati.
6. Documentare limite.

32. Thread e conversazioni email

Una email isolata può essere ambigua. Il thread consente di leggere risposte, inoltri, allegati originari, modifiche all’oggetto, Message-ID, In-Reply-To, References, timestamp e utenti coinvolti.

[ ] email iniziale;
[ ] risposte;
[ ] inoltri;
[ ] allegati originari;
[ ] modifiche oggetto;
[ ] Message-ID;
[ ] In-Reply-To;
[ ] References;
[ ] timestamp;
[ ] utenti coinvolti.

33. BCC e destinatari nascosti

I destinatari BCC non sempre sono visibili nelle copie ricevute. La loro verifica può richiedere accesso alla casella del mittente, alla copia inviata o ai log server autorizzati.

[ ] il destinatario normale può non vedere BCC;
[ ] il mittente o server può conservarli;
[ ] log server possono essere necessari;
[ ] una stampa può non mostrarli;
[ ] una copia nella cartella “Inviata” può contenerli.

34. Allegati moderni: link cloud invece di file

Oggi molte email non contengono davvero il file allegato, ma un link a Google Drive, OneDrive, SharePoint, Dropbox o altri servizi.

Cosa controllare

[ ] l’allegato è file reale o link?
[ ] il link richiede autenticazione?
[ ] il file è ancora accessibile?
[ ] esistono versioni?
[ ] esistono permessi?
[ ] chi ha condiviso?
[ ] quando?
[ ] esistono log cloud?

Questa situazione richiede spesso cloud forensics: Google, Microsoft, Dropbox e backup.

35. Email e PEC: differenza

La email ordinaria e la PEC devono essere analizzate con criteri diversi. Questo capitolo riguarda l’email ordinaria. Per la PEC occorre esaminare ricevute, buste, certificazioni del gestore e allegati secondo il capitolo PEC, ricevute, allegati e prova digitale.

36. Timeline dell’email

La timeline forense e ricostruzione cronologica degli eventi serve a collegare data dichiarata, Date header, Received timestamp, invio, ricezione, apertura, download allegati, inoltri, risposte, accessi account, link cliccati, bonifico o pagamento, log aziendali ed eventi computer.

Fonti

[ ] header email;
[ ] mailbox;
[ ] log server;
[ ] computer del destinatario;
[ ] browser history;
[ ] allegati;
[ ] cloud;
[ ] sistemi aziendali;
[ ] banca o ricevute;
[ ] chat correlate.

37. Email cancellate

Il recupero di email cancellate può coinvolgere Cestino, Posta eliminata, Recoverable Items, PST/OST, MBOX, backup, server, cloud, archivi aziendali, client locale e allegati salvati. Il tema si collega al capitolo recupero dati cancellati per fini probatori.

38. Caso pratico 1 — Email sospetta ricevuta da cliente a Roma

Un cliente di Roma riceve una email che sembra provenire da un fornitore, ma contiene un IBAN diverso.

1. Acquisire email originale.
2. Evitare inoltro semplice.
3. Estrarre header.
4. Salvare EML.
5. Calcolare hash.
6. Analizzare From, Reply-To, Return-Path.
7. Analizzare Received.
8. Verificare SPF/DKIM/DMARC.
9. Acquisire link e allegati.
10. Correlare con bonifico.
11. Costruire timeline.
12. Redigere relazione.

Il caso si collega a truffe online, bonifici fraudolenti e financial cybercrime, accessi abusivi ad account email, social e cloud e timeline forense e ricostruzione cronologica degli eventi.

39. Caso pratico 2 — Email prodotta in giudizio solo come stampa

Una parte produce una stampa di email. La stampa può essere utile come rappresentazione, ma non consente analisi tecnica completa.

1. Trattare la stampa come riproduzione, non come email completa.
2. Richiedere file EML/MSG.
3. Richiedere casella originaria.
4. Verificare se esistono allegati.
5. Verificare thread.
6. Indicare limiti.
7. Non analizzare header se non disponibili.

40. Caso pratico 3 — Allegato PDF contestato

Una email contiene un PDF firmato o una proposta contrattuale contestata.

1. Acquisire email originale.
2. Salvare allegato originale.
3. Calcolare hash email.
4. Calcolare hash allegato.
5. Analizzare header.
6. Analizzare PDF.
7. Verificare metadati.
8. Verificare firme o marche.
9. Confrontare con altre versioni.
10. Redigere nota tecnica.

Il caso richiede spesso PDF, firme digitali e marche temporali e metadati, EXIF, XMP, C2PA e provenienza dei file.

41. Caso pratico 4 — Account email compromesso

Un professionista di Roma sospetta che qualcuno abbia usato la sua casella per inviare email fraudolente.

1. Acquisire email sospette.
2. Acquisire casella autorizzata.
3. Controllare cartella inviati.
4. Controllare regole di inoltro.
5. Controllare accessi recenti.
6. Controllare dispositivi collegati.
7. Controllare header.
8. Confrontare IP e login.
9. Verificare reset password.
10. Costruire timeline.

Il caso è collegato a accessi abusivi ad account email, social e cloud, cloud forensics: Google, Microsoft, Dropbox e backup e analisi di log aziendali, firewall, VPN e sistemi cloud.

42. Caso pratico 5 — Email con allegato audio o video

Una email contiene un file audio o video contestato.

1. Acquisire EML/MSG originale.
2. Salvare allegato.
3. Calcolare hash.
4. Analizzare header email.
5. Analizzare metadati allegato.
6. Usare MediaInfo.
7. Verificare provenienza dichiarata.
8. Collegare a capitolo audio/video.
9. Redigere limiti.

Il caso può richiedere autenticità audio: tagli, montaggi e ricodifiche, autenticità video: frame, codec, tagli e montaggi, il capitolo su voice cloning e deepfake, e metadati, EXIF, XMP, C2PA e provenienza dei file.

43. Errori da evitare

Errore 1 — Analizzare solo lo screenshot.
Errore 2 — Usare solo l’inoltro.
Errore 3 — Non salvare EML/MSG.
Errore 4 — Non calcolare hash.
Errore 5 — Cliccare link sospetti.
Errore 6 — Aprire allegati sospetti.
Errore 7 — Confondere From con mittente reale.
Errore 8 — Interpretare SPF/DKIM/DMARC senza allineamento.
Errore 9 — Ignorare il thread.
Errore 10 — Non indicare limiti.

44. Checklist operativa completa

Prima dell’acquisizione

[ ] autorizzazione;
[ ] codice caso;
[ ] scheda email;
[ ] cartella caso;
[ ] strumenti pronti;
[ ] destinazione sicura;
[ ] procedura hash;

Acquisizione

[ ] salvare EML/MSG, se possibile;
[ ] copiare header raw;
[ ] salvare allegati;
[ ] acquisire screenshot documentativo;
[ ] acquisire thread;
[ ] acquisire cartella/casella, se necessario;
[ ] calcolare hash;

Analisi header

[ ] From;
[ ] To/Cc;
[ ] Date;
[ ] Message-ID;
[ ] Return-Path;
[ ] Reply-To;
[ ] Received;
[ ] Authentication-Results;
[ ] SPF;
[ ] DKIM;
[ ] DMARC;
[ ] ARC;
[ ] MIME;

Relazione

[ ] fonte;
[ ] formato;
[ ] metodo;
[ ] hash;
[ ] header;
[ ] allegati;
[ ] autenticazione;
[ ] timeline;
[ ] limiti;
[ ] conclusioni prudenti.

45. Output minimo

1. verbale di ricezione;
2. scheda email;
3. email originale EML/MSG/PST/MBOX o fonte disponibile;
4. header raw;
5. header interpretati;
6. allegati originali;
7. hash email e allegati;
8. output strumenti;
9. screenshot documentativi;
10. analisi SPF/DKIM/DMARC;
11. analisi link/domini;
12. timeline;
13. nota sui limiti;
14. relazione tecnica.

46. Modelli di frasi tecniche

Email originale

Il messaggio è stato acquisito in formato __, conservando header, corpo, struttura MIME e allegati disponibili.

Header incompleti

La fonte consegnata non contiene header completi; pertanto non è possibile ricostruire integralmente il percorso tecnico del messaggio.

SPF

Il risultato SPF è stato valutato come controllo tecnico relativo all’autorizzazione del server mittente per il dominio indicato nel percorso SMTP.

DKIM

Il risultato DKIM è stato valutato come verifica della firma crittografica associata al dominio firmatario, senza confonderlo con attribuzione personale dell’autore del messaggio.

DMARC

Il risultato DMARC è stato valutato in relazione all’allineamento tra il dominio From e i risultati SPF/DKIM disponibili.

Spoofing

Sono state rilevate incongruenze tecniche compatibili con possibile spoofing, tra cui differenze tra From, Reply-To, Return-Path, server di transito e risultati di autenticazione.

Allegati

Gli allegati sono stati acquisiti separatamente, sottoposti a hash e analizzati come reperti digitali collegati al messaggio.

Limiti

Le conclusioni sono formulate nei limiti della fonte disponibile, del formato acquisito, della completezza degli header e degli eventuali log o archivi accessibili.

47. Foto e immagini da inserire nella pagina

48. Riferimenti tecnici esterni

1. RFC 5322 — Internet Message Format
2. RFC 6376 — DKIM
3. RFC 7208 — SPF
4. RFC 9989 — DMARC core protocol
5. RFC 9990 — DMARC aggregate reporting
6. RFC 9991 — DMARC failure reporting
7. RFC 8601 — Authentication-Results
8. RFC 8617 — ARC
9. Google Gmail Help — Trace an email with full header
10. Microsoft Support — View internet message headers in Outlook
11. Metaspike Forensic Email Collector Documentation
12. Aid4Mail Email Forensics
13. MailXaminer Forensics Wiki
14. MxToolbox Email Header Analyzer

49. Collegamenti interni consigliati

Capitoli precedenti

/triage-iniziale-prova-digitale-roma.html
/catena-custodia-hash-verbale-tecnico.html
/analisi-forense-computer-windows.html
/analisi-forense-macos-linux.html
/recupero-dati-cancellati-fini-probatori.html

Capitolo successivo

/pec-ricevute-allegati-prova-digitale.html

Capitoli correlati

/pdf-firme-digitali-marche-temporali.html
/metadati-exif-xmp-c2pa-provenienza-file.html
/verifica-forense-screenshot-schermate.html
/acquisizione-pagine-web-social-contenuti-online.html
/accessi-abusivi-account-email-social-cloud.html
/truffe-online-bonifici-fraudolenti-financial-cybercrime.html
/cloud-forensics-google-microsoft-dropbox-backup.html
/timeline-forense-ricostruzione-cronologica-eventi.html
/relazione-tecnica-ctp-contestazione-prove-digitali.html

Pagine servizio

/servizi/perizia-informatica-forense-roma/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/accessi-abusivi-log-account/
/servizi/recupero-dati-probatori/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

50. Box commerciale finale

51. Conclusione del capitolo

L’analisi forense di una email richiede metodo, prudenza e attenzione ai dettagli. Una email non è solo il testo che appare sullo schermo.

[ ] header;
[ ] corpo;
[ ] MIME;
[ ] allegati;
[ ] server;
[ ] domini;
[ ] IP;
[ ] autenticazioni;
[ ] timestamp;
[ ] link;
[ ] thread;
[ ] casella;
[ ] contesto.

Non basta leggere una email. Bisogna acquisire l’originale, conservare gli header, verificare autenticazione, analizzare allegati e costruire il contesto tecnico.

Nel prossimo capitolo il manuale passerà a un tema con valore specifico nel contesto italiano:

Capitolo 12 · PEC, ricevute, allegati e prova digitale