MTA-STS și TLS-RPT: configurare pas cu pas

Problema pe care o rezolvă MTA-STS

Când un server de mail livrează către altul, interoghează înregistrările MX ale domeniului destinatar, se conectează pe portul 25 și ridică legătura la TLS prin STARTTLS, dacă receptorul îl oferă. Dacă STARTTLS lipsește sau certificatul este invalid, majoritatea expeditorilor livrează oricum în clar. Astfel mailul continuă să circule, dar înseamnă și că un atacator care poate interveni asupra conexiunii sau asupra DNS-ului poate elimina oferta STARTTLS și citi mesajul. Fiindcă în SMTP-ul clasic nu există niciun semnal anunțat din timp că receptorul chiar suportă criptarea, expeditorul nu poate distinge o conexiune coborâtă de una normală. Ce lipsește nu este criptarea în sine, ci o declarație spusă dinainte că ea este obligatorie.

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) permite unui domeniu receptor să publice faptul că suportă TLS și care sunt gazdele MX legitime. Serverele expeditoare care îl implementează păstrează politica în cache, iar apoi refuză să livreze printr-o conexiune necriptată sau neautentificată cât timp politica este în modul enforce. TLS-RPT (RFC 8460) este standardul complementar de raportare: expeditorii vă trimit rezumate zilnice ale conexiunilor TLS reușite și eșuate. Împreună, cele două vă dau atât o declarație, cât și un canal de feedback care arată ce se întâmplă cu acea declarație în practică. Fiindcă publicarea politicii nu cere nicio infrastructură în afară de DNS și HTTPS, ea poate fi adăugată fără a modifica instalarea de mail existentă.

Înainte de a începe

MTA-STS funcționează doar dacă fiecare gazdă MX acceptă deja STARTTLS cu un certificat public de încredere și valid pentru numele din înregistrarea MX. Furnizorii de căsuțe poștale găzduite îndeplinesc această condiție pentru propriile nume MX. Dacă vă administrați singur serverul de mail, verificați întâi acest lucru; un certificat autosemnat sau emis pentru alt nume va eșua sub enforce. Verificarea trebuie făcută înainte de publicarea politicii, pentru că o problemă de certificat apărută după trecerea pe enforce se transformă direct în mail nelivrat. Faceți aceeași verificare și pentru gazdele MX de rezervă; tocmai serverul folosit cel mai rar este de obicei cel uitat.

1. Listați gazdele MX cu MX și SMTP.
2. Confirmați că numele fiecărei gazde MX este acoperit de certificatul ei. Verificator TLS citește certificatul de pe portul 443; pentru portul 25 folosiți openssl s_client, ca mai jos.
3. Decideți unde găzduiți fișierul de politică: un site static mic, un object store în spatele HTTPS sau serverul web pe care îl aveți deja.
4. Alegeți o adresă sau un endpoint HTTPS pentru rapoartele TLS, ideal o căsuță dedicată.

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_return_error </dev/null | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName

Pasul 1: publicați TLS-RPT

Începeți cu raportarea, pentru că nu costă nimic și arată problemele înainte să impuneți ceva. Înregistrarea este una de tip TXT, aflată la _smtp._tls sub domeniul dumneavoastră. Valoarea rua este un URI mailto: sau https:; mai multe destinații se despart prin virgulă. Publicarea acestei înregistrări nu schimbă nimic în fluxul de mail, ci doar le spune expeditorilor unde să trimită rapoartele. De aceea poate fi adăugată în siguranță ca prim pas, indiferent ce plan aveți cu MTA-STS.

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

Rapoartele sunt documente JSON, de obicei comprimate cu gzip și trimise o dată pe zi de furnizorii care suportă TLS-RPT. Fiecare raport listează politica găsită de expeditor, numărul de sesiuni reușite și eșecurile grupate pe tipuri. Chiar și fără MTA-STS, rapoartele arată dacă expeditorii au reușit să negocieze TLS cu gazdele dumneavoastră MX. De aceea TLS-RPT poate fi citit și de sine stătător, ca o verificare permanentă a stării infrastructurii de mail.

Pasul 2: găzduiți fișierul de politică

Politica este un fișier text scurt, servit exact la https://mta-sts.<domeniul dumneavoastră>/.well-known/mta-sts.txt. Gazda mta-sts.example.com are nevoie de o înregistrare DNS care să indice serverul dumneavoastră web și de un certificat public de încredere pentru acel nume. Expeditorii nu trebuie să urmeze redirecturi HTTP atunci când descarcă politica (RFC 8461 §3.3), așa că serviți fișierul direct, cu status 200. Conținutul trebuie să fie text simplu, iar liniile lui trebuie să reflecte exact tiparele MX ale domeniului.

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mx.example.net
max_age: 86400

Un wildcard precum *.mx.example.net acoperă mx1.mx.example.net, dar nu și mx.example.net în sine și nici a.b.mx.example.net. Listați fiecare tipar folosit de înregistrările dumneavoastră MX; un tipar lipsă face ca livrarea să eșueze sub enforce. Nu uitați nici gazdele MX de rezervă aflate sub alte domenii, pentru că ele intră în joc doar când gazda principală nu răspunde, iar tiparul lipsă se observă abia atunci.

server {
    listen 443 ssl;
    server_name mta-sts.example.com;
    ssl_certificate     /etc/ssl/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/mta-sts.example.com/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        return 200 "version: STSv1\nmode: testing\nmx: mail.example.com\nmax_age: 86400\n";
    }

    location / {
        return 404;
    }
}

Verificați fișierul din exterior: curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt trebuie să afișeze politica fără niciun redirect, iar Verificator TLS trebuie să arate un certificat valid pentru acea gazdă. Faceți verificarea din afara rețelei dumneavoastră, pentru că înregistrările DNS interne sau proxy-urile pot face rezultatul înșelător.

Pasul 3: publicați înregistrarea _mta-sts

Înregistrarea TXT anunță că există o politică și poartă un id. Expeditorii compară acest identificator cu politica din cache-ul lor și descarcă fișierul din nou atunci când identificatorul se schimbă. Identificatorul are între 1 și 32 de litere și cifre; o marcă temporală face ușoară schimbarea lui la fiecare actualizare. Valoarea în sine nu înseamnă nimic, singurul lucru care contează este să fie diferită de fiecare dată când fișierul se schimbă.

_mta-sts.example.com. IN TXT "v=STSv1; id=20260915T0900"

Verificați-o cu Interogare DNS, folosind tipul de înregistrare TXT pentru _mta-sts.example.com. Trebuie să existe exact o înregistrare care începe cu v=STSv1.

Pasul 4: citiți rapoartele, apoi impuneți

Lăsați politica în modul testing cel puțin câteva săptămâni și citiți rapoartele TLS-RPT. Cifrele pe care le doriți sunt un număr constant de sesiuni reușite de la expeditorii mari și niciun eșec în afara erorilor de rețea izolate, apărute ocazional. Eșecurile de tip certificate-host-mismatch sau sts-policy-fetch-error trebuie rezolvate înainte de a impune ceva. Merită să așteptați rapoarte de la mai mulți furnizori mari, pentru că datele de la o singură sursă arată doar o parte din tablou.

Când rapoartele sunt curate, schimbați mode în enforce, creșteți max_age (una până la câteva săptămâni este obișnuit, de exemplu 604800 pentru șapte zile) și actualizați identificatorul din DNS. De atunci încolo, expeditorii care suportă standardul refuză să livreze către domeniul dumneavoastră printr-o conexiune care nu trece validarea TLS și încearcă din nou mai târziu, în loc să coboare la text clar. Datorită acestei reîncercări, o problemă temporară duce la o întârziere, nu la pierderea mesajului.

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mx.example.net
max_age: 604800

Cum citiți un raport TLS-RPT

Un raport este un document JSON care descrie o zi de încercări de livrare dinspre o singură organizație expeditoare. Tabloul policies are câte o intrare pentru fiecare politică evaluată de expeditor, cu un rezumat al sesiunilor reușite și eșuate. Când totul funcționează, total-failure-session-count este zero și nu apare niciun tablou failure-details. Documentul poartă și numele organizației expeditoare, și intervalul acoperit, așa că știți exact datele cărei zile le priviți.

{
  "organization-name": "Sender Example Inc.",
  "date-range": { "start-datetime": "2026-09-14T00:00:00Z", "end-datetime": "2026-09-14T23:59:59Z" },
  "contact-info": "smtp-tls-reporting@sender.example.net",
  "report-id": "2026-09-14T00:00:00Z_example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: testing", "mx: mail.example.com", "max_age: 86400"],
      "policy-domain": "example.com"
    },
    "summary": { "total-successful-session-count": 1480, "total-failure-session-count": 12 },
    "failure-details": [{
      "result-type": "certificate-expired",
      "receiving-mx-hostname": "mail.example.com",
      "receiving-ip": "192.0.2.10",
      "failed-session-count": 12
    }]
  }]
}

Citiți întâi policy-string: arată exact ce politică a folosit expeditorul și scoate la iveală expeditorii care încă țin în cache o versiune veche. Apoi uitați-vă pe rând la fiecare intrare de eșec. Câmpurile receiving-mx-hostname și receiving-ip vă spun care dintre serverele dumneavoastră a eșuat, iar result-type vă spune motivul.

Un policy-type cu valoarea no-policy-found înseamnă că expeditorul nu a găsit nicio politică MTA-STS sau DANE pentru domeniul dumneavoastră. Este de așteptat înainte de a publica MTA-STS, iar după aceea devine semnul unei probleme de DNS sau de găzduire. Numerele mici și ocazionale de eșecuri de la un singur expeditor pot fi zgomot de rețea; eșecurile repetate de la mai mulți expeditori mari sunt probleme reale. Când aveți dubii, testați manual aceeași gazdă, pentru că tipul de eșec din raport vă spune deja direct ce verificare a căzut.

Greșeli frecvente

Cele mai multe dintre acestea apar în rapoartele TLS-RPT în decurs de o zi, și tocmai de aceea există etapa de testare. Păstrați fluxul de rapoarte și după ce treceți la impunere, pentru că expirarea certificatelor și schimbările de MX sunt riscuri permanente, nu probleme de configurare de o singură dată. Direcționarea rapoartelor către o căsuță sau către un panou la care cineva chiar se uită reduce durabil acest risc.

Cum îl operați în siguranță

Schimbarea gazdelor MX

Înainte de a adăuga o gazdă MX nouă sau de a trece la un alt furnizor, adăugați tiparul ei în politică, schimbați identificatorul și așteptați cel puțin vechiul max_age, astfel încât fiecare expeditor să fi descărcat noua politică. Abia apoi schimbați înregistrările MX. Dacă faceți lucrurile în ordinea inversă, expeditorii care au politica în cache vor refuza livrarea către gazda nouă.

Certificate

Sub enforce, un certificat expirat pe o gazdă MX oprește complet livrarea dinspre expeditorii care suportă standardul. Automatizați reînnoirea pentru gazdele MX și pentru mta-sts.example.com și monitorizați datele de expirare. TLS-RPT raportează eșecurile certificate-expired, dar în acel moment mailul este deja întârziat.

Dezactivarea MTA-STS

Nu ștergeți pur și simplu înregistrările: expeditorii continuă să aplice politica din cache până când aceasta expiră. Publicați fișierul cu mode: none, schimbați identificatorul, așteptați să treacă vechiul max_age și abia apoi eliminați înregistrarea TXT și fișierul.

version: STSv1
mode: none
max_age: 86400

MTA-STS și DANE

DANE pentru SMTP (RFC 7672) rezolvă aceeași problemă de downgrade cu înregistrări TLSA care fixează în DNS certificatul sau cheia gazdei MX. Se bazează pe DNSSEC pentru ca acele înregistrări să fie de încredere, în timp ce MTA-STS se bazează pe HTTPS și pe sistemul public de autorități de certificare. Unii expeditori suportă una, alții pe cealaltă, iar unii pe amândouă. Prin urmare cele două nu sunt opțiuni care se înlocuiesc reciproc, ci două căi care ajung la categorii diferite de expeditori.

Dacă domeniul dumneavoastră este semnat cu DNSSEC și furnizorul de mail suportă DANE, este rezonabil să le publicați pe amândouă. Dacă DNSSEC nu este o opțiune, MTA-STS vă oferă cea mai mare parte din protecție cu DNS obișnuit și găzduire web obișnuită. Ghidul DNSSEC explică ce presupune semnarea unei zone.

Cele două pot coexista fără niciun conflict. Un expeditor care suportă DANE și găsește înregistrări TLSA valide folosește DANE; un expeditor care suportă doar MTA-STS folosește politica dumneavoastră. Rapoartele TLS-RPT le acoperă pe amândouă, iar policy-type vă spune pe care dintre ele a aplicat-o un expeditor.

Întrebări frecvente

Surse

• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460: Raportare TLS pentru SMTP
• RFC 7672: Securitatea SMTP prin DANE TLS oportunist
• RFC 3207: Extensie de serviciu SMTP pentru SMTP securizat prin TLS (STARTTLS)
• Google Workspace: Despre MTA-STS și raportarea TLS