Posta elettronica e valore documentale

Proseguo l’esplorazione nel mondo dell’e-mail per evidenziare le connessioni fra informatica e archivi, la comunanza di esigenze e strumenti. Dopo la connessione con il vincolo archivistico, adesso tocca a integrità e provenienza che, insieme, concorrono all’autenticità o, se si vuole essere più generali all’affidabilità di un documento, cioè al livello di fiducia che vi si può riporre. Entriamo un po’, quindi, nel mondo della diplomatica^[1]La diplomatica è quella disciplina che si occupa del documento in quanto tale, al fine di apprezzarne l’autenticità e la sua capacità di produrre effetti giuridici e avere forza di prova. … Continue reading.

A tal proposito, il Codice dell’amministrazione digitale^[2]All’articolo 20. afferma che, in generale, il documento informatico, comunque composto, è liberamente valutabile in giudizio, rispetto al suo valore giuridico-probatorio, tenuto conto delle sue caratteristiche di sicurezza, integrità e immodificabilità (e, aggiungo io, riconducibilità certa la suo autore, altrimenti detta “provenienza“). Quella valutazione non può prescindere da conoscenze tecniche sulle modalità di formazione e trasmissione di documenti informatici. Con questo contributo, quindi, intendo anche fornire le conoscenze di base, semplici ma corrette, per muoversi nella valutazione dell’attendibilità di un messaggio e-mail.

Avvertenza: per incisività comunicativa non sarà possibile trattare tutti i casi e le variazioni sul tema. Come detto, delle semplificazioni sono d’obbligo. Non si intende essere esaustivi e completi dal punto di vista informatico, ma solo fornire gli strumenti, anche a livello di suggestione, per valutare l’affidabilità dei messaggi e-mail che quotidianamente tutti riceviamo e che, talvolta, possono diventare elemento probatorio in qualche controversia.

Il protocollo per lo scambio di messaggi e-mail tramite internet e le sue numerose appendici prevedono alcuni strumenti per verificare l’affidabilità di alcuni dati associati ai messaggi e-mail (per esempio, mittente e oggetto) e anche del contenuto stesso. Questi strumenti di validazione sono per lo più “nascosti” nell’intestazioni (header) dei messaggi e-mail e si potrebbero definire “metadati“, così da sfruttare l’onda del clamore suscitato, almeno fra fanatici e addetti ai lavori, da un recente provvedimento del Garante per la protezione dei dati personali.

Vediamo quali sono questi strumenti di validazione e le loro connessioni con il valore documentale del messaggio e-mail. Per maggiore chiarezza riporto anche degli esempi, tratti da messaggi reali.

Indirizzi IP e nomi di dominio

Ogni dispositivo, in particolare server, connesso a internet ha un indirizzo numerico, detto indirizzo IP, tradizionalmente della forma xxx.xxx.xxx.xxx^[3]Dove xxx è un numero fra 1 e 256, vale a dire 8 bit, ma sono dettagli. Poi ci sarebbero anche gli IP di versione 6 che sono piu’ lunghi, con cifre esadecimali, ma anche quelli sono dettagli … Continue reading. Sui siti web però ci andiamo perché ce ne ricordiamo il nome detto a parole o lo cerchiamo su un motore di ricerca. Esiste un meccanismo per cui i nomi dei siti (e dei server in genere) sono “risolti” (tradotti) nei rispettivi indirizzi IP, numerici.

Alla base del meccanismo c’è il DNS (Domain Name System). Il proprietario di una risorsa su internet registra un nome di dominio (l’indirizzo mnemonico) e lo associa all’indirizzo IP. L’associazione entra nella grande banca dati DNS (che in realtà è un database distribuito, composti di nodi e nameserver, ma poco ci interessa). L’inserimento di una voce nel DNS non è libera, ci sono delle autorità preposte e occorre dimostrare di essere proprietari della rispettiva risorsa per registrare un nome di dominio.

Un indirizzo di posta elettronica, lo ricordiamo, è composto da un nome utente (nome della casella) e da un dominio, separato dal simbolo @.

Un messaggio di posta elettronica, invece, è composto da una parte di intestazioni (o header, in inglese) e una parte di corpo (o body), al pari di molti altri oggetti digitali^[4]Per esempio una pagina HTML, il cui header contiene dati fondamentali per la sua corretta visualizzazione.. I programmi di posta elettronica mostrano principalmente il corpo del messaggio (testo e allegati), mentre delle intestazioni prelevano e mostrano solo i dati più significativi per identificarlo: mittente, destinatario, oggetto e data. Le intestazioni, però, contengono molto di più^[5]Ho aggiunto questo paragarafo successivamente alla prima pubblicazione per completezza di esposizione..

La voce DNS

Una voce di DNS non si limita a contenere l’associazione fra un nome mnemonico e un indirizzo IP, ma contiene molte più informazioni, anche perché lo scambio di dati via internet è qualcosa di molto articolato^[6]Basti pensare che associato a un nome di dominio ci sono quasi sempre un sito web e anche un sistema di posta elettronica. La complessità non si ferma comunque qui.

Per ogni voce sono presenti più tipi di record, ciascuno dei quali veicola informazioni diverse relativamente al nome di dominio. Ai fini della posta elettronica sono rilevanti il record MX (che indica l’indirizzo IP a cui inviare i messaggi di posta indirizzati a un certo dominio) e il record TXT che contiene informazioni di tipo testuale (sarà chiaro in seguito la sua importanza).

Da ogni computer connesso a internet, tramite comandi forniti “di serie” con il sistema operativo, si possono fare interrogazioni del sistema DNS. Per esempio, nei computer Windows esiste il comando nslookup:

> nslookup cultura.gov.it
Server:  UnKnown
Address:  2001:b07:2eb:baf4:c644:7dff:fec1:ce64

Risposta da un server non autorevole:
Nome:    cultura.gov.it
Address:  2.42.229.1

Esistono anche servizi online che consentono interrogazioni specifiche di una voce DNS o avere una visione di insieme^[7]Si segnala, fra i tanti, https://www.dnsqueries.com/..

E’ importante sottolineare che tutto ciò che compare nella voce DNS relativa a un nome di dominio è riferibile, come provenienza, al titolare del nome stesso, perché solo questi (o altro soggetto da questi autorizzato) può avervi accesso e modificarla^[8]Talvolta, per dimostrare a qualcuno di essere titolari di un nome di dominio, può essere richiesto di inserire, anche temporaneamente, un record di tipo TXT, con una stringa di testo concordato. … Continue reading.

SPF (Sender Policy Framework)

Un po’ a tutti è capitato di ricevere mail truffaldine che riportano, come mittente, un indirizzo noto o comunque riconoscibile. Questo non vuol dire che il truffatore di turno ha avuto accesso alla casella e-mail di qualcuno ma, semplicemente, si sta fingendo qualcun altro perché alcuni server di mail consentono di indicare come mittente qualsiasi indirizzo e-mail, anche inesistente.

Il phishing fa leva su questo (e altro). Tecnicamente un server e-mail può mandare un messaggio indicando qualsiasi mittente, anche uno di un dominio differente dal suo.

Il Sender Policy Framework (SPF) ha proprio l’obiettivo di indicare, per ogni nome di dominio registrato, da quali server è lecito far partire messaggi con mittente in quel dominio. Il destinatario (o, meglio, il server del suo gestore di posta elettronica), non appena riceve un messaggio, confronta l’indirizzo IP del server di provenienza reale dell’e-mail con quelli autorizzati per il dominio di posta dell’apparente mittente. Solitamente il server di posta destinatario aggiunge un metadato nell’intestazione con l’esito della verifica del record SPF (per esempio, “SPF = passed“).

Se l’IP non è autorizzato, non necessariamente il messaggio viene scartato; solitamente questa evenienza comporta “solo” un aumento del punteggio di spam^[9]I sistemi antispam integrati nei server di posta eseguono una serie di test su ogni messaggio e per ogni test assegnano un punteggio (più il punteggio è alto più c’è odore di spam). Se la … Continue reading.

L’elenco dei server autorizzati all’invio per conto di un certo dominio è contenuto in un record di tipo TXT della voce DNS del dominio. Per esempio, l’INPS ha impostato il suo SPF in questo modo:

inps.it text =

        "v=spf1 include:spf.protection.outlook.com ip4:89.97.177.19 ip4:89.97.177.3 ip4:93.63.43.112 ip4:93.63.43.115 ip4:93.63.43.113 ip4:93.63.43.114 ip4:89.97.59.100 ip4:89.97.59.101 -all"

I server di posta “seri”, comunque, non accettano di inviare e-mail in cui compare un mittente di un dominio esterno, ma questo esula dagli scopi di questo articolo.

DKIM (DomainKeys Identified Mail)

Il DomainKeys Identified Mail (DKIM) è un metodo tramite il quale il server mittente dell’e-mail^[10]O uno dei soggetti che partecipa all’invio del messaggio, non entriamo nei dettagli e semplifichiamo. applica una firma elettronica ad alcune parti del messaggio per garantirne integrità e provenienza. Il meccanismo di firma è quello delle chiavi asimmetriche, che ho spiegato qui e qui. Le chiavi non sono rilasciate da un soggetto terzo (una Certification Authority) ma sono create dal soggetto che appone la firma. Il soggetto stesso memorizza e rende disponibile la chiave pubblica sul suo record DNS. Anche se non interviene un soggetto terzo autorevole, la coppia di chiavi autoprodotta è sufficiente a garantire che la firma apposta sia quella del titolare del nome di dominio, perché solo lui può accedere alla voce DNS per inserirvi la chiave pubblica.

Se il mittente ha implementato DKIM, le intestazioni (header)^[11]Per visualizzare le intestazioni di un messaggio e-mail, solitamente i programmi o le webmail mettono a disposizione un comando del tipo “vedi messaggio completo”, “visualizza … Continue reading presentano un blocco di informazioni, individuato dal tag DKIM-Signature, di questo tipo^[12]Ho preso come esempio l’e-mail ricevuta da pagoPA che comunicava l’avvenuto pagamento già protagonista di un altro post sul blog.:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pagopa.gov.it;
	s=pagopa-20201113; t=1707853666;
	bh=GX6eZz2IxRwXplH5Qams8tugh3XzMGLX5NFtpbVBkEI=;
	h=Date:From:To:Subject:From;
	b=TjGifl3FAjPBlnfDxGiZB6J0laYytdTUH3g9ZBS0zRp/yIMbbS+oGuom/XtqgtjOI
	 EBE1h6/ZDFWPYA349FtPTwssKvxmmB/NMfJ7L25qUtxPkwIedNLhxct4qRdG/0GiL5
	 dL31st7dlFZ2wqlUk2dOzE8Zjglkqvdmam3zwJYP3h6bwSSDXRWTo1lhEXOr725ZQt
	 mfD07xWeERFvcS8hdhCvCCx+/H1bDJzYF85Rvg8sZjPMk9X+i1bNYeMvRfqF5mru6C
	 RHGlkD2Ehanch8wDoZ4ep7iLp/sXNvyvV03sL+R2O0GOJs5mT42niJiBmk7oi6imqg
	 kugZx1DsBchoA==

I dati esposti sono preceduti da lettere/sigle che ne spiegano il significato:

• v: versione delle regole DKIM applicate;
• a: algoritmo di firma usato;
• d: dominio che firma;
• s: sta per “selector” e serve per recuperare la chiave pubblica;
• t: timestamp del momento della firma;
• bh: impronta (hash) del corpo (body) del messaggio;
• h: elenco dei campi dell’intestazione (header) che sono stati firmati:
• b: firma di intestazione e corpo del messaggio (r

DKIM prevede anche altri dati (opzionali), ma non è il caso di elencarli.

Quando il server del destinatario riceve il messaggio, utilizza i valori di d e s e recupera la chiave pubblica:

nslookup -type=TXT pagopa-20201113._domainkey.pagopa.gov.it

Server:  UnKnown
Address:  2001:b07:2eb:baf4:c644:7dff:fec1:ce64

Risposta da un server non autorevole:
pagopa-20201113._domainkey.pagopa.gov.it        text =

        "v=DKIM1; k=rsa; s=email; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5rE8o8ElzT5ZzDQGmEuQYCu//Oq6GkS2bQSorip/64GTMW4CoakzLVq2NqKcLIBOf5POPTadM2Y4yrkzIMGGy0ZCNtQuBtH/Ng64HdvVgYIqzh4loeFUQIiasi31wr31ZrPgp1B3tGk2urhHhnADdeuaQ2hiSAxok4uODvpZTjLJKmRJnB9hY1q"
[...]

Quindi decifra la firma (valore di b) e la confronta con l’hash del corpo e con i pezzi di intestazione che sono stati firmati dal mittente^[13]Ammetto di aver provato una verifica ma non sono riuscito a decifrare la firma… Al di là dei dettagli tecnici di codifiche e concatenazione di dati, la logica di base dovrebbe essere chiara..

L’esito della verifica è aggiunto dal server destinatario, come metadato, in un’altra sezione dell’intestazione, identificata dall’etichetta Authentication-Results:

Authentication-Results: mx***e**.a*.******.it;
	dkim=pass header.d=pagopa.gov.it header.b=TjGifl3F;
	dmarc=pass header.from=pagopa.gov.it

Anche in questo, se la verifica della firma DKIM fallisce, il messaggio non viene scartato automaticamente, ma ogni gestore di posta adotta le sue scelte che, sicuramente, influiscono sul punteggio assegnato dal sistema antispam.

Se la verifica DKIM ha successo, si può stare certi che il messaggio proviene dal dominio che l’ha firmato (valore d) e che è integro, cioè che non ha subito alterazioni durante la trasmissione.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

I metodi di autenticazione^[14]Qui e nel seguito per autenticazione si intende la verifica dell’autenticità, un processo tipico della diplomatica. SPF e DKIM sortiscono i migliori effetti quando applicati congiuntamente e si verifica allineamento fra il nome che compare come mittente del messaggio, il dominio che compare nella firma e il dominio a cui appartiene il server che ha inviato il messaggio.

A questo fine è stato elaborato il protocollo DMARC (Domain-based Message Authentication, Reporting and Conformance) che consente a un dominio di stabilire le regole con cui i destinatari devono processare i messaggi apparentemente provenienti dal dominio, in base ai risultati dei controlli SPF e DKIM.

Queste regole sono definite e rese note, ancora una volta, in un record di tipo TXT della voce DNS:

nslookup -type=TXT _dmarc.pagopa.gov.it
Server:  UnKnown
Address:  2001:b07:2eb:baf4:c644:7dff:fec1:ce64

Risposta da un server non autorevole:
_dmarc.pagopa.gov.it    text =

        "v=DMARC1; p=quarantine; rua=mailto:dmarc@0f1qy7b5.uriports.com"

Il record, estratto dalla voce DNS del dominio pagopa.gov.it, mostra la versione del protocollo DMARC usato (v), la politica (p) da applicare ai messaggi che falliscono l’autenticazione e l’indirizzo (rua) a cui inviare i report sull’esito delle verifiche. Nel caso dell’esempio si richiede di non scartare i messaggi che non passano la verifica ma di marcarli come sospetti e metterli in quarantena (cosa che di solito si traduce nello spostarli nella cartella dello spam). Il protocollo consente anche altre opzioni per rendere più raffinato il controllo.

Il senso del record TXT con la regola DMARC, volendolo parafrasare, è più o meno: “io ho implementato correttamente SPF e DKIM, sono convinto di aver inserito nel record SPF tutti i server che inviano posta dal mio dominio e che tutti applichino correttamente la firma DKIM. Se ricevi una mail non conforme puoi marcarla come spam [/rifiutarla]. Mandami un report periodico così da valutare l’efficacia del sistema e intraprendere eventuali azioni a tutela della reputazione del mio dominio di posta”.

Valore documentale

Quanto raccontato fin qui mostra come l’informatica applicata allo scambio di messaggi abbia ben presente e tenga in grande considerazione – e non potrebbe essere altrimenti – le questioni legate a integrità e provenienza dei messaggi stessi.

In linea di principio, se i gestori di posta elettronica hanno implementato correttamente SPF, DKIM e DMARC, possiamo essere ragionevolmente certi che le mail che riceviamo siano integre, non alterate, e, per quanto riguarda la provenienza, che provengano effettivamente dal dominio che compare come mittente^[15]La certezza del mittente inteso anche come utente del dominio non è garantita, dipende da come è configurato il server che invia il messaggio: alcuni obbligano a inserire nel campo “Da” … Continue reading.

Tutto ciò funziona finché fruiamo del messaggio tramite il software di posta (client locale o webmail che sia) e sappiamo che non ci sono state manipolazioni successive del messaggio. Infatti, i controlli SPF, DKIM e DMARC avvengono al momento in cui il nostro gestore di posta riceve il messaggio e si appresta a depositarlo nella nostra casella.

Ma se vogliamo trasferire il messaggio ad altri preservandone l’autenticità?

L’usuale comando “inoltra” (“forward”) crea un nuovo messaggio, sostituisce le intestazioni originarie con quelle del nuovo messaggio e anche le intestazioni dedicate all’autenticazione si riferiranno al nuovo messaggio. E, si sa, è ben possibile modificare un messaggio in fase di inoltro a qualcun altro.

Già più sicuro sarebbe usare il comando, non sempre disponibile, “inoltra come allegato“: in quel caso l’e-mail originaria è inserita nel nuovo messaggio come allegato, tipicamente in formato EML^[16]L’EML è il formato per memorizzare un messaggio più vicino possibile alla sua manifestazione originaria. L’EML è un formato di testo, con una sintassi specifica (derivata dalla … Continue reading. In questo modo l’e-mail inoltrata porta con sé tutti i metadati originari che consentono una nuova autenticazione.

Attenzione, però: un’autenticazione successiva al deposito sulla casella del destinatario non può limitarsi alla ricerca di un metadato del tipo “dkim=pass“. Infatti, quel metadato è stato inserito dal gestore del destinatario del messaggio prima del deposito sulla casella. Successivamente il messaggio può essere alterato. Io stesso ho provato e, anche in questo caso, non servono abilità da pirata informatico.

Infatti, basta salvare il messaggio come EML, aprirlo con un editor di testo (anche “Blocco note”), modificare qualche dato e/o il testo del messaggio, salvarlo, trascinarlo nella casella di destinazione usando un client e-mail come Mozilla Thunderbird e, grazie al protocollo IMAP, il messaggio finisce addirittura sul server di posta. Il messaggio vi compare insieme a tutti gli altri ricevuti, saltando i controlli. Se si scorre il “sorgente” del messaggio, nelle intestazione si troverà sicuramente il metadato “dkim=pass” o “spf=pass“, perché sono resti del messaggio originario. E’ evidente che, se si facesse una nuova verifica di SPF e DKIM, questa non potrebbe che fallire.

La domanda sorge spontanea: esistono strumenti per fare verifiche di autenticità con i metodi SPF e DKIM su messaggi già presenti nella casella o disponibili esternamente alla casella in formato EML?

Strumenti operativi per l’autenticazione

Personalmente, trovo che i programmi di posta elettronica, siano essi software installati localmente sul dispositivo (PC o altro) oppure interfacce webmail, dovrebbero dare maggiore risalto all’esito delle verifiche SPF e DKIM. Questo avrebbe anche l’effetto collaterale, per niente disdicevole, di diffondere un po’ di consapevolezza^[17]Poi non ci lamentiamo se in alcune sentenze di tribunale ci si rende conto che le e-mail presentate come prova sono state prodotte… in stampa!.

Gli strumenti che mi sono trovato a usare, invece, non danno alcuna visibilità all’esito dell’autenticazione. Sarebbe invece utile sapere:

• se il mittente ha implementato DKIM e SPF;
• l’esito dell’autenticazione.

Tutte le operazioni di verifica/autenticazione dei messaggi descritte – si è detto, ma lo ripetiamo – avvengono a livello di server di posta, prima del deposito del messaggio sulla casella. Una volta che il messaggio e-mail è sulla casella e può spostarsi in vario modo^[18]Un messaggio e-mail potrebbe essere inoltrato, oppure salvato localmente: entrambe le operazioni consentono alterazioni del messaggio originario. Processi di autenticazione successiva dei messaggi … Continue reading, questi strumenti di validazione rischiano di perdere di valore.

Mi ero ormai rassegnato alla situazione quando, con l’ultima ricerca sul web, ho trovato un’estensione per il client Mozilla Thunderbird che copre, almeno per la parte DKIM, questa mancanza. L’estensione si chiama DKIM Verifier. Non è mia intenzione pubblicizzarla, ma capita “a fagiuolo” per una dimostrazione pratica.

L’ho installata e ho fatto qualche prova. Intanto ho verificato che la verifica DKIM avviene in tempo reale, autenticando nuovamente il messaggio e non cercando nelle intestazioni il risultato dell’autenticazione fatta in precedenza dal server.

Un messaggio che supera il test viene mostrato così:

Il mittente sarebbe mostrato in arancione se il dominio del mittente non fosse allineato con il dominio del firmatario DKIM (può avvenire, nel caso di sottodomini, e questo non è necessariamente sintomo di non autenticità).

Ho anche provato a salvare in locale un messaggio e a modificare il messaggio e i metadati dell’intestazione con un editor di testo. Basta aprire il messaggio in Thunderbird perché DKIM Verifier lo autentichi. Dopo aver modificato le intestazioni, per la parte di mittente e destinatario, si ottiene questa segnalazione:

Se invece si modifica il testo del messaggio, la segnalazione è questa:

Quanto sopra ci mostra che il mittente ha effettivamente firmato sia il corpo del messaggio sia le intestazioni principali.

Lo stesso comportamento si ottiene quando si verifica una mail inoltrata come allegato.

Conclusioni

A conclusione del lungo percorso di illustrazione, sintetizzo qualche conclusione, in ordine sparso.

La prima è che la tanto vituperata e-mail semplice, se ben configurata lato server^[19]Vale la pena ricordare che, per godere dei benefici di DKIM, SPF e DMARC, non deve fare praticamente niente, se non affidarsi a gestori di posta “bravi”. Con DKIM, SPF e DMARC tutto … Continue reading, reca con sé strumenti di autenticazione dei messaggi che meriterebbero maggior attenzione anche da parte di archivisti e records manager.

La seconda è che c’è scarsa consapevolezza^[20]C’è anche da dire che gli strumenti a disposizione non sempre aiutano, il comando per visualizzare il “sorgente” del messaggio talvolta è davvero nascosto. Sapete, per esempio, … Continue reading sul significato e l’utilità della parte di messaggio e-mail che non si vede: le intestazioni (header). Non ci si può stupire poi che si pensi che consegnare la stampa di una e-mail sia equivalente a consegnare il corrispondente file EML, quanto al valore giuridico-probatorio. Saper leggere le intestazioni invece consente di ricavare informazioni molto utili, anche sull’attendibilità del messaggio stesso.

A corollario della seconda osservazione, due raccomandazioni:

• se serve conservare l’autenticità di un messaggio e-mail, inoltratelo come allegato: questo consente di conservare le intestazioni originarie e condurre, anche successivamente autenticazioni^[21]A fare i pignoli, l’autenticazione successiva potrebbe non andare a buon fine se, per esempio, il mittente cambia la coppia di chiavi per il DKIM e non la storicizza (col … Continue reading;
• se presentate e-mail come prove in un contenzioso, producete il file EML e non stampe. I processi, si dice, sono ormai telematici e pretendere di depositare documenti informatici (comunque da valutare nella loro qualità, ben inteso) dovrebbe essere il minimo. Poi ok le stampe di cortesia…

La terza è, ancora una volta, che informatica e archivi non sono domini contrapposti, tutt’altro. Entrambi mirano a organizzare l’informazione e si pongono scopi analoghi: in questo caso integrità e riconducibilità all’autore (provenienza) di un messaggio telematico.

Diciamone anche una quarta e ultima: sarebbe opportuno che anche chi amministra la Giustizia, come giudice, pubblica accusa o avvocato (ma anche notaio), si “sporcasse le mani” con questi meccanismi, per essere in grado davvero di esprimere un “libero apprezzamento” giudizioso e consapevole o fornire le giuste indicazioni di comportamento.

Un (ipotetico) caso pratico

Quando si tratta di comunicazioni telematiche che danno inizio o si inseriscono in un negozio giuridico, il nostro ordinamento – fra CAD, regole tecniche e linee guida discendenti – vede con netto favore l’uso della posta elettronica certificata, che:

• garantisce integrità e immodificabilità dei dati (documenti) trasmessi;
• colloca la comunicazione in un momento preciso, certificato (validazione temporale);
• garantisce che la comunicazione origini dalla casella del mittente;
• se poi l’indirizzo PEC è registrato in un qualche indice pubblico, garantisce anche la provenienza del messaggio (intesa come riconducibilità al suo autore).

Quindi, se si ha bisogno dei requisiti di cui sopra, che si usi la posta elettronica certificata e si comunichi verso una casella certificata. I requisiti sono soddisfatti ex lege, senza che siano rimessi all’apprezzamento del giudice di turno. Basta configurare il servizio PEC per rilasciare una ricevuta di consegna completa e tenere da parte, con cura, la ricevuta di consegna (che contiene tutto il messaggio inviato, allegati inclusi).

Quando questo non è possibile, vuoi perché il destinatario non ha una casella PEC, vuoi perché “è andata così, non ci ho pensato”, siamo sicuri sicuri che anche una comunicazione via e-mail, se i server coinvolti implementano gli strumenti di cui abbiamo parlato non abbia valore di prova? Non esistendo per la posta elettronica ordinaria, proprio come concetto, una ricevuta completa, tanto vale mettersi come destinatario (anche nascosto) in messaggi per i quali potrebbe essere utile avere qualche prova^[22]Per esempio, se inviamo la bozza di un articolo o di un libro e vogliamo cautelarci. Un’e-mail da sola non tutela di certo la proprietà intellettuale, nemmeno con DKIM e SPF, ma potrebbe … Continue reading.

Pensiamoci:

• la data di invio è uno dei “metadati” firmati tramite il DKIM: c’è quindi una validazione temporale, non opponibile a terzi ex lege, ma valutabile in giudizio e, probabilmente, da accogliere;
• il corpo del messaggio (e quindi gli allegati) sono anch’essi firmati tramite il DKIM: se anche non c’è riconducibilità certa all’autore dei documenti, si può ragionevolmente affermare che quegli oggetti digitali esistono in una determinata versione in un certo momento.

Ripeto, anche a scanso di equivoci, non sto dicendo che una mail normale sostituisce una PEC – la cui autorevolezza è anche garantita dall’intervento di un soggetto terzo autorevole e autorizzato dallo Stato – ma dico che, anche una comunicazione e-mail, se si sa leggere fra le righe dei suoi metadati, può avere forza di prova. Occorre, però, comprenderne il funzionamento, anche perché il rischio di falsificazione – come sempre – esiste.

Anticipazione

Giocherellando con le interrogazioni del DNS, per capire come funzionano davvero le cose, ho scoperto che la voce DNS di un’organizzazione può svelare molto di come si è attrezzata a livello informatico, quali strumenti usa. A breve un resoconto senza pretese…

Foto di Wolfgang Claussen da Pixabay