MTA-STS e TLS-RPT spiegati brevemente
MTA-STS e TLS-RPT sono due impostazioni per il Suo dominio che riguardano la crittografia della posta in arrivo. Le incontrerà in test come internet.nl o in un rapporto di una scansione di sicurezza. In questo articolo scoprirà cosa fanno, come si presentano e se ne ha bisogno. Risposta breve in anticipo: per la maggior parte dei clienti non è necessario.
Cosa risolve?
Quando un server di posta consegna un'email al server di posta del destinatario, se possibile la connessione viene crittografata (STARTTLS). Se ciò non riesce, l'email viene solitamente inviata comunque in chiaro. Inoltre, il certificato del server ricevente spesso non viene controllato in modo rigoroso. Chi è in grado di modificare il traffico lungo il percorso può così disattivare la crittografia o indirizzare l'email verso un proprio server.
Con MTA-STS, Lei comunica, in qualità di destinatario: la posta verso il mio dominio deve sempre essere crittografata, e solo verso questi server di posta con un certificato valido. Un mittente che supporta MTA-STS rispetta questa regola.
Le due componenti di MTA-STS
1. Un record TXT sul nome _mta-sts, che indica l'esistenza di una policy:
_mta-sts.ilsuodominio.nl. TXT "v=STSv1; id=20261108T120000;"
L'id è un numero di versione che sceglie Lei stesso. Se modifica la policy, cambi anche l'id, in modo che i mittenti recuperino la nuova policy.
2. Un file di policy esattamente a questo indirizzo, tramite https con un certificato valido:
https://mta-sts.ilsuodominio.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Riga | Significato |
|---|---|
mode: testing | I mittenti consegnano come sempre, ma segnalano eventuali problemi tramite TLS-RPT. È il punto di partenza. |
mode: enforce | I mittenti consegnano solo tramite una connessione crittografata con un certificato valido, verso uno dei server di posta indicati. Se non è possibile, l'email rimane in coda presso il mittente. |
mode: none | Non c'è (più) alcuna policy. |
mx: | Il nome del Suo server di posta, esattamente come nel Suo record MX. Se ha più record MX, inserisca ogni nome su una riga separata. Per un pacchetto WebOké, si tratta solitamente del nome del server del Suo pacchetto, come nell'esempio; il certificato del nostro server di posta è intestato a quel nome. Se il Suo MX punta al Suo stesso nome di dominio, il certificato potrebbe non corrispondere e non deve utilizzare enforce. |
max_age: | Per quanto tempo un mittente può memorizzare la policy, in secondi. 604800 corrisponde a una settimana. |
Un mittente memorizza la policy. Per questo motivo MTA-STS non protegge la primissima volta che un mittente Le invia un'email, ma lo fa in seguito.
TLS-RPT: rapporti sulla crittografia
Con TLS-RPT chiede ai mittenti un rapporto giornaliero sulle crittografie non riuscite, ad esempio a causa di un certificato scaduto o di un nome di server di posta non presente nella Sua policy. Si tratta di un unico record TXT sul nome _smtp._tls:
_smtp._tls.ilsuodominio.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@ilsuodominio.nl"
I rapporti sono file tecnici (JSON). Come per i rapporti DMARC, utilizzi una casella di posta separata. Veda Leggere un rapporto DMARC.
L'ordine da seguire: prima TLS-RPT, poi MTA-STS in modalità testing, qualche settimana di lettura dei rapporti, e solo dopo enforce.
MTA-STS o DANE?
DANE fa la stessa cosa in un altro modo: l'impronta digitale del certificato del Suo server di posta è presente nel DNS (un record TLSA), protetta con DNSSEC. DANE protegge anche la prima connessione, ma funziona solo se DNSSEC è attivo. MTA-STS non richiede DNSSEC, ma richiede un sito web con un certificato. Può utilizzarli entrambi contemporaneamente; un mittente che supporta DANE darà la priorità a DANE.
Se la Sua posta è ospitata presso WebOké, può attivare DANE in Mio WebOké, nello stesso punto in cui si trova DNSSEC. WebOké si occuperà poi autonomamente dei record TLSA. Legga DNSSEC e DANE e Checklist Internet.nl: raggiungere il 100% con il Suo sito web e la Sua email.
Ne ha bisogno?
Per la maggior parte dei clienti no. Oggigiorno la posta tra grandi server di posta viene quasi sempre crittografata e, se desidera proteggere ulteriormente la Sua posta presso WebOké, DANE è il passo più semplice. MTA-STS è utile soprattutto se la Sua organizzazione lo richiede, oppure se si aspetta destinatari che utilizzano MTA-STS ma non DANE. Per la Sua posta in uscita non deve impostare nulla: a determinarlo è il server che invia la Sua posta.
Configurazione autonoma con un pacchetto di hosting
I due record TXT si impostano in Gestione DNS in DirectAdmin o nella scheda DNS in Mio WebOké. Veda Gestire i record DNS in Mio WebOké (con esempi per CNAME, TXT e servizi esterni).
Il file di policy deve trovarsi sul sottodominio mta-sts. Nel Suo pacchetto può creare tale sottodominio in Gestione Sottodomini; DirectAdmin richiederà quindi automaticamente un certificato SSL per esso. Veda Creare ed eliminare sottodomini e Certificato per www, sottodomini e wildcard. Nella cartella del sottodominio, crei una cartella .well-known contenente il file mta-sts.txt.
enforce senza le dovute precauzioni. Se il nome di un server di posta è errato, oppure se il certificato del server di posta non corrisponde a quel nome, i mittenti che seguono MTA-STS non riusciranno più a consegnare la posta. Inoltre, il file di policy deve essere apribile direttamente: i mittenti non seguono reindirizzamenti verso un altro indirizzo. Inizi con testing, legga i rapporti TLS-RPT e, in caso di dubbio, ci contatti prima di procedere.Approfondimento: RFC 8461 (MTA-STS) e RFC 8460 (TLS-RPT).