Un cliente ti consegna «l'email» su una chiavetta. Può essere un file .eml, un .emlx copiato dalla libreria di Apple Mail o un .msg salvato da Outlook. Sembrano tre modi di dire la stessa cosa, e non lo sono: due conservano il messaggio così come è arrivato, il terzo lo scompone in campi e non ne tiene la forma originale. In perizia è questa differenza a decidere se un'impronta o una firma si possono ancora verificare.

Che cos'è, fisicamente, un'email

Un messaggio di posta è testo. Lo definisce la RFC 5322: un blocco di intestazioni (From, To, Date, Message-ID, e le righe Received che ogni server aggiunge in cima lungo il percorso), una riga vuota, e il corpo. MIME aggiunge la struttura: il corpo può essere diviso in parti — il testo semplice, la versione HTML, le immagini richiamate dall'HTML, gli allegati codificati in base64 — ciascuna con le proprie intestazioni Content-Type.

La conseguenza, per chi esamina un messaggio: ciò che si può verificare è calcolato su byte precisi. La firma S/MIME — e quindi la firma del gestore su una PEC — copre una parte MIME esattamente com'è scritta, andate a capo comprese. Riscriverla uguale nell'aspetto ma diversa nei byte la rende inverificabile, anche se nessuno ha alterato niente.

Tre contenitori per lo stesso messaggio

La stessa email in tre file. Nel riquadro tratteggiato dell'MSG, la parte che esiste solo quando Outlook ha conservato la busta di un messaggio firmato.

EML: il file è il messaggio

Un .eml è il messaggio RFC 5322 scritto su disco, dal primo all'ultimo byte. Non c'è involucro: l'impronta del file è l'impronta del messaggio, e qualsiasi strumento lo legge senza dover interpretare niente.

EMLX: il messaggio nella busta di Apple Mail

Apple Mail salva ogni messaggio in un .emlx fatto di tre parti: una prima riga con il numero di byte del messaggio, il messaggio stesso, e in coda un plist XML con i metadati della casella. Il messaggio incapsulato è identico, byte per byte, a quello ricevuto: estrarlo non altera nulla, e nella figura la sua impronta coincide con quella dell'EML.

Il plist è un'informazione in più, e di natura diversa: non dice niente del messaggio, dice che cosa ne ha fatto la casella. date-received è il momento in cui Apple Mail l'ha ricevuto, in secondi dall'epoca Unix; flags è un intero i cui bit dicono se il messaggio è stato letto, risposto, inoltrato, contrassegnato. Quei bit non hanno una specifica pubblica: Probatio nomina quelli stabili e osservati sui file, e riporta sempre il numero intero, che è il dato vero.

Due varianti da riconoscere. In un .partial.emlx Apple Mail ha staccato il contenuto degli allegati per conservarlo a parte: risultano presenti ma vuoti, e Probatio lo dichiara. Se invece la prima riga dichiara più byte di quanti il file ne contenga, il messaggio è troncato e viene letto fin dove arriva, con un avviso.

MSG: il messaggio scomposto in proprietà

Un .msg di Outlook è un Compound File, lo stesso contenitore dei vecchi .doc. Dentro non c'è il messaggio come testo: c'è un insieme di proprietà MAPI, una per flusso — 0x0037 l'oggetto, 0x1000 il testo, 0x1013 l'HTML, 0x007D le intestazioni di trasporto — mentre destinatari e allegati sono sotto-contenitori. Outlook ha preso il messaggio arrivato dal server, lo ha smontato nei suoi campi e ha tenuto i campi.

Per leggerlo, il messaggio va quindi ricostruito. Probatio distingue tre casi e li dichiara:

Intestazioni di trasporto presenti (0x007D): le intestazioni sono quelle originali, ma corpo e allegati sono ricomposti dalle proprietà. La struttura MIME è nuova.
Nessuna intestazione di trasporto: il messaggio non risulta transitato — una bozza, un elemento creato in Outlook, o un salvataggio da un programma che non le conserva. Mittente, destinatari e data sono ricavati dalle proprietà, e non c'è un percorso di server da esaminare.
Busta S/MIME conservata: il caso buono, che merita un paragrafo a sé.

Per questo, aprendo un MSG, Probatio mostra due impronte: quella del file, che è il reperto, e quella del messaggio ricostruito, che non va citata come impronta di qualcosa che esista fuori dal programma.

Il caso che salva la firma: IPM.Note.SMIME.MultipartSigned

Quando Outlook salva un messaggio firmato S/MIME, può conservarne la busta firmata così com'è: la classe del messaggio (proprietà 0x001A) diventa IPM.Note.SMIME.MultipartSigned e la busta finisce in un allegato di nome smime.p7m e tipo multipart/signed. Intestazioni di trasporto più quell'allegato ridanno il messaggio originale byte per byte: la firma resta verificabile, e per una PEC resta verificabile la firma del gestore. È il motivo per cui una PEC salvata in MSG può ancora passare dalla verifica della PEC.

Un dettaglio che ha richiesto una correzione, e che vale la pena conoscere: la busta non comincia sempre con Content-Type. Su una ricevuta PEC del 2019 salvata da Outlook comincia con MIME-Version: 1.0 e solo dopo con Content-Type. Un controllo che guardi soltanto i primi byte la scambia per un blocco binario, la reimbusta, e la firma non si trova più. Probatio riconosce la busta dall'intero blocco d'intestazioni — righe ben formate fino alla riga vuota, con un Content-Type fra loro — e, se la busta porta già la sua MIME-Version, non ne aggiunge una seconda: i byte restano quelli originali.

Se la busta c'è ma mancano le intestazioni di trasporto, il corpo firmato è originale e le intestazioni esterne sono ricostruite; se la classe indica S/MIME ma la busta non si trova, Probatio lo dice.

winmail.dat e l'RTF compresso

Quando Outlook invia un messaggio in «formato RTF» a un destinatario esterno, impacchetta allegati e formattazione in un unico allegato, winmail.dat (formato TNEF). Qualsiasi programma diverso da Outlook mostra solo quel file opaco: gli allegati veri ci sono, ma non si vedono. È il caso più insidioso di «allegato mancante», perché chi ha ricevuto il messaggio può affermare in buona fede di non aver ricevuto alcun documento. Probatio apre il winmail.dat e ne elenca gli allegati come figli del nodo, ciascuno con le proprie impronte.

L'altra eredità di Outlook sta dentro l'MSG: molti messaggi non hanno il corpo HTML come proprietà a sé, ma lo conservano incapsulato in un RTF compresso (proprietà 0x1009, algoritmo «LZFu» descritto in MS-OXRTFCP). L'HTML originale sta nei gruppi htmltag dell'RTF, circondato da testo di resa che va scartato. Probatio decomprime l'RTF e recupera l'HTML: senza questo passaggio il corpo di quei messaggi risulterebbe vuoto.

Gli allegati sono un albero, non un elenco

Un messaggio allegato ha i propri allegati, un winmail.dat contiene file, una PEC porta il messaggio originale dentro postacert.eml. Probatio costruisce l'albero intero e dà a ogni nodo un identificativo a percorso — 1/0 è il primo figlio del secondo allegato — con cui salvarlo o aprirlo senza ambiguità. I messaggi annidati si aprono anche quando sono allegati come file .eml, .msg o .emlx invece che come message/rfc822.

Contenuti d'esempio: fattura.pdf è «%PDF-1.7», a capo, «%%EOF», a capo (15 byte); foto.jpg sono gli 8 byte della firma PNG, 89 50 4E 47 0D 0A 1A 0A; nota.txt è «Ci vediamo alle 10.» e un a capo (20 byte). SHA-256 calcolati con shasum -a 256, abbreviati; le impronte dei contenitori sono omesse.

Per ogni nodo Probatio mostra MD5, SHA-1 e SHA-256, il tipo dichiarato nel messaggio e il tipo riconosciuto dai byte. Quando il nome dice una cosa e il contenuto un'altra, lo segnala — ma solo quando il riconoscimento è certo: un testo generico o un binario non riconosciuto non contraddicono nessuna estensione, e un .docx che risulta uno ZIP non è un'anomalia, perché un .docx è uno ZIP. Sul principio dei magic bytes c'è una guida a parte: entropia e file mascherati.

L'impronta di un allegato di testo è calcolata sui byte originali, togliendo soltanto la codifica di trasporto (base64 o quoted-printable), e non sul testo già convertito in UTF-8: altrimenti un .txt in ISO-8859-1 avrebbe un'impronta diversa da quella del file allegato.

Convertire senza perdere la firma

Probatio salva il messaggio aperto — anche uno annidato — in EML, EMLX, MSG o come sole intestazioni. Le regole sono tre: lo stesso formato è una copia identica; i byte RFC 5322 si conservano dove il formato lo consente; ciò che è ricostruito si dichiara.

Da → a	Che cosa succede	Il messaggio resta identico?
Stesso formato	Copia del file, byte per byte	Sì
EML → EMLX	Messaggio incapsulato senza modifiche; il plist porta la data di ricezione ricavata dal messaggio e il flag «letto»	Sì
EMLX → EML	Estratto il messaggio incapsulato; i metadati di Apple Mail non hanno posto in un EML e non vengono riportati	Sì
EML → MSG, firmato	Forma di Outlook `IPM.Note.SMIME.MultipartSigned`, con la busta conservata byte per byte	La firma resta verificabile
EML → MSG, non firmato	Intestazioni originali in `0x007D`, corpo e allegati scomposti in proprietà, come fa Outlook	No: il MSG non contiene il messaggio
MSG → EML o EMLX	Messaggio ricostruito, marcato con l'intestazione `X-Probatio-Conversione`	No, e lo dichiara

L'intestazione X-Probatio-Conversione dice che il messaggio è stato ricostruito da un MSG, quando, e che corpo e allegati vengono dalle proprietà MAPI: chi riceve quell'EML fra un anno lo sa senza doverlo chiedere. Con una busta firmata conservata l'intestazione si aggiunge a quelle esterne e non tocca la parte firmata: una PEC che fa il giro EML → MSG → EML resta valida, e un EML che passa per l'EMLX torna identico al file di partenza.

Guardare senza farsi vedere

Il corpo HTML di un'email è materiale del reperto, e può essere ostile. L'anteprima di Probatio lo interpreta in un documento inerte e toglie script, iframe, oggetti incorporati, <base>, <meta> e ogni attributo on…; rende inerti i moduli e toglie ai link la possibilità di essere seguiti. L'indirizzo vero di ogni link resta visibile al passaggio del mouse, perché in un'analisi conta dove porta un link, non andarci.

Le immagini remote non si caricano, e il motivo ha un nome: pixel di tracciamento. È un'immagine minuscola, spesso invisibile, con un indirizzo diverso per ogni destinatario: quando il programma di posta la scarica, il server del mittente registra che il messaggio è stato aperto, quando e da quale indirizzo IP. In un phishing conferma che l'indirizzo è attivo; in una perizia direbbe a chi ha spedito il messaggio che è sotto esame, e da dove.

Se servono davvero, si caricano solo dopo una conferma esplicita, e le scarica l'app: senza cookie né Referer, solo da indirizzi pubblici (un messaggio non deve poter sondare la rete dello studio), accettando solo immagini vere e annotando nel registro attività i server contattati. Le immagini di sfondo nei CSS restano bloccate.

Dove si leggono i byte

Tutto ciò che legge i byte del messaggio — EML, EMLX, MSG, winmail.dat, RTF, MIME — gira in un processo separato. Su macOS è confinato dalla sandbox del sistema: niente rete, scrittura solo nella sua cartella di lavoro, niente avvio di altri programmi, limiti di memoria e di CPU. Se quel componente manca, il messaggio non viene aperto. Ogni operazione porta con sé l'impronta mostrata a schermo: se nel frattempo il file sul disco è cambiato, si rifiuta invece di agire su un contenuto diverso da quello visto.

Limiti

Un MSG senza busta S/MIME è un messaggio ricostruito. Impronte e firme calcolate su di esso non coincidono con quelle dell'originale. Il reperto è il file .msg; la ricostruzione serve a leggerlo.
Negli MSG, gli allegati per riferimento (Outlook conserva solo il percorso del file) non contengono il file, e gli oggetti OLE incorporati non vengono ricostruiti. In entrambi i casi Probatio lo segnala.
Del winmail.dat si estraggono gli allegati. L'eventuale corpo RTF al suo interno non viene mostrato, e un elemento che il TNEF conserva solo come oggetto incorporato (per esempio un messaggio allegato) non viene estratto.
Un .partial.emlx ha gli allegati vuoti: il loro contenuto sta in una cartella di Apple Mail, fuori dal file.
Probatio apre un messaggio per file. Gli archivi di caselle intere, mbox e PST, non sono supportati; un file oltre i 256 MB viene rifiutato con l'indicazione che probabilmente è uno di quelli.
Su Windows l'isolamento è più debole: processo separato con un tempo massimo, senza il confinamento di rete e filesystem che c'è su macOS e senza limiti di memoria.

In pratica: quale formato chiedere e conservare

Chiedi l'EML quando si può scegliere: è il messaggio com'è arrivato, senza interpretazioni, e l'impronta del file è quella del messaggio.
Un EMLX vale quanto un EML, più i metadati della casella. Conservalo così com'è: data di ricezione e flag sono dati in più, non da buttare. Controlla che non sia un .partial.emlx.
Se arriva un MSG, guarda la classe. IPM.Note.SMIME.MultipartSigned significa che la busta firmata c'è e la firma si può verificare. Altrimenti scrivi in relazione che il messaggio è ricostruito, e cita l'impronta del file .msg. Se la fonte è ancora disponibile, chiedi lo stesso messaggio anche in EML.
Calcola l'impronta del file ricevuto prima di tutto, e conserva quello. Le conversioni servono a leggere o a consegnare, non a sostituire il reperto.
Apri sempre i winmail.dat. Il documento che «non è mai arrivato» spesso è lì.
Non caricare le immagini remote se l'accertamento non lo richiede. Se lo richiede, annota che lo hai fatto, e quando.

Il Visualizzatore email di Probatio riconosce i tre formati dai byte, non dall'estensione: un .msg rinominato in .eml resta un MSG. Un'email salvata vale per ciò che conserva del messaggio arrivato, e sapere quale dei tre file hai in mano è il primo dato da scrivere in relazione.

EML, EMLX e MSG: che cosa contiene un'email salvata