In breve: una mail che sembra arrivare dall’ufficio stampa del Comune può non esserlo — e l’email-to-publish senza verifica del mittente non è un canale comodo, è una casella aperta. Tre controlli in ordine — allowlist, autenticazione del dominio, token per i flussi delicati — separano un canale da una vulnerabilità; quello che non passa non entra nel flusso.

Lunedì mattina, ore otto. In redazione arriva una mail: “Comunicato stampa del Comune — Nuovo bando per le imprese del territorio”. Mittente visibile: ufficio stampa del Comune. Allegato con il logo dell’ente, tono istituzionale, firma del responsabile. La redattrice apre, legge, segnala al direttore: “C’è un bando del Comune, lo mettiamo in pagina?”. Il direttore dà il via, la bozza finisce in coda, il comunicato esce. Solo il giorno dopo, una telefonata dell’ufficio stampa vero chiarisce che loro non hanno mai mandato nulla.

Capita più spesso di quanto sembri — ed è proprio lo scenario in cui un’email-to-publish che sembra un canale comodo si rivela, appena lo si guarda bene, una porta aperta.

Il canale comodo non basta

L’email-in è una scelta giusta: i comunicati arrivano già in quel formato, le redazioni li ricevono da anni, i giornalisti non devono imparare niente di nuovo. Il problema non è il canale — è che un canale presuppone una soglia. Una casella aperta a tutti non è un canale: è un ingresso dove chiunque può dichiararsi chi vuole, e la redazione scopre l’inganno solo dopo aver pubblicato.

Nessun editore mette una porta senza serratura alla redazione, anche se la porta è comoda e tutti la usano. Allo stesso modo, una casella di redazione non può essere “aperta per definizione” solo perché riceve comunicati.

I tre controlli, in ordine

Verificare il mittente non significa una sola cosa. Significa tre passi distinti, ciascuno con uno scopo preciso. Si applicano in sequenza: il primo che non passa, ferma la mail.

Il primo: l’allowlist. Una lista di mittenti autorizzati, decisa dall’editore. Non dal sistema, non per default: dall’editore, perché sa chi è il Comune, chi è l’ufficio stampa di un’associazione di categoria, chi sono i clienti redazionali che possono mandare direttamente. La lista non è burocrazia: è la dichiarazione esplicita di chi può entrare in redazione via mail senza altri controlli. Una mail di un mittente non in allowlist non è “sospetta” per definizione — semplicemente non è stata autorizzata, e il sistema non la lascia passare.

Il secondo: l’autenticazione del dominio. Anche un mittente in allowlist può essere contraffatto. Le firme standard del protocollo email — SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail) — verificano che la mail arrivi davvero dal dominio dichiarato, e che non sia stata modificata lungo il tragitto. Non è un dettaglio da amministratori di sistema: è la stessa differenza che c’è tra una firma autografa e una fotocopia. Senza SPF e DKIM, l’allowlist dice “questa mail viene da quel dominio”, ma non verifica che venga davvero da lì. Inkstack verifica entrambe le cose.

Il terzo: il token concordato. Per i flussi delicati — un comunicato di un cliente redazionale che vale un contratto, un avviso di un’istituzione che ha conseguenze — un terzo livello è un token concordato fuori banda: una stringa che solo mittente e destinatario conoscono, inserita in un campo dell’email o nell’oggetto secondo un patto preciso. Non serve a tutti i messaggi. Serve quando la posta non può permettersi un dubbio: la mail arriva, il sistema verifica l’allowlist, verifica SPF/DKIM, verifica il token — solo allora entra nel flusso.

Cosa succede alla mail che non passa

Una mail sconosciuta — fuori allowlist, con SPF/DKIM che non tornano, o senza il token — non è qualcosa da gestire. Semplicemente non entra.

Non finisce in una cartella “da controllare dopo”. Non resta in attesa di qualcuno che la vagli. Non diventa un pitch con un flag rosso. Semplicemente non passa: il sistema la scarta, registra il tentativo, e la redazione non la vede. Lo stesso vale per una mail che passa i primi due controlli ma non il terzo: la mail c’è, l’identità del mittente è confermata, ma per quel flusso specifico manca il token — dunque non entra.

Questa è la differenza tra un controllo serio e un controllo di facciata. Un controllo che lascia passare la mail “perché poi qualcuno la guarderà” è un controllo che, nei giorni in cui nessuno ha tempo, diventa un buco.

L’hash dell’originale: la seconda cintura

Una volta che la mail è passata, il testo originale viene conservato con la sua impronta digitale — un hash crittografico che ne attesta l’integrità. Non è un backup: è la prova che quella mail, in quella forma, è entrata nel flusso quel giorno. Se due mesi dopo qualcuno chiede “questo comunicato è stato modificato prima di essere pubblicato?”, la risposta non è un’opinione: è un audit trail che mostra l’originale, l’hash, e i passaggi successivi. L’articolo uscito sul sito — descritto in dettaglio nell’articolo sull’email-to-publish — è etichettato e tracciato fin dal primo byte della mail di origine.

È la seconda cintura di sicurezza. La prima è la verifica del mittente. La seconda è l’integrità dimostrabile del contenuto. Inkstack è progettato per la conformità ODG 2025 e AI Act: la verifica del mittente e l’integrità dell’originale sono i meccanismi su cui poggia la tracciabilità richiesta da quegli obblighi.

Il canale resta comodo

Tutto questo sembra, a leggerlo, un appesantimento del flusso. Non lo è. Per chi è in allowlist, con SPF/DKIM in regola, l’email-in funziona esattamente come prima: la mail arriva, viene processata, la bozza finisce nella coda del direttore. I controlli pesano zero per il mittente legittimo.

Quello che cambia è la posizione della redazione: prima accettava tutto e filtrava dopo; ora filtra prima e processa dopo. È la stessa differenza che c’è tra un portiere che lascia entrare chiunque e poi controlla, e un portiere che controlla all’ingresso. Il secondo è più comodo per chi è atteso, meno per chi non lo è — e molto più sicuro per la redazione dentro.

Una casella aperta a tutti non è un canale. È una vulnerabilità.

Una allowlist, un’autenticazione del dominio, un token per i flussi delicati: tre meccanismi che fanno una cosa semplice — trasformano la casella di redazione da punto di ingresso a punto di accesso. Il canale resta comodo, per chi è legittimo. Smette di essere comodo, per chi non lo è.