Sidebar

[Offcanvas] Topnav

14
Sab, Nov
166 New Articles

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Le email che finiscono nello spam, i clienti che ricevono fatture false "dal nostro indirizzo", il dominio aziendale usato per una truffa: quasi sempre dietro c'è una configurazione incompleta della posta e dei DNS. Da novembre 2025 il problema non è più solo di sicurezza: Gmail ha iniziato a rimandare indietro o rifiutare i messaggi che non rispettano i suoi requisiti, e Microsoft fa lo stesso per Outlook.com, Hotmail e Live da maggio 2025. E l'ondata di falsi allarmi bomba via email che nelle ultime settimane ha raggiunto migliaia di scuole e deviato decine di voli ha mostrato un limite che molti sottovalutano: i controlli tecnici sul mittente funzionano solo se tutti i domini del mondo sono protetti, e basta una casella dimenticata in un'università lontana per aggirarli. In questa guida, pensata per i tecnici ma leggibile anche da chi gestisce un'azienda, una scuola o un ente, mettiamo in fila le buone pratiche: quali record DNS servono, come impostarli senza bloccare la posta legittima, come proteggere server e caselle da abusi, come analizzare il mittente di un'email sospetta e perché, contro attacchi di questo tipo, serve anche la cooperazione internazionale.

Perché oggi è obbligatorio, non facoltativo

Il protocollo SMTP nasce senza alcuna verifica del mittente: chiunque può scrivere nel campo "Da" l'indirizzo che vuole. Lo spoofing è esattamente questo: inviare un messaggio che sembra arrivare dal vostro dominio senza esserlo. Per difendersi esistono da anni tre standard che lavorano insieme, SPF, DKIM e DMARC, ma per molto tempo sono stati considerati "consigliati".

Oggi non è più così:

  • Gmail: dal febbraio 2024 chi scrive a indirizzi Gmail personali deve avere almeno SPF o DKIM, connessione TLS e un record PTR valido; chi invia volumi vicini o superiori a 5.000 messaggi al giorno deve avere SPF, DKIM e DMARC allineati al dominio del mittente e la disiscrizione con un clic. Da novembre 2025 Google applica queste regole con ritardi e rifiuti veri e propri (codici come 4.7.x e 5.7.x).
  • Microsoft: dal 5 maggio 2025 i domini che inviano oltre 5.000 messaggi al giorno verso Outlook.com, Hotmail e Live devono superare SPF e DKIM e pubblicare un record DMARC; i messaggi non conformi vengono respinti con l'errore 550 5.7.515.
  • Yahoo e Apple applicano regole analoghe dal 2024.

Una piccola impresa non arriva a 5.000 email al giorno, ma può superarle facilmente con una newsletter o un gestionale che manda fatture e solleciti. E in ogni caso, sotto quella soglia, un dominio senza autenticazione finisce molto più spesso nello spam.

1. Le fondamenta: MX, PTR e nome del server

  • Record MX: devono puntare a nomi host (mai a indirizzi IP diretti) che risolvono in record A/AAAA. Controllate che non ci siano MX "dimenticati" di vecchi fornitori.
  • Reverse DNS (PTR): ogni IP da cui parte la posta deve avere un record PTR che restituisce un nome host, e quel nome deve risolvere di nuovo allo stesso IP (forward-confirmed reverse DNS). Il PTR si chiede al proprietario dell'IP, cioè al provider di connettività o all'hosting, non si imposta nel proprio DNS.
  • HELO/EHLO coerente: il server deve presentarsi con un nome pienamente qualificato che corrisponde al PTR, non con "localhost" o con il nome interno del PC.
  • Niente invii diretti dalle linee ADSL/fibra dinamiche: gli IP residenziali sono in quasi tutte le blacklist. Per stampanti, scanner, NAS e gestionali usate un relay autenticato (il vostro server o un servizio SMTP dedicato).

2. SPF: chi è autorizzato a inviare

SPF (Sender Policy Framework) è un record TXT che elenca i server autorizzati a inviare posta per il dominio. Un esempio per un'azienda che usa Microsoft 365 più un servizio di newsletter:

esempio.it.  TXT  "v=spf1 include:spf.protection.outlook.com include:spf.servizionewsletter.com -all"

Le regole da rispettare:

  • Un solo record SPF per dominio. Due record v=spf1 rendono SPF non valido: è uno degli errori più frequenti quando si aggiunge un nuovo fornitore.
  • Massimo 10 interrogazioni DNS: ogni include, a, mx, exists e redirect conta, compresi quelli annidati nei record dei fornitori. Superato il limite, il controllo dà errore permanente. Eliminate gli include di servizi non più usati ed evitate ptr, che è deprecato.
  • Chiusura: -all (rifiuta gli altri) è la scelta più netta quando l'elenco è completo; ~all (softfail) va bene durante la fase di censimento, perché sarà comunque DMARC a decidere. Mai usare +all.
  • SPF controlla l'indirizzo di ritorno (Return-Path), non il "Da" che vede l'utente. Per questo da solo non basta contro lo spoofing.

3. DKIM: la firma digitale del messaggio

DKIM aggiunge a ogni email una firma crittografica; la chiave pubblica per verificarla è pubblicata nel DNS sotto un selettore (ad esempio selector1._domainkey.esempio.it). A differenza di SPF, la firma sopravvive agli inoltri.

  • Attivate DKIM su ogni piattaforma che invia per il dominio: Microsoft 365, Google Workspace, server di posta dell'hosting, gestionale, CRM, newsletter. Ognuna ha il suo selettore.
  • Chiavi RSA da 2048 bit: quelle da 1024 bit sono ormai considerate deboli.
  • Firmate con il vostro dominio, non con quello del fornitore: è quello che serve per l'allineamento DMARC.
  • Ruotate le chiavi periodicamente e quando cambia un fornitore, e rimuovete i selettori dei servizi dismessi.

4. DMARC: la regola che tiene tutto insieme

DMARC fa due cose. Primo, richiede l'allineamento: il dominio che compare nel "Da" deve coincidere con quello verificato da SPF o da DKIM. È questo che blocca davvero lo spoofing del mittente visibile. Secondo, dice ai server che ricevono cosa fare dei messaggi che falliscono e dove mandare i rapporti.

_dmarc.esempio.it.  TXT  "v=DMARC1; p=none; rua=mailto:Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.; fo=1"

Il percorso consigliato è graduale:

  1. p=none (solo monitoraggio) per alcune settimane, leggendo i rapporti aggregati (rua) per scoprire tutti i sistemi che inviano a nome del dominio: spesso emergono il centralino, il sito web, il gestionale o un vecchio servizio dimenticato.
  2. Sistemati SPF e DKIM per ogni fonte legittima, passate a p=quarantine, anche con pct= parziale all'inizio.
  3. Quando i rapporti sono puliti, arrivate a p=reject: solo a questo punto il dominio è davvero protetto dallo spoofing.

I rapporti DMARC sono file XML difficili da leggere a mano: conviene usare uno strumento di analisi, anche gratuito, o un servizio dedicato. Aggiungete il parametro sp= per i sottodomini e, se mandate i rapporti a una casella di un altro dominio, ricordate che quel dominio deve autorizzarlo con un apposito record.

5. Proteggere anche i domini che non inviano posta

I domini "parcheggiati" o usati solo per il sito sono i bersagli preferiti, perché nessuno li controlla. Per ognuno pubblicate:

esempio.com.         TXT  "v=spf1 -all"
_dmarc.esempio.com.  TXT  "v=DMARC1; p=reject;"
esempio.com.         MX   0 .

L'ultimo è il cosiddetto null MX, che dichiara che il dominio non riceve posta.

6. Cifratura e protezioni avanzate

  • TLS sempre attivo in ingresso e in uscita, con certificati validi: è un requisito esplicito di Gmail.
  • MTA-STS e TLS-RPT: MTA-STS obbliga i server che vi scrivono a usare TLS con certificato verificato, impedendo il declassamento a connessione in chiaro; TLS-RPT vi manda i rapporti sui problemi di cifratura. Si configurano con due record TXT e un piccolo file pubblicato su HTTPS.
  • DNSSEC e DANE, dove il provider DNS li supporta, proteggono le risposte DNS da manomissioni.
  • BIMI permette di mostrare il logo aziendale accanto ai messaggi in alcuni client, ma richiede DMARC in quarantine o reject e, per Gmail, un certificato a pagamento: è un traguardo, non un punto di partenza.

7. Il server e le caselle: evitare di diventare una fonte di spam

Gran parte dello spam che parte dai domini delle piccole imprese non arriva dallo spoofing, ma da caselle violate. Le buone pratiche lato server:

  • Mai un open relay: il server deve accettare in uscita solo utenti autenticati. Verificatelo con un test esterno.
  • Invio solo sulla porta 587 (o 465) con autenticazione; la 25 serve solo per lo scambio tra server.
  • Autenticazione a due fattori su tutte le caselle e disattivazione dei protocolli e dei metodi di accesso legacy (POP/IMAP con password semplice, SMTP AUTH dove non serve).
  • Disattivazione delle caselle inutilizzate: ex dipendenti, ex studenti, collaboratori esterni, account di servizio. Una casella dimenticata ma ancora attiva è la porta d'ingresso perfetta, come dimostra il caso degli allarmi bomba raccontato più avanti.
  • Limiti di invio per utente e avvisi automatici sui picchi: una casella che manda 2.000 email in un'ora è quasi sempre compromessa.
  • Controllo delle regole di inoltro: i criminali che violano una casella creano spesso regole che inoltrano o nascondono la posta. Bloccate l'inoltro automatico verso domini esterni, salvo eccezioni approvate.
  • Monitoraggio delle blacklist per gli IP e i domini di invio, e registrazione ai servizi per mittenti dei grandi provider (Google Postmaster Tools, Microsoft SNDS).
  • Protezione del pannello DNS e del registrar: autenticazione a due fattori, accessi nominativi, blocco del trasferimento del dominio. Chi controlla il DNS controlla la vostra posta.

8. Difendersi dalle email in arrivo

  • Applicare le policy DMARC dei mittenti e attivare le funzioni anti-spoofing e anti-impersonificazione del filtro (in Microsoft 365 e Google Workspace sono incluse ma non sempre attive al massimo livello).
  • Etichetta "Esterno" sui messaggi provenienti da fuori azienda: aiuta a riconoscere chi usa il nome di un collega con un indirizzo diverso, la tecnica più usata nelle truffe del falso fornitore o del falso direttore.
  • Attenzione ai domini simili (lookalike): esempio-srl.it al posto di esempiosrl.it. Nessun record DNS li blocca; servono filtri, formazione e, per i casi importanti, la registrazione preventiva delle varianti principali.
  • Procedura di verifica fuori canale per ogni richiesta di cambio IBAN o pagamento urgente: una telefonata al numero già noto, mai a quello indicato nell'email.

9. Gli allarmi bomba via email: quando i controlli non bastano

Cosa è successo

In poche settimane un semplice strumento come la posta elettronica è bastato a paralizzare scuole, aeroporti e redazioni in mezza Europa:

  • 19 ottobre: decine di scuole italiane ricevono un'email con oggetto "La morte è vicina"; il mittente appare riconducibile al ministero dell'Istruzione saudita.
  • 2 novembre: un messaggio raggiunge 271 istituti, con evacuazioni in Veneto, Lombardia, Liguria e Lazio; questa volta il mittente risulta riconducibile al ministero dell'Istruzione egiziano.
  • 2-6 novembre: decine di voli in diversi Paesi europei vengono deviati, scortati o ispezionati dopo email inviate agli aeroporti, Fiumicino e Malpensa compresi; un messaggio diretto agli aeroporti di Roma riportava l'indirizzo di una struttura sanitaria colombiana. Seguono minacce a redazioni giornalistiche in Irlanda e in Bulgaria.
  • 11 novembre: secondo il ministro dell'Istruzione Valditara, un nuovo messaggio arriva a circa seimila scuole. L'indirizzo appartiene al dominio cloud.dyu.edu.tw della Dayeh University di Taiwan, dove sarebbe stato violato l'account di un'ex studentessa; l'università ha riferito di traffico in uscita anomalo e ha sospeso la casella.

Nessun ordigno è stato trovato. Le caselle usate per l'invio si trovano almeno in quattro Paesi diversi (Taiwan, Colombia, Lituania, Australia), mentre i testi portano firme di fantomatici gruppi. Sul caso indaga la Procura nazionale Antimafia e Antiterrorismo, che ha ricevuto le informative dell'Agenzia per la cybersicurezza nazionale, ed Europol ha convocato una riunione con le polizie dei Paesi coinvolti. Va ricordato che la provenienza dei domini non identifica gli autori: le caselle sono state usate come "tramite" e chi le ha sfruttate può trovarsi ovunque.

Come sono stati aggirati i controlli

Questo caso mostra bene i limiti di SPF, DKIM e DMARC quando vengono usati da soli:

  • Caselle vere, non falsificate. Almeno nel caso di Taiwan non si tratta di spoofing: i messaggi sono partiti da un account reale, dai server autorizzati dell'università. SPF, DKIM e DMARC risultano quindi superati, perché certificano il server da cui parte il messaggio, non le intenzioni di chi lo scrive. Le stesse ricostruzioni giornalistiche parlano di indirizzi compromessi o di servizi di posta che garantiscono l'anonimato.
  • La reputazione del dominio. Università, ministeri e strutture sanitarie hanno domini con una buona reputazione: i filtri antispam tendono a fidarsi di loro molto più che di un indirizzo appena creato.
  • Account dimenticati. L'account di un'ex studentessa è l'esempio tipico di casella rimasta attiva dopo la fine del rapporto, probabilmente senza autenticazione a due fattori e senza nessuno che ne controlli l'uso. Credenziali di questo tipo circolano nei mercati illegali, rubate da malware o da vecchie violazioni di dati.
  • Una casella diversa a ogni ondata. Cambiando ogni volta mittente e Paese, gli autori rendono inutili le liste di blocco: quando un indirizzo viene segnalato e sospeso, il danno è già fatto e la volta successiva ne verrà usato un altro.
  • Destinatari facili da trovare. Gli indirizzi istituzionali delle scuole sono pubblici per legge: costruire un elenco di migliaia di destinatari richiede poco tempo.
  • Accesso anonimo. Chi entra in una casella violata lo fa di solito attraverso VPN, proxy o la rete Tor: l'indirizzo IP registrato dal server dell'università è quello di un servizio intermedio, non quello dell'autore.
  • Nessun elemento "tecnico" da bloccare. I messaggi contengono solo testo, spesso tradotto automaticamente: nessun allegato o link malevolo che un antivirus possa riconoscere. E nessun filtro può scartare in automatico ogni email che parla di un pericolo senza rischiare di bloccare anche le comunicazioni legittime.

Perché serve un coordinamento internazionale

Per risalire agli autori bisogna ricostruire una catena di prove sparse in giurisdizioni diverse: i registri di accesso del server di posta (a Taiwan, in Colombia o altrove), quelli del servizio di anonimizzazione usato per collegarsi, eventuali pagamenti o account collegati. Ogni anello appartiene a un'organizzazione diversa, in un Paese diverso, con leggi e tempi di conservazione dei dati diversi. Con le rogatorie tradizionali possono servire mesi, mentre i registri di accesso di molti servizi vengono cancellati dopo poche settimane.

Alcuni strumenti esistono già:

  • Europol coordina le indagini tra le polizie europee e ha già riunito i Paesi colpiti da questa ondata.
  • Il regolamento europeo e-Evidence (UE 2023/1543), applicabile dal 18 agosto 2026, permette a un'autorità giudiziaria di un Paese dell'Unione di ordinare direttamente a un fornitore che opera in un altro Stato membro di conservare o consegnare i dati, senza passare per la vecchia rogatoria.
  • La Convenzione di Budapest sulla criminalità informatica del Consiglio d'Europa, ratificata anche dall'Italia, prevede una rete di contatti attiva 24 ore su 24 per la conservazione rapida dei dati tra i Paesi aderenti.
  • La rete dei CSIRT, i gruppi nazionali di risposta agli incidenti (in Italia lo CSIRT dell'Agenzia per la cybersicurezza nazionale), può avvisare rapidamente i colleghi stranieri e i titolari dei domini abusati perché blocchino le caselle compromesse.

Ma questi strumenti hanno un limite evidente: valgono pienamente solo tra i Paesi che vi aderiscono, e le caselle usate in questa ondata si trovano in buona parte fuori dall'Unione europea, dove la cooperazione passa per accordi bilaterali e canali diplomatici, a volte complessi. Per questo la prevenzione e l'individuazione degli autori dipendono da un coordinamento internazionale che oggi è ancora parziale e che dovrebbe andare in più direzioni:

  • tempi rapidi e certi per la conservazione dei registri di accesso, in ogni Paese, prima che vengano cancellati;
  • standard minimi comuni di sicurezza per le caselle di università, ministeri e servizi pubblici: autenticazione a due fattori, disattivazione degli account inattivi, controlli sui picchi di invio. In Europa la direttiva NIS2 va in questa direzione, ma la posta è un sistema globale e la sua sicurezza dipende dall'anello più debole, ovunque si trovi;
  • condivisione immediata degli indicatori tecnici (indirizzi, server, testi, orari) tra CSIRT, forze di polizia e grandi provider di posta, così che una casella usata per minacciare le scuole di un Paese venga bloccata prima di colpire quelle di un altro;
  • collaborazione dei grandi fornitori di posta e di servizi di anonimizzazione nel rispondere rapidamente alle richieste legittime delle autorità, con le garanzie previste per la privacy.

Nessuna di queste misure, da sola, eliminerà il problema: ma senza di esse chi organizza queste campagne può continuare a spostarsi da una casella all'altra, da un Paese all'altro, sapendo che le indagini arriveranno sempre in ritardo.

Cosa fare quando arriva un'email di minaccia

Una premessa importante: la valutazione della minaccia spetta sempre alle forze dell'ordine. La verifica tecnica non serve a decidere se evacuare un edificio, ma a fornire elementi utili agli investigatori e a capire se il proprio dominio sia stato usato da qualcun altro.

  • Chiamare subito il 112 e seguire le indicazioni delle autorità.
  • Non cancellare, non rispondere, non aprire allegati o link.
  • Conservare il messaggio originale completo, intestazioni comprese: in Gmail con "Mostra originale", in Outlook salvandolo come file .eml o .msg o con "Visualizza origine". Inoltrarlo come semplice testo, o fare uno screenshot, fa perdere proprio le informazioni tecniche che servono agli inquirenti.
  • Annotare data e ora di ricezione e le caselle che l'hanno ricevuto, e mettere tutto a disposizione della Polizia Postale.

Come leggere le intestazioni

Le righe più utili si trovano nelle intestazioni del messaggio. La prima è il risultato dei controlli fatto dal vostro server:

Authentication-Results: mx.esempio.it;
  spf=fail smtp.mailfrom=ministero-esempio.gov;
  dkim=none;
  dmarc=fail (p=REJECT) header.from=ministero-esempio.gov
  • dmarc=fail su un dominio istituzionale significa che il messaggio non è partito dai server autorizzati di quel dominio: il mittente è falsificato.
  • dmarc=pass significa che il messaggio è partito davvero da un sistema autorizzato di quel dominio, come nel caso dell'università di Taiwan: è probabile una casella violata e va avvisato il titolare del dominio, di solito attraverso l'indirizzo abuse@ o i contatti indicati nei registri del dominio.
  • Nome visualizzato e indirizzo reale: il nome mostrato ("Ministero", "Polizia", "Dirigente scolastico") può essere qualsiasi cosa; conta l'indirizzo tra parentesi angolari.
  • Return-Path e Reply-To diversi dal mittente sono un segnale d'allarme.
  • Catena Received: leggendo dal basso verso l'alto si trova il primo server che ha preso in carico il messaggio, con il suo indirizzo IP. Spesso è il server legittimo di un ente violato, o un servizio di posta anonima: risalire alla persona richiede richieste formali ai provider, che solo l'autorità giudiziaria può fare.

Cosa possono fare scuole, enti e aziende

  • Portare il proprio dominio a DMARC p=reject: impedisce che qualcuno spedisca minacce credibili "a nome" della vostra scuola, del vostro Comune o della vostra azienda, e i rapporti DMARC vi mostrano i tentativi di abuso.
  • Non diventare il prossimo "tramite": autenticazione a due fattori ovunque, chiusura delle caselle di ex dipendenti, ex studenti e collaboratori, limiti e avvisi sui picchi di invio. Il caso di Taiwan dimostra che una sola casella trascurata può essere usata per colpire seimila scuole dall'altra parte del mondo.
  • Proteggere le caselle pubblicate sul sito (segreteria, protocollo, info), che sono le prime a essere bersagliate: filtri attivi al massimo livello e un referente che sappia riconoscere e gestire i messaggi anomali.
  • Scrivere una procedura interna: chi riceve il messaggio, chi chiama le autorità, chi conserva l'originale e chi avvisa il tecnico.

10. Newsletter e invii massivi

  • Usate un sottodominio dedicato (ad esempio news.esempio.it) per le campagne: se la reputazione cala, la posta ordinaria non ne risente.
  • Inserite la disiscrizione con un clic (intestazioni List-Unsubscribe e List-Unsubscribe-Post), obbligatoria per gli invii massivi verso Gmail e Yahoo.
  • Tenete le segnalazioni di spam sotto lo 0,3% (Google consiglia di restare sotto lo 0,1%): inviate solo a chi si è iscritto davvero e ripulite regolarmente gli indirizzi che non esistono più.

Checklist rapida per i tecnici

  1. Censire tutti i sistemi che inviano posta a nome del dominio.
  2. Verificare MX, PTR, EHLO e TLS.
  3. Un solo record SPF, sotto le 10 interrogazioni DNS.
  4. DKIM a 2048 bit attivo su ogni piattaforma, con il proprio dominio.
  5. DMARC in p=none con rapporti, poi quarantine, poi reject.
  6. Record di blocco sui domini che non inviano posta.
  7. MTA-STS e TLS-RPT.
  8. Autenticazione a due fattori, niente accessi legacy, niente open relay, limiti di invio.
  9. Disattivazione periodica delle caselle inutilizzate (ex dipendenti, ex studenti, collaboratori, account di servizio).
  10. Monitoraggio di blacklist, rapporti DMARC e strumenti per mittenti di Google e Microsoft.
  11. Procedura scritta per le email di minaccia: chiamare il 112, conservare l'originale con le intestazioni, consegnarlo alle autorità.
  12. Controllo periodico: ogni nuovo servizio che invia email va aggiunto a SPF e DKIM prima di andare in produzione.

Per verificare la configurazione esistono strumenti gratuiti come Internet.nl, MXToolbox (che offre anche un analizzatore di intestazioni) e Learn DMARC, che mostra passo per passo come un messaggio di prova viene valutato.

Il commento di PINET

Nel nostro lavoro di assistenza vediamo ogni settimana gli stessi problemi: due record SPF dopo il cambio di fornitore, DKIM mai attivato su Microsoft 365, nessun DMARC, il gestionale che manda le fatture da un server non autorizzato. Sono errori che non si notano finché un cliente importante non smette di ricevere le nostre email o, peggio, riceve una fattura falsa con il nostro nome. La configurazione corretta non costa quasi nulla, ma richiede metodo: prima censire, poi monitorare, solo alla fine bloccare, senza fermarsi a p=none, che protegge poco.

Gli allarmi bomba di queste settimane insegnano però qualcosa di più. SPF, DKIM e DMARC garantiscono che un messaggio arrivi davvero dal dominio che dichiara, ma non possono dire nulla su chi stia usando una casella violata. Basta un account dimenticato in un'università di Taiwan per far partire minacce perfettamente "autenticate" verso migliaia di scuole italiane. La posta elettronica è un sistema globale, e la sua sicurezza è quella dell'anello più debole: ognuno di noi deve fare la sua parte proteggendo le proprie caselle, ma individuare e fermare chi organizza queste campagne è possibile solo con una cooperazione internazionale rapida e concreta tra autorità, centri di risposta agli incidenti e fornitori di servizi. Se volete un controllo del vostro dominio e delle vostre caselle, i tecnici di PINET possono verificare la configurazione e accompagnarvi fino alla protezione completa.

Fonti: Google, linee guida per i mittenti e FAQ sull'applicazione da novembre 2025; Microsoft Defender for Office 365 Blog, Outlook's New Requirements for High-Volume Senders (aprile 2025); RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 8461 (MTA-STS), RFC 8058 (disiscrizione con un clic); Regolamento (UE) 2023/1543 (e-Evidence). Sugli allarmi bomba: Il Tempo, 12 novembre 2026; Policy Maker, 11 novembre 2026; TerniToday; IlSoftware.it; Open, 2 novembre 2026; Agenda Digitale, 6 novembre 2026; Il Sole 24 Ore; Avvenire, 7 novembre 2026; Affaritaliani, Europol convoca le polizie.

Giancarlo Finesso