MTA-STS: come obbligare gli altri server a cifrare la posta che ti inviano - init.d - sistemistica Linux, DevOps e sviluppo PrestaShop

Nell'articolo sullo STARTTLS stripping abbiamo lasciato un problema aperto: tra un server di posta e l'altro (porta 25) il TLS implicito non è praticabile, e la cifratura resta opportunistica. Il server che invia prova a cifrare "se c'è"; chi sta in mezzo può far credere che non ci sia.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) è la risposta che non richiede DNSSEC. Il proprietario di un dominio pubblica una regola che dice ai server che gli scrivono: "usa TLS, verso questi server precisi, con un certificato valido. Altrimenti non consegnare." Servono un record DNS e un file su un sito HTTPS.

Un paragone: è l'avviso sul portone di un condominio. "I pacchi si consegnano solo al portiere, dentro, con documento." Un corriere che lo ha letto non lascia mai un pacco a uno sconosciuto sul marciapiede.

Come funziona

MTA-STS ha due pezzi.

1. Un record DNS TXT che segnala l'esistenza di una policy:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20261101000000Z;"

L'id cambia a ogni modifica della policy: serve ai mittenti per capire che devono riscaricarla. Microsoft suggerisce, per esempio, di usare la data e l'ora UTC.

2. Un file di policy servito in HTTPS a un indirizzo fisso, sul sottodominio mta-sts:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail.example.com
mx: backup-mx.example.com
max_age: 1209600

mx: i server di posta autorizzati a ricevere per il dominio (è ammesso un carattere jolly solo a sinistra, come *.example.net). Un record MX che punta a un host non elencato fallisce la verifica.
mode: testing (se il controllo fallisce la posta può comunque essere consegnata, e i mittenti che supportano TLS-RPT inviano un report), enforce (se il controllo fallisce non si consegna) oppure none.
max_age: per quanti secondi la policy può restare in cache presso il mittente, fino a 31557600 (circa un anno). La RFC raccomanda valori nell'ordine di settimane o più.

In modalità enforce, la RFC vieta al mittente di consegnare a un server che non è nella lista mx, non supporta STARTTLS o presenta un certificato non valido. Il certificato deve essere non scaduto, firmato da una CA fidata e avere un nome che corrisponde all'host MX. Questi fallimenti vanno trattati come temporanei: il messaggio viene riprovato più tardi.

Un esempio reale

Il dominio gmail.com pubblica MTA-STS. Interrogando il DNS e il sito (verificato il 1 novembre 2026):

dig +short TXT _mta-sts.gmail.com
curl -sS https://mta-sts.gmail.com/.well-known/mta-sts.txt

"v=STSv1; id=20190429T010101;"

version: STSv1
mode: enforce
mx: smtp.google.com
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

Pubblica anche un record per i report: _smtp._tls.gmail.com contiene "v=TLSRPTv1;rua=mailto:sts-reports@google.com".

I report: TLS-RPT

MTA-STS da solo funziona alla cieca: se un certificato scade, i mittenti smettono di consegnare e tu non lo sai. Per questo si affianca TLS-RPT (RFC 8460), un record DNS che dice dove inviare i resoconti sugli esiti delle connessioni:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1;rua=mailto:tls-reports@example.com"

Secondo la RFC 8460 i report sono in formato JSON (se ne raccomanda la compressione con gzip) e coprono di norma un giorno intero, dalle 00:00 alle 24:00 UTC. Tra gli errori che segnalano ci sono starttls-not-supported, certificate-expired, certificate-host-mismatch, certificate-not-trusted e, per MTA-STS, sts-policy-fetch-error, sts-policy-invalid e sts-webpki-invalid. È la stessa logica dei report DMARC descritta in SPF, DKIM e DMARC: prima si osserva, poi si impone.

Come si pubblica, passo per passo

Un certificato valido per mta-sts.example.com e un sito HTTPS che lo serve.
Il file di policy, in mode: testing.
I due record DNS: _mta-sts e _smtp._tls.
Un periodo di osservazione leggendo i report. Le istruzioni di Google per Gmail consigliano di partire da testing per circa due settimane.
Passaggio a enforce: si modifica il file e si cambia l'id nel record DNS, altrimenti i mittenti continuano a usare la policy in cache fino alla scadenza di max_age.

Il file può essere servito da qualunque web server, purché risponda a quell'indirizzo con il certificato giusto. La RFC è precisa su due dettagli: vale solo una risposta HTTP 200, e i redirect 3xx non vengono seguiti. Un 301 verso un altro indirizzo equivale a non avere la policy. Il tipo di contenuto atteso è text/plain.

Cosa può andare storto

Certificato del server di posta non valido con enforce attivo. I mittenti non consegnano. Exchange Online, per esempio, restituisce al mittente un errore 5.7.5 ("Remote certificate failed MTA-STS validation") quando il certificato del server di destinazione non è valido. Con certificati sempre più brevi, fino a 47 giorni, il rinnovo automatico non è più facoltativo.
Un MX non elencato nella policy. Exchange Online restituisce 5.4.8 ("MX hosts failed MTA-STS validation") quando l'host MX non è quello atteso dalla policy.
id non aggiornato dopo una modifica: i mittenti usano la policy vecchia fino alla scadenza di max_age.
Jolly troppo larghi nelle righe mx: la RFC avverte che indeboliscono il controllo.

I limiti di MTA-STS

La RFC 8461 è esplicita: MTA-STS protegge un dominio solo se il mittente ha potuto ottenere e conservare la policy in precedenza. Chi può bloccare il DNS al primo contatto può impedire al mittente di conoscerla e causare il declassamento. La RFC osserva che DANE evita questo problema, perché DNSSEC permette di dimostrare in modo autorevole che un record non esiste.

MTA-STS inoltre protegge solo i mittenti che lo implementano, e solo la posta in arrivo al tuo dominio. Per la posta in uscita, il tuo server deve controllare le policy altrui: per Postfix esiste un componente esterno, postfix-mta-sts-resolver, un demone che fornisce a Postfix la policy TLS in base alla policy MTA-STS del dominio destinatario.

Tra i grandi fornitori, Exchange Online valida con MTA-STS tutti i messaggi inviati a destinatari protetti da MTA-STS, senza bisogno di configurazione, e Google documenta il supporto in Gmail e Google Workspace (messaggi in uscita verso server con policy in modalità enforce, e policy pubblicabile per il proprio dominio).

Come verificare

dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com
curl -sS -i https://mta-sts.example.com/.well-known/mta-sts.txt
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -brief

L'ultimo comando mostra il certificato presentato dall'MX: deve essere valido e il nome deve corrispondere a una delle righe mx della policy.

In sintesi

MTA-STS rende obbligatoria la cifratura della posta in arrivo per chi la richiede: un record DNS, un file su HTTPS, un certificato valido sui server MX. Si parte da testing, si leggono i report TLS-RPT e solo dopo si passa a enforce. Il rischio è la gestione dei certificati; il limite è la fiducia alla prima connessione.

# MTA-STS: come obbligare gli altri server a cifrare la posta che ti inviano