TLS-RPT (raportowanie SMTP TLS, zdefiniowane w RFC 8460) to pojedynczy rekord DNS TXT, który mówi innym serwerom pocztowym, dokąd mają przesyłać Ci codzienny raport za każdym razem, gdy nie uda im się nawiązać zaszyfrowanego połączenia TLS z Twoją domeną. Publikujesz go w subdomenie _smtp._tls, kierujesz tag rua na skrzynkę lub punkt końcowy HTTPS, który kontrolujesz, i w ciągu około 24 godzin zaczynasz otrzymywać raporty JSON o udanych i nieudanych połączeniach. To warstwa raportowania, a nie egzekwowania, więc sama w sobie nigdy nie blokuje ani nie opóźnia poczty.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Sam rekord jest krótki. Oto szablon do skopiowania, który możesz od razu dostosować:
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"
Zastąp yourdomain.com swoją domeną i wstaw prawdziwy adres raportowy. Ta jedna linia stanowi cały mechanizm. Wszystko inne w tym przewodniku dotyczy tego, jak zrobić to poprawnie i jak czytać to, co wraca.
Dlaczego TLS-RPT istnieje i jaki problem rozwiązuje
SMTP zaprojektowano w czasach bez szyfrowania. Gdy później doczepiono do niego STARTTLS, pozostał on oportunistyczny: jeśli uzgadnianie TLS się nie powiedzie lub certyfikat jest nieprawidłowy, większość serwerów wysyłających po cichu wraca do przesyłania tekstem jawnym albo odracza wiadomość. Nadawca wie, że coś poszło nie tak. Ty, właściciel domeny odbierający pocztę, nie dowiadujesz się niczego.
Ta cisza jest właśnie problemem. Źle skonfigurowany certyfikat, wygasły łańcuch, atak degradujący, który usuwa baner STARTTLS, albo uszkodzona polityka MTA-STS mogą sprawić, że TLS zawiedzie dla części Twojej poczty przychodzącej, a Ty nigdy nie zobaczysz tego we własnych logach, ponieważ połączenie nigdy nie zostało ukończone. TLS-RPT zamyka tę lukę w widoczności. Prosi każdego uczestniczącego nadawcę, aby zebrał to, co zaobserwował podczas łączenia się z Tobą, i raz dziennie wysłał Ci ustrukturyzowane podsumowanie.
Ma to największe znaczenie, gdy wdrożyłeś politykę egzekwowania TLS. Jeśli włączysz MTA-STS w trybie enforce, a Twój certyfikat później wygaśnie, nadawcy, którzy honorują politykę, odmówią dostarczenia zamiast obniżyć poziom zabezpieczeń. Bez TLS-RPT dowiesz się o tym, gdy ktoś poskarży się, że Twoja poczta przestała docierać. Z TLS-RPT otrzymasz jeszcze tego samego dnia raport nazywający dokładny typ awarii.
Dokładny rekord TXT _smtp._tls, tag po tagu
Rekord znajduje się w stałej lokalizacji: nazwa hosta _smtp._tls poprzedzająca Twoją domenę. Dla example.com pełna nazwa to _smtp._tls.example.com. Jest to zwykły rekord DNS TXT, więc może go przechowywać każdy dostawca DNS, który pozwala dodawać wpisy TXT.
Musisz znać tylko dwa tagi:
v=TLSRPTv1to identyfikator wersji i musi znajdować się na pierwszym miejscu, dokładnie tak, jak zapisano. Rekord, który nie zaczyna się odv=TLSRPTv1, jest nieprawidłowy i pomijany.ruato identyfikator URI raportu zbiorczego. Mówi nadawcom, dokąd dostarczać raporty. Ten tag jest wymagany; rekord TLS-RPT bezruanie robi nic.
Kompletny rekord mailto wygląda tak:
v=TLSRPTv1; rua=mailto:tls-reports@example.com
Możesz wskazać więcej niż jeden cel, oddzielając URI przecinkiem, a raporty będą wysyłane do każdego z nich:
v=TLSRPTv1; rua=mailto:tls-reports@example.com,https://reports.example.net/v1/tlsrpt
Punkty końcowe mailto kontra https
RFC 8460 definiuje dwa transporty rua i możesz użyć jednego albo obu.
Punkt końcowy mailto: odbiera każdy raport jako wiadomość e-mail z załącznikiem JSON skompresowanym metodą gzip. To najprostsza opcja i działa z dowolną skrzynką. Kompromis polega na tym, że ruchliwa domena może otrzymywać wiele raportów dziennie od wielu dostawców, więc współdzielona skrzynka obsługiwana przez człowieka szybko się zapełnia.
Punkt końcowy https: odbiera raporty jako żądanie HTTP POST z tym samym JSON-em, co pozwala kolektorowi przetwarzać je programowo. Użyj tego, jeśli prowadzisz narzędzia, które automatycznie parsują raporty. Zwróć uwagę, że serwer raportujący musi przedstawić prawidłowy certyfikat TLS dla punktu końcowego HTTPS, co jest zamierzone: raporty o uszkodzonym szyfrowaniu same nie powinny podróżować przez uszkodzone szyfrowanie.
Większość zespołów zaczyna od mailto:, ponieważ wymaga jedynie zmiany w DNS i skrzynki pocztowej.
Użyj dedykowanej skrzynki raportowej, a nie osobistej skrzynki
Oto szczegół operacyjny, który pomija większość poradników. Nie kieruj rua na własne nazwisko ani na alias wsparcia. Raporty TLS-RPT to generowany maszynowo JSON, który przychodzi codziennie z Google, Microsoftu i od każdego innego nadawcy obsługującego ten standard. Kierowanie tego do roboczej skrzynki zasypuje prawdziwą pocztę i uczy ludzi, by to ignorować.
Utwórz dedykowaną skrzynkę, taką jak tls-reports@yourdomain.com (lub podadres w rodzaju tls-reports+prod@), której jedynym zadaniem jest zbieranie tych raportów. Kilka praktycznych uwag:
- Adres raportowy nie musi znajdować się w tej samej domenie co rekord. Możesz wysyłać raporty dla
example.comnatls-reports@collector.example.net, jeśli centralizujesz raportowanie. RFC 8460, w przeciwieństwie do DMARC, zezwala na raportowanie międzydomenowe bez rekordu autoryzacji. - Upewnij się, że sama ta skrzynka niezawodnie przyjmuje pocztę. Jeśli Twoja skrzynka TLS-RPT stoi za tym samym uszkodzonym TLS, który próbujesz zdiagnozować, możesz nigdy nie otrzymać raportu, który miał Ci o tym powiedzieć.
- Ta sama dyscyplina, którą zastosowałbyś do skrzynki na raporty zbiorcze DMARC, obowiązuje tutaj: spodziewaj się dużego wolumenu, zaplanuj jego parsowanie i trzymaj go z dala od poczty ludzkiej.
TTL, publikacja i weryfikacja
Opublikuj rekord z umiarkowanym TTL. Sensowna jest wartość między 3600 (jedna godzina) a 86400 (jeden dzień). Nie ma korzyści z agresywnie krótkiego TTL, ponieważ zmiany polityki TLS-RPT są rzadkie, a dłuższy TTL zmniejsza obciążenie DNS. Jeśli aktywnie testujesz i spodziewasz się edytować rekord, najpierw obniż TTL do 3600, potwierdź, że wszystko działa, a następnie go podnieś.
Po dodaniu rekordu potwierdź, że się rozwiązuje. Z terminala:
dig +short TXT _smtp._tls.example.com
Powinieneś zobaczyć zwrócony ciąg v=TLSRPTv1. Jeśli jest pusty, sprawdź, czy przypadkiem nie utworzyłeś rekordu w apeksie domeny albo w smtp._tls bez wiodącego podkreślenia przy _smtp. Oba podkreślenia mają znaczenie.
Raporty są generowane w rytmie dobowym, więc nie spodziewaj się niczego w ciągu kilku minut. Daj temu 24 do 48 godzin, zanim uznasz, że raportowanie nie działa. Pierwsze raporty zwykle przychodzą najpierw od dużych dostawców.
Jak TLS-RPT uzupełnia MTA-STS i DANE
TLS-RPT to raportujący towarzysz dwóch mechanizmów, które faktycznie egzekwują zaszyfrowane dostarczanie. Nie zastępuje żadnego z nich.
MTA-STS używa rekordu DNS oraz pliku polityki hostowanego przez HTTPS, aby powiedzieć nadawcom, że muszą użyć zweryfikowanego TLS, aby do Ciebie dotrzeć. DANE (rekordy TLSA) używa rekordów podpisanych DNSSEC, aby przypiąć certyfikat, którego powinni oczekiwać nadawcy. Oba mogą sprawić, że poczta zostanie odroczona lub odrzucona, gdy TLS jest niepoprawny, i o to właśnie chodzi: powstrzymują ciche obniżanie poziomu zabezpieczeń.
Wspólną luką obu jest informacja zwrotna. Egzekwowanie bez raportowania oznacza, że działasz na oślep w kwestii tego, jak często egzekwowanie faktycznie się uruchamia. TLS-RPT jest odpowiedzią. Wdróż MTA-STS lub DANE dla egzekwowania, wdróż obok nich TLS-RPT dla widoczności, a będziesz mógł dokładnie zobaczyć, którzy nadawcy trafiają w raportach na typy awarii certificate-expired, starttls-not-supported, validation-failure lub sts-policy-invalid. Wielu operatorów najpierw publikuje TLS-RPT w izolacji, prowadzi go przez kilka tygodni, aby potwierdzić, że ich przychodzący TLS jest zdrowy, i dopiero wtedy z pewnością włącza egzekwowanie MTA-STS. Jeśli rozważasz obie opcje egzekwowania, nasze porównanie MTA-STS i DANE wyjaśnia, która pasuje do Twojej konfiguracji.
Ponieważ TLS-RPT nigdy nie blokuje poczty, nie ma żadnej wady we wczesnym jego opublikowaniu. Jest to najbezpieczniejszy ze wszystkich rekordów DNS uwierzytelniania poczty do wdrożenia, ponieważ nie może spowodować awarii dostarczania.
Czytanie tego, co mówią raporty
Raport TLS-RPT to dokument JSON z podsumowaniem udanych i nieudanych sesji oraz z rozbiciem na typy awarii. Najważniejsze pola to wartości result-type w ramach każdej polityki. Do częstych należą:
starttls-not-supported: serwer wysyłający zaoferował STARTTLS, ale Twój serwer go nie ukończył, często obniżenie do tekstu jawnego lub usunięty baner.certificate-expired: Twój certyfikat przekroczył datę ważności. To najczęstsza rzeczywista awaria i powód, by obserwować raporty.certificate-host-mismatch: certyfikat nie pasował do nazwy hosta pocztowego.validation-failure: ogólny problem z walidacją TLS, taki jak niezaufany łańcuch.sts-policy-fetch-errorlubsts-policy-invalid: nadawca nie mógł pobrać lub przetworzyć Twojej polityki MTA-STS.
Stały strumień certificate-expired po odnowieniu zwykle oznacza, że węzeł pocztowy nie został przeładowany i nadal serwuje stary certyfikat. Uporczywe starttls-not-supported z jednego źródła może wskazywać na urządzenie pośredniczące usuwające STARTTLS. Wartość TLS-RPT polega na przekształceniu tych awarii z niewidocznych w nazwaną, opatrzoną datą liczbę przypadków dla każdego nadawcy.
Najczęściej zadawane pytania
Czy TLS-RPT blokuje lub opóźnia pocztę e-mail?
Nie. TLS-RPT to wyłącznie mechanizm raportowania. Nie ma mocy egzekwowania i nie może spowodować odroczenia ani odrzucenia wiadomości. Tylko MTA-STS i DANE zmieniają zachowanie przy dostarczaniu. Właśnie dlatego TLS-RPT można bezpiecznie opublikować przed wdrożeniem jakiegokolwiek egzekwowania i dlatego dodanie tego rekordu już dziś nie niesie ze sobą ryzyka.
Czy potrzebuję MTA-STS lub DANE, aby TLS-RPT działał?
Nie, są niezależne. TLS-RPT będzie zbierać raporty o Twoim przychodzącym TLS nawet bez żadnej polityki egzekwowania, a raporty te obejmują także zwykłe sesje STARTTLS. Niemniej TLS-RPT jest znacznie cenniejszy, gdy już egzekwujesz, ponieważ mówi Ci, kiedy egzekwowanie powoduje awarie. Uruchomienie najpierw samego TLS-RPT to dobry sposób na audyt kondycji Twojego TLS przed zdecydowaniem się na egzekwowanie MTA-STS.
Czy mogę wysyłać raporty TLS-RPT na adres w innej domenie?
Tak. W przeciwieństwie do DMARC, TLS-RPT nie wymaga rekordu autoryzacji, gdy cel raportowania znajduje się w innej domenie niż ta, której dotyczy rekord. Możesz scentralizować wszystkie raporty w jednej skrzynce lub jednym kolektorze HTTPS dla wielu domen. Upewnij się tylko, że ten cel niezawodnie przyjmuje pocztę lub żądania HTTP POST.
Jak szybko zobaczę raporty po opublikowaniu rekordu?
Raporty są generowane raz dziennie przez serwery wysyłające, więc spodziewaj się pierwszych w ciągu 24 do 48 godzin, a nie minut. Najwięksi dostawcy zwykle raportują jako pierwsi. Jeśli po dwóch dniach nic nie przyjdzie, ponownie sprawdź, czy rekord rozwiązuje się w _smtp._tls.yourdomain.com z oboma podkreśleniami i zaczyna się od v=TLSRPTv1.
Gdy Twój rekord już działa, uruchom bezpłatne sprawdzenie w spfwise, aby potwierdzić, że parsuje się poprawnie, i zobaczyć, jak Twoja konfiguracja TLS-RPT wypada obok rekordów SPF, DKIM, DMARC i MTA-STS w jednej ocenie.