MTA-STS i TLS-RPT: wymuszanie TLS dla poczty przychodzącej

Poczta między serwerami jest zwykle szyfrowana przez STARTTLS, ale tylko oportunistycznie. Jeśli atakujący usunie z odpowiedzi Twojego serwera linię 250 STARTTLS albo przekieruje połączenie, nadawca korzystający z oportunistycznego TLS po cichu przejdzie na tekst jawny lub przyjmie dowolny certyfikat. Nikt nie zobaczy błędu. (Podstawy opisujemy w poradniku SMTP i STARTTLS.)

MTA-STS (RFC 8461) pozwala opublikować politykę, która mówi: moje serwery MX obsługują TLS z ważnym certyfikatem — nie dostarczaj do nich poczty inaczej. TLS-RPT (RFC 8460) prosi nadawców o codzienny raport o ich połączeniach TLS z Twoimi serwerami.

Oba mechanizmy chronią pocztę przychodzącą i działają tylko u nadawców, którzy je obsługują — Google i Microsoft dokumentują, że ich poczta wychodząca respektuje MTA-STS. Pozostali nadawcy dostarczają pocztę jak dotąd.

Jak działa MTA-STS

Składają się na niego trzy elementy:

1. Rekord TXT _mta-sts.example.com ogłasza, że polityka istnieje, i podaje jej wersję (id).
2. Plik polityki pod adresem https://mta-sts.example.com/.well-known/mta-sts.txt wymienia Twoje serwery MX, tryb oraz czas przechowywania polityki w pamięci podręcznej.
3. Twoje serwery MX oferują STARTTLS z certyfikatem wystawionym przez publiczne CA na ich nazwę hosta.

Nadawca obsługujący MTA-STS pobiera politykę przez HTTPS i przechowuje ją przez max_age sekund. Od tej pory serwer MX, z którym się łączy, musi pasować do jednej z linii mx, oferować STARTTLS i przedstawić ważny, niewygasły certyfikat na swoją nazwę. W trybie enforce serwer, który nie spełnia tych warunków, nie dostaje poczty — nadawca traktuje to jako błąd tymczasowy i ponawia próbę później.

Ktoś, kto potrafi sfałszować odpowiedzi DNS, nadal nie wystawi sobie ważnego certyfikatu dla mta-sts.example.com. Słabym punktem jest pierwszy kontakt: nadawcę, który nigdy nie pobrał Twojej polityki, można przekonać, że jej nie ma (RFC 8461, sekcja 10.2). Dlatego polityki przechowuje się tygodniami.

Zanim zaczniesz: sprawdź serwery MX

W trybie enforce serwer MX bez działającego TLS przestaje otrzymywać pocztę od nadawców obsługujących MTA-STS. Każdy host z Twoich rekordów MX musi:

• oferować STARTTLS na porcie 25;
• przedstawiać certyfikat obejmujący dokładnie nazwę hosta MX (jako nazwę DNS w polu subject alternative name), wystawiony przez publiczne CA i niewygasły — certyfikat samopodpisany albo wystawiony na inną nazwę nie przejdzie;
• obsługiwać TLS 1.2 lub nowszy, czego RFC 8461 wymaga od serwerów obsługujących MTA-STS.

Test SMTP i TLS łączy się z każdym serwerem MX i pokazuje wersję TLS oraz certyfikat. Nie pomijaj zapasowych serwerów MX: błędny certyfikat może tam pozostać niezauważony, dopóki nie zawiedzie serwer główny (RFC 8461, sekcja 8.4). Google Workspace i Microsoft 365 opisują MTA-STS dla swoich serwerów MX — wtedy publikujesz tylko rekord i plik polityki.

Krok 1: opublikuj rekord TLS-RPT

Zacznij od raportów, żeby mieć dane, zanim cokolwiek wymusisz. TLS-RPT działa także bez MTA-STS — raporty pokazują wtedy no-policy-found.

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

• v=TLSRPTv1 musi być na początku.
• rua= wskazuje, dokąd trafiają raporty: adres mailto: albo adres https: przyjmujący żądania POST. Można podać kilka, rozdzielonych przecinkami.
• Tylko jeden rekord TXT pod _smtp._tls może zaczynać się od v=TLSRPTv1. Jeśli są dwa, nadawcy uznają, że nie używasz TLS-RPT.

W przeciwieństwie do DMARC RFC 8460 nie przewiduje rekordu autoryzującego adresy raportów w innej domenie — rua możesz od razu skierować do zewnętrznej usługi raportowej.

Krok 2: przygotuj plik polityki

Polityka to zwykły tekst, jedna para klucz: wartość w linii:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

Pole	Wartości	Uwagi
version	STSv1	Wymagane. Umieść je w pierwszej linii — wymaga tego instrukcja Google.
mode	testing, enforce, none	Wymagane.
mx	nazwa hosta albo wzorzec *.	Jedna linia na wzorzec; wymagane, chyba że tryb to none.
max_age	sekundy, maksymalnie 31557600 (około roku)	Wymagane. Jak długo nadawcy przechowują politykę.

Linie mx muszą obejmować wszystkie hosty z Twoich rekordów MX. Gwiazdka zastępuje dokładnie jedną etykietę: *.example.net pasuje do mx1.example.net, ale nie do example.net ani do a.mx.example.net. Dla Microsoft 365 Microsoft podaje mx: *.mail.protection.outlook.com; jeśli nazwa Twojego serwera MX kończy się na mx.microsoft (domeny z włączonym DNSSEC w Exchange Online), Microsoft każe zamiast tego wpisać do polityki właśnie tę nazwę. Dla innych dostawców przepisz nazwy hostów z rekordów MX albo z dokumentacji dostawcy. Unikaj gwiazdki obejmującej Twoją własną domenę, np. *.example.com: każdy host w tej domenie z ważnym certyfikatem byłby wtedy uznany za prawidłowy MX (RFC 8461, sekcja 10.4).

Tryby: w testing nadawcy zgłaszają błędy przez TLS-RPT, ale i tak dostarczają pocztę; w enforce nie dostarczają jej do serwerów, które nie przeszły weryfikacji; none służy do czystego wycofania polityki.

max_age: krótka wartość podczas testów sprawia, że ewentualny błąd nie zostanie na długo w pamięci podręcznej nadawców (Google akceptuje wartości od 86400, czyli jednego dnia). Docelowo RFC 8461 przewiduje tygodnie lub dłużej, bo długi czas przechowywania zawęża okno ataku przy pierwszym kontakcie.

Krok 3: umieść plik na mta-sts.example.com

Plik musi być dostępny dokładnie pod tym adresem:

https://mta-sts.example.com/.well-known/mta-sts.txt

Zasady określa RFC 8461, sekcja 3.3:

• HTTPS z ważnym certyfikatem dla mta-sts.example.com (wystarczy też certyfikat wildcard *.example.com), wystawionym przez CA zaufane w przeglądarkach i systemach operacyjnych i niewygasłym.
• Status 200. Nadawcy nie mogą podążać za przekierowaniami — przekierowanie na www, inną ścieżkę lub inny host oznacza brak polityki.
• Content-Type: text/plain — nadawcy powinni to sprawdzać.
• Mały plik i szybka odpowiedź. Nadawca może zrezygnować po około minucie albo gdy plik przekroczy 64 KB.

Wystarczy dowolny hosting plików statycznych, byle serwował certyfikat dla mta-sts.example.com. Polityka dotyczy wyłącznie tej konkretnej domeny: poczta do user@sub.example.com szuka rekordu _mta-sts.sub.example.com, nigdy domeny nadrzędnej.

Sprawdź plik z terminala. Bez opcji -L program curl nie podąża za przekierowaniami — tak samo jak serwer nadawcy:

curl -sS -D - https://mta-sts.example.com/.well-known/mta-sts.txt

W odpowiedzi powinny się pojawić status 200, typ text/plain i treść polityki.

Krok 4: opublikuj rekord _mta-sts

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261024T1200"

• v=STSv1 musi być na początku.
• id to od 1 do 32 liter i cyfr — bez myślników, kropek i dwukropków. id=2026-10-24 jest nieprawidłowe, a nieprawidłowy rekord oznacza brak polityki.
• Tylko jeden rekord może zaczynać się od v=STSv1.

Rekord publikuj dopiero wtedy, gdy plik jest już dostępny. Następnie uruchom Sprawdzanie MTA-STS: narzędzie odczytuje rekord, pobiera i waliduje plik polityki oraz porównuje linie mx z Twoimi rekordami MX. Sprawdzanie TLS-RPT weryfikuje rekord _smtp._tls i adresy raportów.

Krok 5: czytaj raporty, potem włącz enforce

Nadawcy obsługujący TLS-RPT przysyłają raporty w formacie JSON obejmujące pełną dobę UTC, zwykle skompresowane gzipem, e-mailem lub przez HTTPS. Każdy raport podaje politykę zastosowaną przez nadawcę (sts, tlsa dla DANE albo no-policy-found), liczbę udanych i nieudanych sesji, a dla błędów — result-type z adresem IP nadawcy, hostem MX i liczbą sesji.

Typ wyniku	Co sprawdzić
starttls-not-supported	serwer MX nie oferuje STARTTLS
certificate-host-mismatch	certyfikat nie pasuje do nazwy MX wymaganej przez politykę
certificate-expired	odnów certyfikat na serwerze MX
certificate-not-trusted	certyfikat samopodpisany albo niepełny łańcuch
sts-policy-fetch-error	plik polityki jest niedostępny, przekierowany albo nie zwraca 200
sts-policy-invalid	błąd składni w pliku polityki
sts-webpki-invalid	problem z certyfikatem na mta-sts.example.com

Gdy raporty przez kilka tygodni nie pokazują problemów, przełącz politykę na enforce:

1. Zmień plik: ustaw mode: enforce i dłuższe max_age, np. 604800 (tydzień) lub więcej.
2. Dopiero potem zmień id w rekordzie TXT.

Kolejność ma znaczenie (RFC 8461, sekcja 8.1): nadawca, który zobaczy nowe id, gdy serwer wciąż zwraca stary plik, zapamięta starą politykę.

Późniejsze zmiany polityki

Każda zmiana pliku wymaga nowego id — inaczej nadawcy trzymają starą kopię, aż minie max_age. Nowe id zauważą przy najbliższym odświeżeniu (RFC sugeruje codzienne), a w trybie enforce również zanim ostatecznie zrezygnują z doręczenia wiadomości.

Zmiana serwerów poczty przy włączonym enforce: dopisz nowe hosty MX do polityki obok starych i zmień id; daj nadawcom kilka dni na pobranie nowej wersji; przełącz rekordy MX; na koniec usuń stare hosty i ponownie zmień id. Możesz też na czas migracji wrócić do testing — Microsoft zaleca to, gdy wymuszanie powoduje problemy z dostarczaniem.

Wygasłe certyfikaty: wygasły certyfikat na serwerze MX w trybie enforce sprawia, że nadawcy obsługujący MTA-STS wstrzymują pocztę do Ciebie. Wygasły certyfikat na hoście mta-sts jest mniej pilny — nadawcy korzystają z zapamiętanej polityki i zgłaszają sts-webpki-invalid — ale napraw go, zanim te kopie wygasną.

Wycofanie MTA-STS: opublikuj mode: none z krótkim max_age (np. jeden dzień), zmień id i odczekaj, aż wygasną wszystkie zapamiętane polityki — nawet tyle, ile wynosiło najdłuższe max_age w dotychczas publikowanych wersjach. Dopiero wtedy usuń rekord i plik. Samo usunięcie rekordu TXT nie czyści pamięci podręcznej nadawców.

Najczęstsze błędy

• Nieprawidłowe id — znaki interpunkcyjne albo więcej niż 32 znaki.
• Przekierowanie lub zły certyfikat na hoście polityki, np. przekierowanie wszystkiego na https://www.example.com albo domyślny certyfikat platformy hostingowej.
• Brak któregoś serwera MX w polityce — często zapasowego albo świeżo dodanego.
• Zmiana pliku bez zmiany id.
• Oczekiwanie, że polityka chroni pocztę wychodzącą. Twoja polityka dotyczy wyłącznie poczty wysyłanej do Ciebie.

Jeśli po przejściu na enforce poczta przestanie docierać, wróć do mode: testing, zmień id, a potem za pomocą raportów i testu SMTP i TLS znajdź serwer, który nie przechodzi weryfikacji.