Jak skonfigurować MTA-STS i TLS-RPT dla poczty

Jak skonfigurować MTA-STS i TLS-RPT, aby zwiększyć bezpieczeństwo poczty e-mail

MTA-STS pozwala domenie odbierającej poinformować systemy pocztowe nadawców, które serwery mogą odbierać jej wiadomości oraz że połączenia z nimi muszą korzystać z zaufanego protokołu TLS. TLS-RPT umożliwia raportowanie: uczestniczący nadawcy mogą przekazywać informacje o problemach z dostarczaniem wiadomości przez TLS i błędach dotyczących zasad. Jeśli zastanawiasz się, jak zabezpieczyć pocztę e-mail za pomocą TLS, zacznij od konfiguracji poczty przychodzącej, a nie od rekordu DNS.

Te mechanizmy nie zastępują SPF, DKIM ani DMARC. Dotyczą innego etapu dostarczania poczty: szyfrowanego połączenia między serwerami pocztowymi. Zasada zawierająca nieaktualny lub błędnie skonfigurowany host MX może zakłócić dostarczanie wiadomości, dlatego przed jej egzekwowaniem przetestuj całą konfigurację.

1. Upewnij się, że hosting poczty jest gotowy

Na początek sprawdź bieżące rekordy MX domeny. Wypisz wszystkie wskazane w nich nazwy hostów, w tym hosty używane do obsługi zapasowej lub regionalnej. Jeśli pocztą przychodzącą zarządza dostawca, poproś go o potwierdzenie, które nazwy MX należy uwzględnić w zasadach MTA-STS i czy każdy z tych hostów obsługuje TLS oraz ma ważny certyfikat.

Sprawdź konkretne nazwy hostów, a nie tylko markę dostawcy. Domena może mieć rekordy MX takie jak mx1.mail.example.com i mx2.mail.example.com, podczas gdy dostawca obsługuje też inne hosty, które nie są przypisane do Twojej domeny. Zasady powinny obejmować nazwy hostów MX, które mogą odbierać pocztę dla tej domeny.

Sprawdź certyfikat i konfigurację TLS każdego hosta z listy. Certyfikat musi być zaufany i ważny dla nazwy hosta MX, z którym łączy się system pocztowy nadawcy. Certyfikat obejmujący stronę internetową dostawcy, ale nie jego serwer pocztowy, nie będzie odpowiednim zamiennikiem.

Zapytaj też dostawcę poczty o planowane zmiany nazw hostów. Jeśli w trakcie konfiguracji ma się zmienić nazwa hosta MX, poczekaj na ostateczną listę lub uzgodnij z dostawcą aktualizację zasad. Niezapisany w zasadach host zastępczy może powodować problemy z dostarczaniem, gdy nadawca zapisze już egzekwowane zasady w pamięci podręcznej.

2. Opublikuj miejsce docelowe raportów TLS-RPT

Prawidłowa konfiguracja TLS-RPT dla domeny zaczyna się od wyboru miejsca, do którego mają trafiać raporty, jeszcze przed opublikowaniem rekordu DNS. Możesz użyć skrzynki pocztowej, która je przyjmuje, albo usługi raportowania TLS udostępniającej adres e-mail lub adres HTTPS. Upewnij się, że ktoś monitoruje to miejsce i że Twój system pocztowy może tam odbierać raporty.

Opublikuj rekord TXT pod adresem _smtp._tls.example.com, zastępując example.com swoją domeną. Wartość rekordu wskazująca adres e-mail powinna mieć format: v=TLSRPTv1; rua=mailto:tls-reports@example.com. Jeśli usługa raportowania podaje inne miejsce docelowe, użyj dokładnego URI, które udostępnia.

Jeśli to możliwe, użyj osobnej skrzynki zamiast codziennej skrzynki konkretnej osoby. Raporty TLS mogą przychodzić jako ustrukturyzowane załączniki, a dedykowana skrzynka ułatwia ustawienie zasad dostępu, przechowywanie wiadomości i przekazywanie ich do administratora odpowiedzialnego za dostarczanie poczty. Przed opublikowaniem rekordu sprawdź ustawienia miejsca na dane i filtrowania.

Zmiany DNS mogą być widoczne z opóźnieniem, ponieważ resolwery buforują rekordy przez czas określony przez ich TTL. Po opublikowaniu rekordu odpytaj autorytatywny serwer DNS oraz publiczny resolver, aby upewnić się, że oba zwracają właściwą wartość TXT. Literówka w nazwie rekordu może sprawić, że nadawcy nie będą mogli znaleźć miejsca docelowego.

3. Udostępnij plik zasad MTA-STS

Umieść plik zasad pod adresem https://mta-sts.example.com/.well-known/mta-sts.txt, zastępując example.com własną domeną. Adres musi być dostępny przez HTTPS, a jego certyfikat musi być ważny dla nazwy hosta mta-sts.example.com. Plik umieszczony na zwykłej stronie głównej witryny nie spełni tego wymagania.

Zasady zapisuje się w zwykłym pliku tekstowym. Na początek, do testów, użyj pól takich jak te:

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

Zastąp przykładowe nazwy MX rzeczywistymi hostami poczty przychodzącej dla swojej domeny. Wartość max_age określa, przez ile sekund nadawca może przechowywać zasady w pamięci podręcznej; w powyższym przykładzie jest to jeden dzień. Krótszy początkowy okres może ułatwić wprowadzanie zmian w testowanych zasadach, a dłuższy oznacza, że nadawcy będą je przechowywać przez dłuższy czas.

Przed egzekwowaniem zasad użyj trybu testing. W tym trybie nadawcy mogą zgłaszać problemy z zasadami, ale nie muszą traktować ich jako wymogu odrzucania poczty, której nie da się dostarczyć z zachowaniem wymaganych warunków TLS. Przetestuj adres URL spoza swojej sieci i sprawdź, czy plik jest dostępny bez logowania, pętli przekierowań ani błędu aplikacji internetowej.

4. Opublikuj rekord wykrywania MTA-STS

Nadawcy znajdują zasady za pomocą rekordu TXT pod adresem _mta-sts.example.com. Jego wartość zawiera wersję i identyfikator zasad, na przykład: v=STSv1; id=20261104a. Wybierz identyfikator, który można śledzić w rejestrze zmian, zamiast ponownie używać starej wartości.

Zmieniaj identyfikator za każdym razem, gdy publikujesz zaktualizowany plik zasad. Dzięki temu systemy nadawców wiedzą, że powinny sprawdzić, czy zasady zostały zmienione, zamiast polegać wyłącznie na kopii zapisanej w pamięci podręcznej. Identyfikator służy do wykrywania zmian — nie zastępuje pliku zasad ani jego hostingu przez HTTPS.

Opublikuj rekord dopiero wtedy, gdy plik zasad będzie dostępny pod wymaganym adresem URL. Następnie sprawdź rekord TXT i otwórz adres URL z zewnętrznego połączenia. Rekord DNS i plik muszą opisywać tę samą, aktualną konfigurację: nowy identyfikator prowadzący do brakującego lub nieaktualnego pliku oznacza, że wdrożenie nadal jest błędne.

5. Sprawdź wykrywanie, zasady i zgodność z rekordami MX

Sprawdź osobno każdą warstwę konfiguracji. Odpytaj rekordy TXT _smtp._tls i _mta-sts, pobierz plik zasad przez HTTPS i porównaj każdą linię mx: z bieżącymi rekordami MX. Taki trzyczęściowy test pozwala wykryć błędy, których nie ujawni samo sprawdzenie DNS.

Sprawdź, czy odpowiedź HTTPS zawiera zaufany certyfikat dla nazwy hosta MTA-STS i czy plik zawiera oczekiwane pola. Następnie upewnij się, że każdy host MX obsługuje TLS i ma certyfikat ważny dla dokładnie tej nazwy hosta. Jeśli dostawca ma kilka nazw hostów MX dla poczty przychodzącej, przetestuj każdą z nich — nie zakładaj, że wszystkie mają identyczną konfigurację certyfikatów.

Zapisz wyniki, w tym wartości DNS, identyfikator zasad, nazwy hostów MX i datę sprawdzenia. Dzięki temu kolejny administrator będzie miał punkt odniesienia, jeśli w raportach pojawią się problemy. Więcej informacji o konfiguracji poczty można znaleźć w kanale RSS bloga YourTrend, który można dodać do firmowej listy źródeł.

6. Przejrzyj raporty, zanim zaczniesz egzekwować zasady

Pozostaw zasady w trybie testowym, zbierając informacje z TLS-RPT i sprawdzając, czy poczta jest normalnie dostarczana. Raporty mogą wskazać systemy nadawców, które napotkały problem z certyfikatem, negocjacją TLS albo rozbieżnością między reklamowanymi hostami MX a zasadami. Raport to sygnał wymagający sprawdzenia, a nie automatyczne polecenie zmiany rekordu DNS.

Sprawdź okres raportowania, domenę, której dotyczą zasady, oraz szczegóły serwera odbierającego. Porównaj je z własnym wykazem hostów MX i konfiguracją dostawcy. Jeśli brakuje prawidłowego hosta, zaktualizuj plik zasad i zmień identyfikator zasad. Jeśli problem dotyczy certyfikatu, przed egzekwowaniem zasad poproś dostawcę o jego poprawienie.

Przetestuj też dostarczanie wiadomości z systemów pocztowych, od których zależy Twoja organizacja, na przykład od partnera biznesowego lub z innej kontrolowanej przez Ciebie usługi. Upewnij się, że wiadomości docierają, a logi poczty przychodzącej potwierdzają udane połączenia TLS. Sama pusta skrzynka z raportami nie dowodzi, że każdy nadawca przetestował Twoje zasady.

Ustal okres przeglądu odpowiedni do wolumenu poczty i potrzeb operacyjnych. Nie ma uniwersalnej liczby dni, która gwarantowałaby, że raporty obejmą wszystkie systemy nadawców, dlatego nie traktuj konkretnego okresu kalendarzowego jako dowodu pełnego pokrycia. Zapisz, co sprawdzono i którzy znani nadawcy skutecznie dostarczyli wiadomości w trakcie testów.

7. Egzekwuj zasady, monitoruj i utrzymuj konfigurację

Gdy lista MX, certyfikaty, zasady HTTPS i wyniki testów będą gotowe, zmień tryb zasad z testing na enforce. Opublikuj zaktualizowany plik zasad i nowy identyfikator _mta-sts. Po aktualizacji sprawdź oba elementy spoza swojej sieci, a następnie nadal monitoruj raporty TLS-RPT i logi poczty.

Przy egzekwowaniu zasad system nadawcy obsługujący MTA-STS powinien korzystać z TLS i weryfikować serwer odbierający zgodnie z tymi zasadami. Jeśli nie może tego zrobić, dostarczanie wiadomości może się opóźnić, ponieważ nadawca będzie ponawiać próby zamiast wysyłać ją przez niezabezpieczone połączenie. Uzgodnij tę zmianę z dostawcą poczty i zespołem wsparcia, aby wiedzieli, jak diagnozować opóźnienia w dostarczaniu.

Udokumentuj czynności konserwacyjne wraz z adresem URL zasad i rekordami DNS. Gdy zmieni się host MX, zaktualizuj zasady, zanim zaczniesz korzystać z nowego hosta. Po odnowieniu certyfikatu sprawdź, czy obejmuje właściwą nazwę hosta i ma zaufany łańcuch certyfikatów. Jeśli egzekwowanie zasad ujawni problem, powrót do trybu testowego może ograniczyć jego skutki, ale pamiętaj, by zmienić identyfikator zasad i upewnić się, że poprawiony plik jest prawidłowo udostępniany.

Wyznacz osobę odpowiedzialną za przegląd skrzynki lub usługi raportującej oraz śledzenie zmian DNS i certyfikatów. Jeśli publikujesz dla współpracowników informacje o działaniu usług lub aktualizacjach poczty, mogą oni śledzić również kanał RSS bloga YourTrend. Wyznaczony opiekun i udokumentowana procedura zmiany hostów MX ułatwią kolejne odnowienie certyfikatu lub migrację do innego dostawcy.