Analizzare caso di atertv.it che parrebbe avere libraesva come gateway frontend (simil baracuda proofpoint) ma dietro avrebbe microsoft

[fpietrosanti]

Analizzare caso di atertv.it che parrebbe avere libraesva come gateway frontend (simil baracuda proofpoint) ma dietro avrebbe microsoft per informazioni raccolte da persona che conosce i fatti.

Investigare possibile bug importante relativo ai gateway smtp antivirus

[fpietrosanti]

[fpietrosanti]

Analisi — confermato, bug rilevante per la sovranità ⚠️

In breve: gli enti dietro un gateway antivirus Libraesva (MX *.esvacloud.com / esva.*) con mailbox reali su Microsoft 365 vengono contati come aruba / independent / italiani, non Microsoft → sottostima diretta dell'esposizione al CLOUD Act (l'ISD risulta più alto del reale).

Prova su atertv.it

• MX = forsystem.esvacloud.com → gateway Libraesva (verificato via DNS).
• SPF = … include:spf.protection.outlook.com -all → backend reale Microsoft 365.
• Classificazione attuale: aruba — reason: "MX (forsystem.esvacloud.com) on AS31034 (Aruba.it) -> aruba (ASN-based override)".

Causa radice (due fattori che si sommano)

1. Keyword gateway troppo stretta. Libraesva è registrato come libraesva.com (constants.py), ma i deployment reali usano esvacloud.com, esva.<reseller>.it, esva-cloud.…. Marcatore affidabile: il token esva (Email Security Virtual Appliance). Questi MX non vengono riconosciuti come gateway → il look-through non parte.
2. L'override ASN→italiano maschera tutto (classify.py#L301-L308). Il gateway è ospitato su Aruba → scatta l'override a aruba. L'ASN di hosting di un relay ≠ il provider delle caselle. E in step 4 l'SPF è volutamente ignorato (#L283-L286), quindi il segnale outlook non viene mai letto.

Raggio del bug (misurato su data.json)

• 169 enti con MX Libraesva (esva*).
• 93 hanno SPF Microsoft, ma solo 17 classificati microsoft. Gli altri: 27 aruba, 43 independent, 5 local-isp, 1 regional-public (+4 con backend Google).
• ⇒ ~76 enti con backend estero contati come italiani/indipendenti, tra cui comune.venezia.it, ieo.it (Istituto Europeo di Oncologia), consiglio.regione.liguria.it, lavoro.gov.it, l'Unione Bassa Romagna (Lugo, Bagnacavallo, Cotignola…), decine di comuni.
• L'ISD attuale (52,65%) è ottimistico; correggendo, la quota CLOUD Act sale e l'ISD scende di ~0,3-0,4 pt.

Fix in lavorazione

1. Allargare il keyword gateway Libraesva a esvacloud.com + esva./esva- → look-through (SPF mono-provider → MS/Google; DKIM/tenant a conferma).
2. Blindare l'override ASN: mai applicarlo quando l'MX è un gateway noto.
3. Re-run della pipeline (DNS + tenant detection) sui 169 → ri-classificazione (~76 attesi → Microsoft).
4. Generalizza al task mx_inbound_gateway (Proofpoint US, Sophos UK, Barracuda US…): registrare il gateway-frontend separato dal backend.

[fpietrosanti]

Risolto