Davanti a un'email sospetta, quasi tutti gli strumenti guardano le parole: «urgente», «account sospeso», «clicca qui». Probatio no, ed è una scelta di prodotto. Un indicatore è un fatto che chiunque può ricontrollare sul file o nel DNS — un'intestazione, un'impronta, un record pubblicato — oppure non è un indicatore.

Perché le parole non contano

La regola è nata da un falso allarme: un'email legittima di un servizio clienti, segnalata come sospetta perché conteneva un «clicca qui» verso l'informativa privacy, un link http alla home del negozio, il testo d'anteprima nascosto tipico delle newsletter e due firme DKIM, del mittente e del servizio d'invio. Nessuno di questi elementi, da solo, dice qualcosa; sommati come indizi, davano un verdetto sbagliato con il tono di uno giusto.

L'avviso vero della banca usa le stesse parole di quello falso: giudicare dal lessico è un'interpretazione, e un'interpretazione presentata come controllo non regge al controesame. Per la stessa ragione Probatio non tiene elenchi di marchi, non misura quanto un dominio «somigli» a un nome famoso, non assegna reputazioni a domini di primo livello o fornitori di hosting e non trae conclusioni dal nome inverso di un server: un dyn o un pool nel nome non provano niente. Quel messaggio oggi esce senza rilievi, ed è uno dei test del modulo.

Tre fonti, tre pesi

Il rapporto tiene separate tre specie di informazione, che valgono in modo diverso.

Fonte	Esempi	Quando è stata prodotta
Il messaggio	intestazioni, percorso dei server, link, allegati, impronta del corpo DKIM	è nel file e non cambia
Il server del destinatario	`Authentication-Results`, `Received-SPF`	al momento della consegna
Le verifiche di oggi (facoltative)	chiave DKIM e record SPF/DMARC nel DNS, nome inverso e titolare degli IP	adesso: il DNS può essere cambiato

Per l'autenticità del mittente fa fede la seconda riga, il giudizio dato all'arrivo; le verifiche di oggi lo confermano o lo contestualizzano, non lo sostituiscono.

Il percorso: le Received si leggono dal basso

Ogni server che prende in carico un messaggio aggiunge una riga Received, uno dei campi di traccia del formato RFC 5322, in cima alle intestazioni. Ne risulta una pila in cui l'ultimo passaggio sta in alto e il primo in basso: per ricostruire il viaggio si legge dal fondo. Probatio lo fa per te, numera i salti in ordine cronologico e per ciascuno riporta host e IP di provenienza, server ricevente, protocollo, TLS e ora.

Il primo IP pubblico dal basso è l'origine; l'ultimo è quello che ha consegnato, su cui si valuta SPF. L'esito della consegna sta in cima.

Sulle ore i controlli sono aritmetici: un salto che precede quello prima di lui di oltre cinque minuti (orologi sbagliati o righe inserite a mano), una consegna durata più di un giorno, una data Date successiva di oltre un'ora all'arrivo sull'ultimo server o anteriore di oltre sette giorni alla partenza.

Ogni IP viene classificato: privato, loopback, link-local, CGNAT, riservato, pubblico. Il primo IP pubblico in ordine cronologico è l'IP d'origine. Con le verifiche in rete, per i primi otto IP pubblici Probatio legge il nome inverso (PTR), controlla che punti di nuovo allo stesso IP (forward-confirmed reverse DNS) e chiede via RDAP a chi è assegnato il blocco: rete, organizzazione, paese, contatto abuse. Dati da riportare, non da interpretare.

Una cautela che vale per qualunque strumento: le righe Received più in basso sono state scritte da chi ha spedito o da server sotto il suo controllo. Sono dichiarazioni; fanno fede solo quelle aggiunte dai server del destinatario.

SPF: alla consegna e oggi

SPF (RFC 7208) risponde a una domanda precisa: l'IP che ha consegnato il messaggio era autorizzato a spedire per il dominio del mittente di busta, quello del Return-Path? Non il «Da» che legge l'utente: il mittente tecnico.

L'esito della consegna sta nelle intestazioni Authentication-Results o Received-SPF scritte dal server ricevente. Probatio legge il blocco più in alto — l'ultimo aggiunto — e avverte se ce n'è più d'uno, perché quelli sotto può averli scritti chiunque. Un spf=fail pesa come rilievo medio, un softfail come basso.

Con le verifiche in rete, Probatio rifà la valutazione sul record pubblicato oggi. Prende l'IP dal client-ip= di Received-SPF o, in mancanza, dall'ultimo salto con IP pubblico; prende il dominio dal Return-Path o, in mancanza, dal «Da». Segue include, redirect, a, mx, ip4, ip6 ed exists, rispetta il limite di 10 interrogazioni DNS della norma (oltre, permerror) e mostra la traccia di ogni passo, così che il risultato si possa rifare a mano.

I due esiti possono differire, e il rapporto lo segnala. Le ragioni sono di solito banali: il dominio ha cambiato fornitore di posta, il fornitore i propri indirizzi, qualcuno ha corretto un record. Per questo l'esito di oggi è una conferma, mai il dato primario: un SPF che fallisce oggi non dimostra che fallisse il giorno della consegna.

DKIM: due verifiche da non confondere

Una firma DKIM (RFC 6376) è un'intestazione DKIM-Signature aggiunta dal server d'invio. Contiene, fra l'altro, il dominio firmatario (d=), il selettore (s=), l'impronta del corpo (bh=) e la firma vera e propria (b=). Ne derivano due controlli diversi.

L'impronta del corpo si ricalcola sul file, con la canonicalizzazione dichiarata (simple o relaxed) e l'eventuale limite di lunghezza l=. Non serve la rete e non dipende dal tempo: se torna, il corpo è quello firmato; se non torna, testo o allegati sono cambiati dopo la firma (anche innocentemente, se una lista di distribuzione aggiunge un piè di pagina: per i messaggi di lista il rilievo scende da medio a basso).
La firma richiede la chiave pubblica, che sta nel DNS al nome <selettore>._domainkey.<dominio>: con s=sel2026 e d=example.net si interroga sel2026._domainkey.example.net. Probatio verifica rsa-sha256, rsa-sha1 ed ed25519-sha256 (RFC 8463) e segnala le chiavi RSA sotto i 1024 bit.

La seconda verifica è di oggi. Le chiavi ruotano, e una chiave tolta dal DNS non rende falsa una firma valida il giorno della consegna: il rapporto scrive «la chiave può essere stata ruotata dopo l'invio», non «firma non valida». Un record con p= vuoto è una chiave revocata dal dominio, e come tale è riportato.

DMARC: il dominio che vede il lettore

SPF e DKIM autenticano domini che l'utente non vede: il mittente di busta e il firmatario d=. DMARC (RFC 7489) li collega al dominio del «Da», quello mostrato dal programma di posta, chiedendo che almeno uno dei due sia allineato con esso.

Probatio riporta l'esito dmarc= del server ricevente — un fail è l'unico esito di autenticazione che pesa come rilievo alto — e calcola da sé l'allineamento del «Da» col dominio del Return-Path e con i domini DKIM, questi solo se l'impronta del corpo torna. Senza rete il confronto è rilassato: basta lo stesso dominio organizzativo, ricavato dalla Public Suffix List incorporata nel programma. Così posta.comune.milano.it appartiene a comune.milano.it, e comune.milano.it non è lo stesso dominio di truffa.milano.it, perché milano.it è un suffisso pubblico.

Con la rete Probatio cerca il record come prevede la norma: prima in _dmarc. seguito dal dominio esatto del «Da», poi in _dmarc. seguito dal dominio organizzativo, e dice su quale dei due l'ha trovato. Ne mostra la policy p= e legge le modalità di allineamento aspf= e adkim=: senza il tag, o con r, vale il confronto rilassato; con s (stretta) serve il dominio esatto, e il calcolo si restringe di conseguenza. Un dominio senza DMARC è un rilievo basso, perché chiunque può usarlo come mittente senza che i destinatari se ne accorgano.

Il rapporto lo ripete ogni volta: un DMARC superato dice che il dominio mostrato è autentico, non che chi lo usa sia in buona fede. Un dominio registrato dall'attaccante lo supera benissimo.

I link: il testo e la destinazione

Nessun link viene aperto, mai: Probatio li legge dal codice del messaggio (<a href>, moduli, aree cliccabili, indirizzi nel testo). La regola centrale riguarda il link il cui testo è a sua volta un indirizzo: se il testo mostra un host e l'href porta a un altro, è un rilievo alto. Il confronto è sugli host, dopo aver tolto un eventuale www.: percorso, porta e parametri non contano, e un sottodominio dello stesso dominio, in un verso o nell'altro, è coerente. È un confronto esatto fra stringhe, senza approssimare il «dominio registrabile».

Percorso, porta e parametri non entrano nel confronto: nella terza riga il dominio della banca compare nella querystring, ma l'host è evil.test.

La terza riga è una tecnica diffusa: la destinazione nomina il dominio della banca nella querystring, perché a un'occhiata l'indirizzo sembri giusto; confrontando gli host il trucco cade. La quarta mostra il limite onesto della regola: se il testo non è un indirizzo, non c'è niente da confrontare.

Gli altri fatti che si leggono su un link: punta a un indirizzo IP invece che a un nome; contiene una @ prima dell'host, per cui in https://www.banca.example@evil.test/ la destinazione è evil.test; usa gli schemi javascript:, data:, vbscript: o file:, o è la destinazione di un modulo (tutti rilievi alti). Pesano come medi un dominio in punycode (xn--) o con caratteri non ASCII, un accorciatore di link — il fatto è che la destinazione vera non compare nel messaggio — e un link che scarica un eseguibile, uno ZIP o un'immagine ISO.

Un link http non cifrato è una nota, non un indizio: molti siti legittimi ne hanno ancora. Le immagini remote vengono contate e non caricate, perché aprirle direbbe al mittente che il messaggio è stato letto, quando e da quale indirizzo.

Gli allegati

Gli allegati si esaminano sull'intero albero, compresi i messaggi inoltrati come allegato e i contenitori winmail.dat di Outlook. Anche qui solo fatti: doppia estensione (fattura.pdf.exe), spazi o caratteri che invertono il verso del testo per nascondere l'estensione vera, tipo reale riconosciuto dai byte diverso da quello dichiarato, estensioni che eseguono codice, pagine web allegate, documenti con macro, PDF con JavaScript o /Launch, archivi ZIP cifrati che nessun antivirus può ispezionare, documenti che all'apertura caricano un modello da Internet.

YARA: «non ho potuto guardare» non è «pulito»

Se le regole YARA sono attive, Probatio le scarica dall'endpoint configurato e le applica al messaggio intero e a ogni allegato (i primi 64 MiB di ciascuno). Un riscontro è un rilievo alto. Se l'endpoint non risponde, il rapporto lo dichiara per quello che è: una scansione non eseguita non è una scansione negativa, e scriverle allo stesso modo sarebbe un errore.

Il punteggio, e cosa non significa

I rilievi hanno pesi dichiarati: alto 25, medio 10, basso 3; le note informative e i segnali positivi valgono zero. La somma, fino a 100, dà il verdetto: alto da 50 in su o con almeno due rilievi alti, medio da 20 o con un rilievo alto, basso sopra zero. Ogni rilievo porta il fatto da cui nasce, perché il perito possa ricontrollarlo.

«Nessun indicatore» significa che i controlli automatici non hanno trovato segnali, non che il messaggio sia sicuro. Il rapporto lo scrive con queste parole.

Privacy: cosa esce dal computer

Il messaggio si legge in un processo isolato, senza rete. Le verifiche in rete — facoltative, si disattivano con una casella prima dell'analisi — lavorano sui soli dati estratti: domini e indirizzi IP. Le interrogazioni DNS passano da DNS-over-HTTPS, prima Cloudflare e in ripiego Google; quelle sui titolari degli IP dal servizio RDAP rdap.org. Nessun server indicato dal messaggio viene contattato direttamente: una query su un dominio dell'attaccante arriva comunque al suo server DNS, ma tramite il resolver pubblico, senza il tuo indirizzo IP.

Senza rete restano percorso, esiti del server ricevente, impronta del corpo DKIM, link e allegati; mancano firma DKIM, SPF di oggi, record DMARC, nomi inversi e titolari degli IP.

Limiti

Le macro SPF (%{…}) non sono valutate: il record è dichiarato «non valutabile», non indovinato. Il meccanismo ptr, deprecato, è contato ma non valutato.
SPF e chiave DKIM di oggi non sono quelli della consegna; senza rete, di DKIM si verifica solo l'impronta del corpo.
Senza rete l'allineamento DMARC è calcolato in modalità rilassata: le modalità aspf/adkim si conoscono solo leggendo il record. La Public Suffix List è quella incorporata nella versione in uso.
Le intestazioni ARC non entrano nella valutazione.
Degli archivi cifrati si riconoscono solo gli ZIP: un 7z o un RAR protetto da password non è segnalato come tale.
Un file MSG senza le intestazioni di trasporto originali non permette di analizzare percorso e autenticazione: serve l'.eml esportato dalla casella.
Il significato del testo non viene analizzato. È una scelta, non una mancanza.

Il modulo è descritto nella scheda Analisi phishing; per la struttura dei file .eml, .emlx e .msg vedi la guida sui formati dei file email.

Un rapporto costruito così dice meno cose di uno che giudica le parole. Ma ognuna si può rifare: con le intestazioni sotto gli occhi, con una query DNS, con un calcolo d'impronta. È questo che lo rende utilizzabile in perizia.

Analizzare un'email sospetta: solo fatti verificabili