Contenuto informativo basato su fonti istituzionali. L’applicazione concreta richiede una valutazione del contesto, del rischio e della normativa vigente.
Il problema del TLS opportunistico nella posta
SMTP è nato senza una protezione obbligatoria del trasporto. STARTTLS consente di cifrare la connessione, ma in uno scenario opportunistico un aggressore sul percorso può tentare di rimuovere l'offerta TLS o indurre un mittente a consegnare senza cifratura. Anche errori di certificato o configurazione possono passare inosservati.
MTA-STS, definito da RFC 8461, offre ai domini riceventi un meccanismo per pubblicare una policy recuperata tramite HTTPS. I mittenti compatibili possono verificare che il server MX corrisponda alla policy, usi TLS e presenti un certificato valido prima della consegna.
- Record DNS TXT _mta-sts
- Policy servita via HTTPS su mta-sts.dominio
- Elenco dei pattern MX autorizzati
- Modalità testing o enforce
- Durata della policy tramite max_age
TLS-RPT rende osservabili gli errori
Una policy più restrittiva deve essere monitorata. RFC 8460 definisce SMTP TLS Reporting: il dominio pubblica nel DNS dove ricevere report aggregati sui successi e sui fallimenti delle negoziazioni TLS. I dati aiutano a individuare certificati scaduti, nomi non corrispondenti, host non conformi e tentativi di downgrade.
TLS-RPT non garantisce che ogni mittente invii report e non contiene il contenuto dei messaggi. Va comunque trattato come telemetria di sicurezza: destinatario presidiato, parser affidabile, retention definita, soglie di allarme e procedura per distinguere errore operativo, incompatibilità e possibile attacco.
- Record DNS TXT _smtp._tls
- Destinazione dei report sotto controllo
- Trend di successi e fallimenti
- Classificazione del tipo di errore
- Escalation al gestore DNS, posta o certificati
Introduzione graduale e responsabilità
Prima dell'enforcement si verificano MX, certificati, catena di fiducia, rinnovo, alta disponibilità e comportamento dei sistemi di posta. La modalità testing consente ai mittenti compatibili di applicare la validazione senza bloccare la consegna sulla sola base della policy; i report guidano la correzione.
Dopo un periodo osservato, si può passare a enforce con change management e rollback. DNS, hosting HTTPS della policy, certificati e piattaforma email possono essere gestiti da fornitori diversi: proprietario, contatti e tempi di intervento devono essere documentati. MTA-STS e TLS-RPT completano, non sostituiscono, SPF, DKIM e DMARC.
- Validazione preventiva di tutti gli MX
- Testing e raccolta report
- Rinnovo certificati monitorato
- Enforcement dopo criteri di successo
- Riesame dopo modifiche a provider o routing
Domande frequenti
MTA-STS cifra il contenuto della casella?+
No. Protegge il trasporto SMTP tra server compatibili. Non sostituisce la cifratura end-to-end, la protezione della casella o i controlli sugli accessi.
TLS-RPT può bloccare un messaggio?+
No. È un meccanismo di reporting: segnala risultati e problemi TLS. L'eventuale rifiuto della consegna deriva dalla policy MTA-STS applicata dal mittente compatibile.
MTA-STS sostituisce DMARC?+
No. MTA-STS riguarda la sicurezza della connessione verso i server riceventi; DMARC riguarda l'uso autorizzato del dominio nel From tramite SPF o DKIM allineati.