MTA-STS, DANE i TLS-RPT: co dwadzieścia domen zabezpiecza w transporcie poczty

SMTP przesyła wiadomości między serwerami pocztowymi; STARTTLS dodaje szyfrowanie do takiego połączenia. Bez obowiązkowej polityki bezpieczeństwa zestawianie połączenia często pozostaje oportunistyczne: brak oferty STARTTLS w odpowiedzi na EHLO może oznaczać dalsze doręczanie bez szyfrowania. Napastnik na trasie połączenia mógłby usunąć tę ofertę. Dopuszczalność transmisji jawnym tekstem zależy jednak od konfiguracji i pozostałych polityk serwera wysyłającego.

Rekordy MX wskazują serwery odbierające pocztę dla domeny. MTA-STS i DANE określają obowiązkowe warunki dla obsługujących te mechanizmy nadawców. TLS-RPT dostarcza raporty o udanych i nieudanych sesjach TLS. Żaden z tych mechanizmów nie zastępuje szyfrowania od końca do końca: ochrona obejmuje transport między serwerami.

Trzy mechanizmy, różne zadania

MTA-STS: Rekord TXT pod _mta-sts.example.com zapowiada politykę. Plik https://mta-sts.example.com/.well-known/mta-sts.txt zawiera dozwolone nazwy MX, tryb i okres ważności. W trybie enforce nadawca obsługujący MTA-STS nie może przekazać wiadomości serwerowi MX bez TLS, z niedozwoloną nazwą lub nieodpowiednim certyfikatem. W trybie testing samo naruszenie MTA-STS nie blokuje doręczenia; pozostałe wymagania bezpieczeństwa nadal obowiązują.

DANE: Rekordy TLSA pod nazwą serwera pocztowego wiążą punkt końcowy TLS z certyfikatem, kluczem albo kotwicą zaufania. SMTP DANE wymaga wiarygodnych danych MX i TLSA zweryfikowanych przez DNSSEC, wraz z poprawnym łańcuchem zaufania i obsługą błędów. TLSA wymaga osobnego zapytania DNS; TTL określa, jak długo zapisana w pamięci podręcznej odpowiedź DNS może być ponownie użyta. Dodatkowe ograniczenie stanowi termin ważności podpisu.

TLS-RPT: Rekord TXT pod _smtp._tls.example.com wskazuje odbiorców raportów. Nadawcy obsługujący ten standard zgłaszają zbiorczo sukcesy i błędy. Raporty uzupełniają własne logi i aktywne testy. Brak raportów nie dowodzi ani bezawaryjnego działania, ani obserwacji wszystkich nadawców.

Historyczna próbka: 20 domen, 38 kontroli hostów

Zachowane dane źródłowe z 5 września 2026 r. obejmują 20 domen i 38 zapisanych kontroli hostów. Podczas aktualizacji 25 października sumy ponownie obliczono z tego pliku. Nie wykonano nowego pomiaru dostawców. Liczba 38 kontroli nie dowodzi też sprawdzenia wszystkich opublikowanych serwerów MX i adresów IP.

W tej próbce jedenaście domen publikujących TLS-RPT pokrywało się z domenami publikującymi TXT MTA-STS. Nie jest to reguła ogólna. Flaga AD w odpowiedzi TLSA również nie dowodzi pełnej walidacji łańcucha DNSSEC domeny odbiorcy. Historyczny pomiar nie pozwala zatem potwierdzić kompletnej ochrony DANE.

Czego wyniki nie dowodzą

Identyfikator MTA-STS zawierający 2018 nie dowodzi ośmiu lat pracy testowej. Pole id to dowolny identyfikator zmiany, a nie obowiązkowy znacznik czasu. Tryb należy odczytać z pobranej polityki.

Przy dwóch domenach rekordowi TXT nie towarzyszyła czytelna polityka. Bez wcześniej zapisanej, nadal ważnej kopii nie powstaje z tego obowiązująca reguła MTA-STS. Ważna kopia w pamięci podręcznej pozostaje natomiast miarodajna. Określenie „gorzej niż brak wpisu” było zbyt ogólne. Z tak małej próbki nie wynikają również organizacyjne przyczyny wyboru MTA-STS lub DANE.

Historyczne dane zawierały politykę enforce dla wp.pl obejmującą *.wp.pl. Przy sprawdzonym hoście mx5.wp.pl narzędzie zgłosiło nieudaną walidację certyfikatu mimo zgodnej nazwy hosta. W danych brakuje pełnego łańcucha certyfikatów, więc określenie „samopodpisany” pozostaje nieudowodnione. Wynik nie opisuje też obecnej konfiguracji. Nadawca obsługujący politykę musiałby pominąć rzeczywiście niezgodny MX i w miarę możliwości spróbować innego serwera albo ponowić doręczenie później.

Dla gmx.net, web.de i t-online.de kontrola zakończyła się odrzuceniem połączenia SMTP przed testem STARTTLS. Tylko zachowana odpowiedź t-online.de wyraźnie wskazuje reputację; brak rekordu PTR nie został udowodniony dla wszystkich trzech przypadków. „Odrzucone połączenie” i „brak STARTTLS” to różne ustalenia.

Oddzielne sprawdzenie DNS, polityki i certyfikatu

Poniższe przykłady dla Linuksa zawierają nazwy zastępcze. Konkretna kontrola wymaga domeny i nazwy MX z rzeczywistej konfiguracji. Polecenia nie wysyłają wiadomości.

dig +short MX example.com
dig +short TXT _mta-sts.example.com
dig +short TXT _smtp._tls.example.com
dig +dnssec TLSA _25._tcp.mx.example.com
curl --fail --show-error --silent --max-time 15 --include \
  https://mta-sts.example.com/.well-known/mta-sts.txt
timeout 20s openssl s_client -starttls smtp \
  -connect mx.example.com:25 -servername mx.example.com \
  -verify_hostname mx.example.com -verify_return_error </dev/null

curl pobiera treść metodą GET; opcja -I żądałaby wyłącznie nagłówków. Użyteczna polityka wymaga również właściwego statusu HTTP, treści i certyfikatu HTTPS. openssl sprawdza nazwę hosta i przerywa przy błędach certyfikatu. Samo -servername ustawia jedynie SNI. To połączenie bada publiczne zaufanie do certyfikatu według lokalnego magazynu zaufania, a nie pełną walidację DANE.

dig +dnssec żąda danych DNSSEC, lecz samodzielnie nie weryfikuje całego łańcucha. Flaga AD jest miarodajna wyłącznie przy zaufanym resolverze i zabezpieczonej drodze do tego resolvera. Samo porównanie skrótu TLSA również nie wystarcza: ocena obejmuje sposób użycia certyfikatu, selektor, metodę dopasowania i stan DNSSEC.

Sprawdzanie bezpieczeństwa transportu poczty zapewnia wstępny przegląd. Implementacja sprawdzona podczas aktualizacji domyślnie bada najwyżej trzy hosty MX i pierwszy ustalony adres IP każdego hosta. Porównanie TLSA nie obejmuje w pełni wszystkich obsługiwanych kombinacji rekordów, a flaga AD pochodzi z niezabezpieczonego zapytania DNS. Wynik nie zastępuje zatem pełnej walidacji DANE ani kontroli wszystkich dróg doręczania.