Come si contesta l'autenticità di una email
Il campo «Da:» di un messaggio di posta è scritto da chi spedisce, esattamente come il mittente sul retro di una busta. Chiunque può scriverci quello che vuole. Le righe che contano sono altre, e stanno in una parte del messaggio che i programmi di posta, per default, non mostrano.
La regola procedurale che viene prima di tutto
Prima di ogni considerazione tecnica c'è un errore procedurale che manda in fumo la maggior parte delle contestazioni: l'email va conservata e prodotta nel suo formato originale, con le intestazioni integre.
Una stampa non serve: contiene solo la parte cosmetica. Un inoltro non serve: è un nuovo messaggio, generato dal suo programma, che cita il testo del precedente e ne perde le intestazioni originali. Una copia incollata in un documento non serve per la stessa ragione. Quello che serve è il file del messaggio — l'estensione varia con il programma, ma è sempre lo stesso oggetto: un file di testo che contiene, in cima, decine di righe aggiunte dai sistemi che lo hanno maneggiato.
Se lei sa che un messaggio sarà controverso, la prima cosa da fare è farlo acquisire in formato originale dalla casella, con verifica di integrità. Il secondo posto in cui cercare, se l'originale è andato perduto, sono i registri del server di posta: conservano spesso traccia del transito anche quando il messaggio non c'è più.
Le righe Received: il percorso
Ogni server che prende in carico il messaggio aggiunge in cima una riga
Received con il proprio nome, l'indirizzo di rete di chi glielo ha
consegnato, il protocollo usato e l'ora. Il risultato è una pila: leggendola dal
basso verso l'alto si ricostruisce il tragitto dalla partenza all'arrivo.
Il punto che quasi tutti trascurano è il grado di affidabilità di ciascuna riga. Le righe non sono equivalenti, perché non sono state scritte dallo stesso soggetto:
- Le righe scritte dai sistemi del destinatario — quelle in cima — sono attendibili quanto lo è quell'infrastruttura. Registrano un fatto avvenuto sotto il controllo di chi riceve.
- Le righe più in basso, che descrivono i primi passaggi, possono essere state fabbricate insieme al resto del messaggio: chi confeziona un messaggio falso scrive le intestazioni che vuole.
Da qui la regola pratica dell'analisi: si risale dall'alto verso il basso finché le righe sono verificabili, e ci si ferma dove finisce ciò che si può controllare. La prima riga aggiunta dal primo server di cui ci si può fidare è il punto in cui il messaggio è entrato nel mondo verificabile. Tutto ciò che sta sotto è dichiarazione del mittente.
È anche il motivo per cui, quando il messaggio contestato è stato ricevuto da una casella aziendale, i registri di quel server valgono più del messaggio stesso.
SPF, DKIM, DMARC: che cosa dimostrano davvero
Tre meccanismi, oggi attivi su quasi tutti i domini gestiti con criterio, lasciano tracce verificabili. Vale la pena capire che cosa ciascuno affermi, perché vengono spesso confusi.
SPF
Il titolare di un dominio pubblica nel sistema dei nomi l'elenco dei server autorizzati a spedire per suo conto. Il server ricevente confronta l'indirizzo da cui arriva il messaggio con quell'elenco e registra l'esito. Un esito negativo su un messaggio che dichiara di provenire da quel dominio è un elemento di sospetto rilevante. Attenzione però al limite: SPF verifica l'indirizzo tecnico del mittente di busta, che non è necessariamente quello mostrato all'utente.
DKIM
È l'elemento più forte. Il server del mittente appone una firma crittografica su una porzione definita del messaggio — di norma alcune intestazioni e il corpo — usando una chiave privata; la corrispondente chiave pubblica è pubblicata nel sistema dei nomi del dominio. Se la firma verifica, si può affermare due cose: che quel contenuto è transitato per un server autorizzato da quel dominio, e che le parti coperte dalla firma non sono state alterate da allora.
Se la firma non verifica, le ipotesi sono almeno tre e vanno tenute distinte: il messaggio è stato modificato; la firma non c'era; oppure — ed è il caso più insidioso — la chiave con cui era stata apposta non è più pubblicata.
DMARC
Lega i due precedenti al dominio visibile all'utente, richiedendo che quello verificato e quello mostrato coincidano, e istruisce il ricevente su che cosa fare quando non è così. La sua presenza rafforza il valore degli altri due controlli.
Il problema del tempo
La verifica di DKIM si può rifare a distanza di anni, ma solo finché il dominio pubblica ancora la chiave. Le chiavi vengono ruotate per ragioni di sicurezza, i domini cambiano gestore, le aziende chiudono. Una firma che oggi non verifica non prova che il messaggio sia falso: può semplicemente non essere più verificabile. È una distinzione che va scritta nella relazione, perché è esattamente il punto su cui una conclusione affrettata verrebbe smontata.
La conseguenza pratica è sempre la stessa: acquisire presto. Il valore probatorio di un'email si deteriora con il tempo, non perché il file cambi, ma perché cambia il mondo intorno a lui.
La posta certificata
La posta elettronica certificata è un sistema diverso e va trattato con le sue regole, fissate dal d.P.R. 68 del 2005 e dal Codice dell'amministrazione digitale. Il valore probatorio non sta nel messaggio, sta nelle ricevute generate e firmate dai gestori.
- La ricevuta di accettazione attesta che il gestore del mittente ha preso in carico il messaggio, con data e ora.
- La ricevuta di consegna attesta che il messaggio è stato depositato nella casella del destinatario, e contiene il messaggio originale.
Le distinzioni che contano nella pratica:
- La consegna attesta il deposito nella casella, non la lettura. È il punto che ricorre nelle eccezioni sulle notifiche.
- Le ricevute sono firmate dal gestore: la firma è verificabile, e la verifica è la prima cosa da fare quando l'autenticità è contestata.
- Il messaggio originale viaggia allegato alla busta di trasporto: è da lì che va estratto per l'analisi, non dalla visualizzazione del programma di posta.
- Una PEC che scrive a una casella ordinaria perde le garanzie sul versante del destinatario; il contrario, allo stesso modo.
Il sistema sta evolvendo verso il modello europeo dei servizi elettronici di recapito certificato previsto dal regolamento eIDAS, che porterà con sé regole di interoperabilità e di identificazione più stringenti. Le questioni sulle ricevute, nella sostanza, restano quelle.
Le domande da porre
Se deve impostare una contestazione, questi sono i quesiti che nella mia esperienza producono risposte utilizzabili, perché sono verificabili e circoscritti:
- Il messaggio è stato acquisito nel formato originale, con le intestazioni integre?
- Qual è la prima riga
Receivedattribuibile a un'infrastruttura verificabile, e che cosa attesta? - Il messaggio reca una firma DKIM del dominio dichiarato? Verifica? Se non verifica, la chiave è ancora pubblicata?
- L'esito del controllo SPF risulta registrato dal server ricevente?
- Le marche temporali dei diversi passaggi sono coerenti fra loro e con la data dichiarata, tenuto conto dei fusi orari?
- Esistono, presso il server ricevente, registri di transito relativi a quel messaggio?
Un quesito formulato come «se il messaggio sia autentico» ottiene, quasi sempre, una risposta più debole di quanto avrebbe potuto essere.