Tra server di posta la cifratura si negozia con STARTTLS: il server che riceve annuncia di supportarla e quello che invia, se vuole, la attiva. Il problema è che questa negoziazione avviene in chiaro e che, se qualcosa va storto, la maggior parte dei server preferisce consegnare il messaggio senza cifratura piuttosto che non consegnarlo. Chi si trova in mezzo alla connessione può eliminare l'annuncio di STARTTLS e costringere i server a parlare in chiaro. MTA-STS nasce per chiudere questa debolezza, e TLS-RPT per sapere quando la cifratura fallisce.
Cosa fa MTA-STS
MTA-STS permette al proprietario di un dominio di dichiarare pubblicamente due cose:
- i suoi server di posta in arrivo supportano TLS con certificati validi;
- i mittenti non devono consegnare messaggi a quel dominio se la connessione cifrata non può essere stabilita.
I server mittenti che supportano lo standard scaricano la policy, la memorizzano per il periodo indicato e la applicano alle consegne successive. La protezione riguarda quindi la posta in arrivo verso il tuo dominio, non quella che invii.
Il punto chiave è che la policy viene recuperata tramite HTTPS, cioè da un canale autenticato con un certificato web, e non solo dal DNS, che senza DNSSEC può essere falsificato.
I tre elementi da pubblicare
Il record DNS
Un record TXT su _mta-sts annuncia che esiste una policy e ne indica la versione:
_mta-sts.example.com. TXT "v=STSv1; id=20261027T1200"
Il valore di id è un identificativo arbitrario che va cambiato ogni volta che si modifica la policy: è il segnale con cui i mittenti capiscono che devono scaricarla di nuovo.
Il file della policy
La policy è un file di testo servito via HTTPS su un sottodominio dedicato, mta-sts, al percorso /.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400
Le righe mx elencano i server di posta ammessi, ed è possibile usare un carattere jolly per un intero sottodominio. Il valore max_age indica per quanti secondi la policy resta valida nella memoria dei mittenti.
Il certificato
Il sottodominio mta-sts deve avere un certificato HTTPS valido. Anche ciascun server MX deve presentare, sulla porta 25, un certificato valido per il proprio nome. È il requisito più spesso trascurato: molti server di posta usano ancora certificati autofirmati o con un nome diverso, e con MTA-STS in modalità enforce la posta verso di loro verrebbe bloccata.
Le modalità
| Modalità | Effetto |
|---|---|
none |
la policy non viene applicata; serve per ritirarla in modo ordinato |
testing |
i mittenti consegnano comunque, ma segnalano i problemi tramite TLS-RPT |
enforce |
i mittenti non consegnano se TLS non è valido o il server non è nell'elenco |
Il percorso corretto è identico a quello di DMARC: si parte da testing, si leggono i report per qualche settimana, si correggono i problemi e solo dopo si passa a enforce, aumentando max_age a valori più lunghi, per esempio una o due settimane.
TLS-RPT: i report sui fallimenti
TLS-RPT è uno standard separato, ma va configurato insieme. Si pubblica un record TXT su _smtp._tls con l'indirizzo che riceverà i report:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-report@example.com"
I mittenti che lo supportano inviano report giornalieri in formato JSON, con il numero di sessioni riuscite e fallite e il tipo di errore: certificato scaduto, nome non corrispondente, server non presente nella policy, impossibilità di scaricare la policy.
Anche senza MTA-STS, TLS-RPT è utile: mostra se qualche mittente non riesce a stabilire connessioni cifrate con i tuoi server.
Errori comuni
- Dimenticare di aggiornare
iddopo una modifica: i mittenti continuano a usare la policy vecchia. - Aggiungere un nuovo server MX senza inserirlo nella policy: in enforce, la posta verso quel server viene rifiutata.
- Lasciare scadere il certificato del sottodominio
mta-stso dei server MX. - Passare a enforce senza aver mai letto un report.
- Usare valori di
max_agemolto lunghi già in fase di test, rendendo lento ogni ripensamento.
Chi usa un servizio di posta ospitato deve verificare che i suoi server MX abbiano certificati validi per i nomi indicati: di solito è così, ma la conferma va presa dalla documentazione del fornitore.
In sintesi
- STARTTLS da solo può essere aggirato; MTA-STS dichiara che la cifratura è obbligatoria.
- La policy si pubblica con un record TXT e un file servito via HTTPS su un sottodominio dedicato.
- I server MX devono presentare certificati validi per il proprio nome.
- Si parte da testing con TLS-RPT attivo e si passa a enforce dopo aver letto i report.
- Ogni modifica alla policy richiede un nuovo valore di
id.
