MTA-STS è una policy che pubblichi sul tuo dominio per dire agli altri server di posta: quando mi consegni un messaggio devi usare una connessione cifrata e verificare il mio certificato, altrimenti non consegnare. Senza di essa la cifratura del trasporto è opportunistica e può essere fatta cadere da chi sta in mezzo. TLS-RPT è il suo complemento: chiede ai mittenti di segnalarti quando qualcosa va storto. Si attivano con un record DNS ciascuno e un file pubblicato su un sottodominio.
Quando un server consegna un messaggio al tuo, i due si accordano sul canale. Il meccanismo standard prevede che il mittente chieda di passare a una connessione cifrata e, se il destinatario risponde di sì, il resto della conversazione viaggia protetto.
Il difetto sta nella parola se. Quel passaggio è opportunistico: se la richiesta di cifratura non riceve risposta, oppure se il certificato presentato non è valido, la maggior parte dei server consegna comunque in chiaro, perché il progetto originario preferiva la consegna alla riservatezza. Chi si trova nel percorso di rete può sfruttare questo comportamento: basta rimuovere l'annuncio della capacità di cifrare perché i due server concludano che non è disponibile e proseguano in chiaro. È un attacco noto da anni e non richiede di violare alcuna crittografia, solo di stare in mezzo.
Lo stesso vale per l'identità: senza una verifica del certificato, un server che si presenta al posto del tuo viene accettato.
MTA-STS toglie il se. Dice al mittente che per il tuo dominio la connessione cifrata e verificata non è un'opzione, e che in caso contrario deve rifiutare la consegna anziché degradare.
Il meccanismo è descritto dalla RFC 8461 e si compone di tre pezzi.
_mta-sts del tuo dominio, che annuncia l'esistenza della policy e ne identifica la versione. La forma è v=STSv1; id=20260913120000. L'identificatore cambia ogni volta che modifichi la policy, ed è così che i mittenti sanno di doverla rileggere.https://mta-sts.tuodominio.it/.well-known/mta-sts.txt. Il sottodominio deve esistere e avere un certificato valido: è proprio la validità di quel certificato a garantire al mittente che la policy è autentica.Il contenuto del file è semplice:
version: STSv1
mode: enforce
mx: mail.tuodominio.it
mx: mail2.tuodominio.it
max_age: 604800
Le tre modalità disponibili:
Il campo max_age indica per quanti secondi la policy resta valida nella cache del mittente. Una settimana è un valore di partenza prudente; si allunga quando la configurazione è stabile.
MTA-STS ha una caratteristica scomoda: quando funziona, non te ne accorgi; quando fallisce, il messaggio non arriva e il mittente vede un errore che tu non vedi. TLS-RPT, descritto dalla RFC 8460, colma esattamente questo vuoto.
Si attiva con un solo record TXT sul nome _smtp._tls del tuo dominio:
v=TLSRPTv1; rua=mailto:tls-report@tuodominio.it
Da quel momento i mittenti che lo supportano ti inviano un rapporto periodico, di norma giornaliero, con le sessioni riuscite e quelle fallite, il tipo di errore e i server coinvolti. È quello che ti permette di sapere che un certificato è scaduto o che un server di posta non è più nell'elenco prima di passare in enforce, e di accorgertene subito se qualcosa si rompe dopo.
Vale per TLS-RPT la stessa osservazione che vale per i report DMARC: sono file strutturati, arrivano da mittenti diversi e letti uno a uno dicono poco. Serve qualcosa che li aggreghi e ti avvisi quando cambia qualcosa. La protezione dell'identità email con Defensio Identity Shield include la gestione di MTA-STS e TLS-RPT accanto al monitoraggio DMARC, con l'avviso quando la policy non corrisponde più ai server di posta reali.
La sequenza è breve ma l'ordine conta, perché una policy in enforce con i server sbagliati blocca la posta in arrivo.
Sono pochi e quasi sempre gli stessi. Vale la pena conoscerli prima, perché l'effetto è visibile: la posta non arriva.
Una nota sul ruolo: MTA-STS protegge la posta in arrivo verso di te. Per la posta che invii, la protezione dipende dalla policy pubblicata dal dominio destinatario. Le due cose sono indipendenti, ed è normale che il tuo dominio sia in enforce mentre molti dei tuoi corrispondenti non hanno alcuna policy.
Esistono due modi di rendere obbligatoria la cifratura del trasporto, e la scelta pratica è quasi sempre semplice.
| MTA-STS | DANE | |
|---|---|---|
| Su cosa poggia la fiducia | Sui certificati pubblici e su HTTPS | Su DNSSEC, cioè sulla firma della zona DNS |
| Prerequisito | Un sottodominio in HTTPS con certificato valido | La zona DNS firmata con DNSSEC, lato tuo e lato mittente |
| Diffusione fra i grandi operatori | Ampia | Più limitata, forte in alcuni paesi e settori |
| Difficoltà di attivazione | Bassa | Media, dipende dal provider DNS |
| Effetto di un errore | Posta rifiutata dai mittenti che applicano la policy | Posta rifiutata e, se la firma è rotta, dominio irraggiungibile |
Non sono alternative esclusive: si possono attivare entrambe, e chi ha già DNSSEC ha ragione di farlo. Per la maggior parte delle PMI italiane, MTA-STS è il punto di partenza perché non richiede di firmare la zona e perché i destinatari che lo applicano coprono la gran parte della posta reale.
La sicurezza del trasporto della posta compare, sotto varie formulazioni, in tutte le cornici che riguardano le PMI italiane.
Nell'insieme delle difese della posta, l'ordine di priorità è chiaro: prima DMARC fino al reject, perché protegge la tua identità presso gli altri; poi la sorveglianza dei domini lookalike; poi MTA-STS e TLS-RPT, che proteggono la riservatezza del trasporto. Sono tre problemi distinti e nessuno dei tre risolve gli altri due.
È una regola che pubblichi per il tuo dominio e che dice agli altri server di posta: quando mi consegni un messaggio devi usare una connessione cifrata e verificare che il mio certificato corrisponda ai server che ho dichiarato, altrimenti non consegnare. Senza questa regola la cifratura del trasporto resta facoltativa e chi si trova nel percorso di rete può farla cadere, ottenendo che i due server proseguano in chiaro. MTA-STS elimina questa possibilità di ripiego.
MTA-STS impone il comportamento, TLS-RPT ti racconta cosa è successo. Il primo dice ai mittenti come devono consegnare; il secondo chiede loro di inviarti un rapporto periodico con le sessioni riuscite e fallite, il tipo di errore e i server coinvolti. Senza TLS-RPT una policy in enforce fallisce in silenzio dal tuo punto di vista: il messaggio non arriva e l'errore lo vede solo il mittente. Si attivano insieme, e TLS-RPT va acceso per primo.
Servono tre cose. Un record TXT nel DNS sul nome _mta-sts del dominio, nella forma v=STSv1 seguita da un identificatore di versione. Un sottodominio mta-sts raggiungibile in HTTPS con certificato valido, che serve un file di testo al percorso .well-known/mta-sts.txt. E il contenuto del file, con la versione, la modalità, l'elenco completo dei nomi dei server di posta e la durata di validità. Si parte sempre in modalità testing, si osservano i report e solo dopo si passa a enforce.
In modalità enforce sì, se la configurazione è sbagliata: un server di posta non elencato nella policy, un certificato scaduto o emesso per un nome diverso da quello del record MX fanno rifiutare la consegna ai mittenti che applicano la regola. È esattamente il motivo per cui esiste la modalità testing, in cui il mittente verifica e segnala ma consegna comunque. Attenzione anche alla durata della cache: se pubblichi una policy errata con validità lunga, i mittenti la ricordano per tutto quel periodo.
No. La tua policy riguarda la posta che gli altri consegnano a te. Per i messaggi che invii, la protezione dipende dalla policy pubblicata dal dominio del destinatario e dal fatto che il tuo server di posta la legga e la applichi. Vale la pena verificare che il tuo sistema di invio supporti MTA-STS lato mittente: molti servizi gestiti lo fanno, alcuni server installati in casa no, e in quel caso la protezione vale in una direzione sola.
Sì, il meccanismo lo richiede: il file della policy va servito in HTTPS dal sottodominio mta-sts del tuo dominio, al percorso .well-known/mta-sts.txt. Il certificato di quel sottodominio è ciò che garantisce al mittente l'autenticità della policy, quindi deve essere valido e rinnovato. Va trattato come un servizio in esercizio e non come una pagina messa lì una volta: se smette di rispondere o il certificato scade, il meccanismo si interrompe.
Dipende dai prerequisiti. DANE poggia su DNSSEC e richiede che la zona DNS sia firmata, sia dalla tua parte sia da quella del mittente; dove c'è già, è una scelta solida. MTA-STS poggia sui certificati pubblici e su HTTPS, non richiede DNSSEC ed è supportato dalla gran parte dei grandi operatori di posta. Per la maggior parte delle PMI italiane MTA-STS è il punto di partenza, e i due meccanismi possono convivere senza conflitti.
Tipicamente due o tre settimane, quasi tutte di osservazione. La configurazione tecnica richiede poche ore: il record TXT, il sottodominio in HTTPS e il file della policy. Poi serve lasciare la modalità testing attiva abbastanza a lungo da raccogliere report da mittenti diversi e scoprire eventuali server dimenticati nell'elenco o certificati non validi. Quando i report sono puliti si cambia la modalità e si aggiorna l'identificatore di versione nel record TXT.
Policy, record e report gestiti insieme al monitoraggio DMARC, con l'avviso quando la configurazione non corrisponde più ai tuoi server di posta reali. Guarda la protezione dell'identità email.