Între serverele de mail, TLS este de obicei oportunist: expeditorul îl folosește dacă i se oferă, dar cineva aflat pe traseu poate elimina oferta STARTTLS și atunci mailul pleacă necriptat. MTA-STS (RFC 8461) le permite domeniilor să ceară expeditorilor TLS cu certificat valid, doar către serverele MX listate. TLS-RPT (RFC 8460) le cere expeditorilor să raporteze zilnic ce livrări TLS au eșuat. Împreună vă lasă să impuneți TLS fără să aflați de probleme abia când lipsește mailul. Politica o faceți cu generatorul MTA-STS, iar rapoartele le citiți cu analizorul de rapoarte TLS.
Din ce e făcut MTA-STS
Trei piese, toate necesare (RFC 8461, secțiunea 3):
- Fișierul de politică, servit prin HTTPS la
https://mta-sts.exemplu.ro/.well-known/mta-sts.txt. - Înregistrarea
_mta-sts, un TXT care anunță politica și îi dă un id. - Numele
mta-sts.exemplu.ro, cu adresă și certificat valid, pe serverul web care servește fișierul.
version: STSv1
mode: testing
mx: mail.exemplu.ro
mx: *.backup.exemplu.ro
max_age: 604800_mta-sts.exemplu.ro. IN TXT "v=STSv1; id=20260925120000Z"Expeditorii verifică id-ul din DNS și descarcă fișierul doar când id-ul se schimbă. Id-ul poate fi orice șir de 1–32 de litere și cifre (secțiunea 3.1); data și ora sunt o alegere comodă.
Modurile
| Mod | Ce fac expeditorii la un eșec |
|---|---|
testing | raportează eșecul (dacă aveți TLS-RPT) și livrează oricum |
enforce | nu livrează la serverele fără TLS valid sau nelistate |
none | tratează domeniul ca fără politică |
În enforce, un expeditor care nu poate livra reîncearcă mai târziu și verifică întâi dacă a apărut o politică nouă (secțiunea 5). Un certificat expirat nu pierde deci mailul pe loc, dar îl întârzie până îl reparați.
Modelele mx
Fiecare server din înregistrarea MX trebuie să se potrivească cu un rând mx: și să prezinte un certificat valid pentru numele lui (secțiunea 4). Un model cu *. acoperă exact un nivel: *.exemplu.ro se potrivește cu mail.exemplu.ro, dar nu cu exemplu.ro și nici cu a.b.exemplu.ro (secțiunea 4.1).
Greșeala obișnuită: un server MX de rezervă uitat în politică. Expeditorii îl folosesc rar, doar când primul nu răspunde, așa că problema apare exact când nu vă permiteți (secțiunea 8.4).
Găzduirea fișierului
Serverul care servește politica trebuie (secțiunile 3.2 și 3.3):
- să aibă un certificat HTTPS valid pentru
mta-sts.exemplu.ro, neexpirat, de la o autoritate în care au încredere expeditorii; - să răspundă direct cu 200: expeditorii nu urmează redirecționări;
- să servească fișierul ca
text/plain, sub 64 KB.
Un fișier pe care expeditorii nu îl pot descărca face ca domeniul să fie tratat ca fără MTA-STS, dacă nu au deja o politică validă în cache (secțiunea 3.3).
max_age
max_age spune cât timp păstrează expeditorii politica în cache, în secunde, cel mult 31557600 (un an). RFC 8461 se așteaptă la săptămâni sau mai mult (secțiunea 3.2): o politică ținută mult nu poate fi ocolită de cineva care blochează descărcarea ei. În testing, o zi vă lasă să corectați repede; în enforce, 1–2 săptămâni sunt un punct de plecare rezonabil.
TLS-RPT: rapoartele
TLS-RPT este o înregistrare TXT la _smtp._tls + domeniu, cu adresa unde vin rapoartele (RFC 8460, secțiunea 3):
_smtp._tls.exemplu.ro. IN TXT "v=TLSRPTv1; rua=mailto:tls-rapoarte@exemplu.ro"Destinația poate fi o adresă de e-mail sau un URL https://, sau amândouă, separate prin virgulă. Rapoartele vin de obicei o dată pe zi, ca JSON comprimat, și spun ce politică a aplicat expeditorul, câte sesiuni TLS au reușit și de ce au eșuat celelalte: STARTTLS lipsă, certificat expirat, nume greșit, lanț nevalid, politică imposibil de descărcat (secțiunea 4.3). Rapoartele trimise pe e-mail trebuie să fie semnate DKIM de domeniul care raportează, iar cele fără semnătură trebuie ignorate (secțiunea 3).
Trecerea la enforce, pas cu pas
- Publicați TLS-RPT și politica în modul
testing, cumax_agede o zi. - Citiți rapoartele câteva săptămâni și reparați ce apare: certificate expirate, nume greșite, servere MX care lipsesc din politică.
- Când rapoartele arată zero eșecuri, treceți la
mode: enforceși mărițimax_age.
La fiecare schimbare puneți întâi fișierul nou, apoi id-ul nou din _mta-sts (secțiunea 8.1). Invers, un expeditor care vede id-ul nou poate descărca fișierul vechi și îl păstrează în cache până la următoarea schimbare.
Renunțarea la MTA-STS
Nu ștergeți direct înregistrarea: expeditorii care au politica în cache o aplică în continuare până expiră. Secțiunea 8.3 recomandă: publicați mode: none cu un max_age mic și un id nou, așteptați să expire vechea politică din cache-uri, abia apoi ștergeți înregistrarea și fișierul.