💥 Introduzione – Quando una semplice e-mail diventa una prova giudiziaria

Nel corso della mia attività di consulente informatico forense, mi capita spesso di ricevere incarichi in cui la posta elettronica rappresenta l’elemento centrale di una controversia.

Un’e-mail può essere infatti una prova determinante: può confermare un accordo contrattuale, smentire una versione dei fatti o dimostrare l’origine di una comunicazione diffamatoria. Tuttavia, per essere considerata valida in sede giudiziaria, deve essere autentica, integra e riconducibile con certezza al mittente.

In questo articolo racconto un caso reale (con dati anonimizzati) in cui sono stato incaricato di verificare l’autenticità di un messaggio e-mail contestato in un procedimento civile.

Il caso: un’e-mail “modificata” dopo l’invio?

Un’azienda aveva ricevuto da un suo fornitore una e-mail che sembrava contenere un’ammissione di responsabilità in merito a una fornitura difettosa.
Il mittente, però, sosteneva che il testo mostrato dal destinatario non corrispondeva a quello originariamente inviato, accusandolo di aver manipolato il messaggio.

Il Tribunale, per chiarire la vicenda, ha disposto una perizia informatica forense.
Il mio compito era accertare:

1. Se il messaggio fosse stato realmente inviato dal mittente indicato.

2. Se il suo contenuto fosse stato alterato dopo la spedizione.

3. Se gli orari e i log fossero coerenti con il flusso di posta elettronica.

1️⃣ Fase 1 – Acquisizione forense e conservazione della prova

La prima attività è stata l’acquisizione del messaggio in modo tecnicamente valido, senza alterarne alcun elemento.

Il file della e-mail (in formato .eml) è stato estratto dai sistemi di posta del destinatario tramite duplicazione bit-a-bit, documentando ogni passaggio con screenshot e firma digitale della copia.
Contestualmente è stato calcolato un hash SHA-256 per garantire l’immutabilità del file originale:

SHA256: 3f8a9b7c45e2...a4f9c12b6e0

Questo valore univoco sarebbe stato poi confrontato in tutte le successive analisi per dimostrare che il file non era stato modificato.

🔐 La regola fondamentale della digital forensics è: “non lavorare mai sull’originale”. Tutte le analisi vengono effettuate su copie forensi identiche, in sola lettura.

2️⃣ Fase 2 – Analisi degli header: la carta d’identità dell’e-mail

Ogni messaggio di posta elettronica contiene, oltre al testo visibile, un insieme di intestazioni tecniche (header) che raccontano il suo percorso digitale.
Ecco un estratto (semplificato) dell’header analizzato:

Received: from smtp.mailserver.it (smtp.mailserver.it [185.23.44.19])
  by mx.google.com with ESMTPS id s6-20020a17090b00a300b0023fdefc
  for <info@azienda.com>;
  Tue, 10 Oct 2023 09:42:18 +0200 (CEST)
Received: from [192.168.1.34] (unknown [93.44.11.200])
  by smtp.mailserver.it (Postfix) with ESMTPSA id 9D45F3A09C
  for <info@azienda.com>;
  Tue, 10 Oct 2023 09:42:15 +0200 (CEST)
Message-ID: <003a01da9d21$c23b77a0$46b266e0$@fornitore.it>
From: "Ufficio Forniture" <ufficio@fornitore.it>
To: "Responsabile Acquisti" <info@azienda.com>
Subject: Consegna merce e resi
Date: Tue, 10 Oct 2023 09:42:10 +0200

🔍 Cosa ho verificato:

• Sequenza Received: la catena degli header mostrava un percorso coerente: prima l’invio dal PC del mittente (93.44.11.200), poi il passaggio attraverso il server SMTP aziendale, infine la ricezione sul server Google del destinatario.

• Coerenza temporale: tutti i timestamp erano coerenti e con lo stesso fuso orario (+0200).

• Message-ID: il valore 003a01da9d21... risultava univoco e generato automaticamente dal client di posta Microsoft Outlook, confermando che il messaggio non era stato ricreato manualmente.

• Campo Return-Path: combaciava con il dominio del mittente.

Questi elementi hanno escluso l’ipotesi di un falso “spoofing” o di un inoltro manipolato.

3️⃣ Fase 3 – Confronto con i log del provider

Ho poi richiesto un estratto dei log SMTP del provider di posta elettronica.
In tali registri ho trovato la traccia corrispondente all’invio dell’e-mail in questione, con lo stesso Message-ID e timestamp.

Un estratto (anonimizzato):

Oct 10 09:42:14 smtp postfix/smtpd[1123]: 9D45F3A09C: client=unknown[93.44.11.200], sasl_method=LOGIN, sasl_username=ufficio@fornitore.it
Oct 10 09:42:15 smtp postfix/qmgr[2021]: 9D45F3A09C: from=<ufficio@fornitore.it>, size=2342, nrcpt=1 (queue active)
Oct 10 09:42:18 smtp postfix/smtp[2053]: 9D45F3A09C: to=<info@azienda.com>, relay=mx.google.com[74.125.140.27]:25, status=sent

L’analisi dei log ha confermato l’avvenuto invio dell’e-mail alle 09:42:18, con esito “sent”.
Anche il provider del destinatario ha confermato la ricezione con lo stesso Message-ID.

4️⃣ Fase 4 – Analisi del contenuto e confronto tra versioni

Per verificare se il messaggio fosse stato alterato, ho confrontato:

• il file .eml fornito dal destinatario;

• la copia archiviata nella cartella “Posta inviata” del mittente.

Il confronto è stato eseguito con strumenti forensi (ad es. Autopsy, FTK Imager e un diff binario) per analizzare eventuali differenze nei segmenti MIME.

Esempio di struttura MIME analizzata:

MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Il risultato del confronto è stato identico bit per bit, ad eccezione dei campi “Received” generati automaticamente dai server intermedi (legittimo e previsto dal protocollo SMTP).
Nessuna variazione nel corpo del messaggio né negli allegati PDF.

5️⃣ Fase 5 – Verifica della firma digitale e dei metadati

Il messaggio non era una PEC, ma includeva una firma DKIM (DomainKeys Identified Mail), visibile nell’header:

DKIM-Signature: v=1; a=rsa-sha256; d=fornitore.it; s=mail;
  bh=TbY9zT9oO8wPa9X6QcyOvsG41vT0aR+4wq...;
  b=VHQv1J3CgwQnQ7kZ...

Ho verificato la validità della firma DKIM, ottenendo esito positivo:
➡️ significa che il contenuto non era stato modificato dopo l’invio e che proveniva effettivamente dal dominio fornitore.it.

6️⃣ Fase 6 – Redazione della relazione tecnica

Dopo aver raccolto tutte le evidenze, ho redatto una relazione tecnica forense comprendente:

• descrizione metodologica delle attività svolte,

• hash di verifica,

• copia degli header completi,

• allegati con i log dei server,

• e un paragrafo conclusivo che sintetizzava l’esito:

“L’e-mail contestata risulta autentica, non alterata e proveniente dal server SMTP appartenente al dominio fornitore.it.
Le firme DKIM e i log di transito confermano l’integrità del messaggio e la sua riferibilità al mittente dichiarato.”

✅ Risultato finale

La perizia ha permesso al Tribunale di riconoscere pieno valore probatorio al messaggio.
Il giudice ha rigettato l’ipotesi di manipolazione e ha utilizzato l’e-mail come prova valida nel giudizio.

Lezioni apprese e consigli pratici

1. Mai fidarsi solo dello screenshot di un’e-mail.
   Gli header sono la vera fonte della verità.

2. Salvare sempre i file .eml o .msg originali.
   Aprire e salvare nuovamente un messaggio può alterarne i metadati.

3. Utilizzare sistemi di posta con firme DKIM e SPF.
   Questi protocolli riducono drasticamente i casi di spoofing.

4. Affidarsi a un consulente forense certificato.
   Solo un’analisi condotta con criteri scientifici può avere valore legale.

Conclusione – La verità nei dettagli digitali

Questo caso dimostra quanto sia facile accusare un’e-mail di essere falsa, ma anche quanto sia difficile sostenerlo di fronte a un’analisi forense completa.

Ogni messaggio di posta elettronica, anche apparentemente semplice, racchiude una complessa struttura di metadati che, se analizzata correttamente, racconta con precisione ciò che è accaduto.

Il compito del perito informatico è leggere quella storia digitale — con rigore tecnico, metodo e imparzialità.