MTA-STS i TLS-RPT: co robią i czy są Państwu potrzebne
MTA-STS to polityka, za pomocą której informują Państwo serwery wysyłające, że poczta do Państwa domeny może być dostarczana wyłącznie przez szyfrowane i zweryfikowane połączenie TLS. TLS-RPT to towarzyszący jej kanał raportowania: nadawcy codziennie przesyłają Państwu sprawozdanie z połączeń, które nie spełniły tej polityki. Oba mechanizmy chronią pocztę, którą Państwo odbierają; w przypadku poczty wysyłanej potrzebny jest przede wszystkim serwer wysyłkowy, który respektuje te zasady po stronie odbiorcy.
Problem, który rozwiązują
Poczta między serwerami od lat jest w większości szyfrowana za pomocą STARTTLS. Ale STARTTLS jest oportunistyczny: serwer wysyłający pyta, czy odbiorca obsługuje szyfrowanie, a jeśli odpowiedź nie nadejdzie albo certyfikat się nie zgadza, po cichu przechodzi na połączenie nieszyfrowane. Ktoś, kto znajduje się między oboma serwerami, może odfiltrować to pytanie i przepuścić pocztę w czytelnej postaci. MTA-STS usuwa tę możliwość powrotu: gdy Państwa polityka jest ustawiona na „enforce”, nadawca, któremu nie uda się nawiązać szyfrowania, nie może dostarczyć poczty.
Jak działa MTA-STS
Składa się z dwóch części, które publikują Państwo samodzielnie:
- Rekord DNS pod _mta-sts.twojadomena.be z wersją i identyfikatorem. Identyfikator zmieniają Państwo przy każdej zmianie polityki; dzięki temu nadawcy wiedzą, że muszą pobrać ją ponownie.
- Plik polityki pod adresem https://mta-sts.twojadomena.be/.well-known/mta-sts.txt. Zawiera tryb (none, testing lub enforce), serwery pocztowe, które mogą odbierać pocztę dla Państwa domeny, oraz to, jak długo nadawca może pamiętać politykę.
Ta druga część wyjaśnia, dlaczego MTA-STS działa przez HTTPS, a nie tylko przez DNS: certyfikat tej strony dowodzi, że polityka naprawdę pochodzi z Państwa domeny, bez potrzeby stosowania DNSSEC. Alternatywa, DANE, robi to samo przez DNS, ale wymaga DNSSEC w Państwa domenie, czego w praktyce u wielu belgijskich rejestratorów i w pakietach hostingowych nie ma domyślnie włączonego.
Jak działa TLS-RPT
TLS-RPT to jeden rekord DNS pod _smtp._tls.twojadomena.be z adresem, na który chcą Państwo otrzymywać raporty. Nadawcy, którzy go obsługują (w tym duzi dostawcy), wysyłają wtedy raz dziennie sprawozdanie, w którym dla każdego serwera wysyłającego podają, ile połączeń się powiodło, ile nie i dlaczego: certyfikat wygasł, nazwa serwera się nie zgadza, STARTTLS nie był oferowany, nie udało się pobrać polityki.
Ten raport jest powodem, by zacząć od TLS-RPT jeszcze przed wymuszeniem MTA-STS. Mówi on, czy są nadawcy, którzy nie będą mogli dostarczać Państwu poczty, gdy ustawią Państwo tryb enforce. Można to porównać z DMARC: najpierw obserwować, potem zaostrzać. Jak czytać takie raporty, opisujemy w artykule o raportowaniu DMARC; logika jest ta sama.
Czy są Państwu potrzebne?
To zależy od tego, z której strony połączenia Państwo patrzą.
Jako odbiorca
Jeśli Państwa domena odbiera wrażliwą pocztę (akta pracownicze, dane medyczne, korespondencję prawną, instrukcje płatnicze), MTA-STS jest tanią ochroną przed przechwyceniem poczty po drodze. Dla domeny, która odbiera głównie newslettery i potwierdzenia zamówień, korzyść jest mniejsza, ale koszt niewielki: rekord DNS, mały plik statyczny w subdomenie z ważnym certyfikatem i skrzynka na raporty.
Jako nadawca
MTA-STS we własnej domenie nie zmienia niczego w poczcie, którą Państwo wysyłają. Liczy się natomiast to, że serwer, przez który Państwo wysyłają, musi sprawdzać i respektować politykę MTA-STS odbiorcy oraz sam mieć poprawny certyfikat TLS. Jeśli wysyłają Państwo przez relay SMTP, to odpowiedzialność relaya. W razie wątpliwości warto zapytać: nadawca ignorujący politykę zostanie odrzucony przez odbiorcę w trybie enforce, a Państwo zobaczą to jako odbicie.
Praktyczny plan krok po kroku
- Ustawić rekord TLS-RPT i przez kilka tygodni zbierać raporty na adres, który ktoś faktycznie czyta.
- Opublikować politykę MTA-STS w trybie testing. Nadawcy zgłaszają wtedy nieprawidłowości w raportach, ale nadal normalnie dostarczają pocztę.
- Usunąć to, co widać w raportach: zwykle serwer pocztowy, którego nie było w polityce, albo certyfikat wystawiony na inną nazwę.
- Ustawić tryb enforce i zwiększyć identyfikator w rekordzie DNS.
- Co miesiąc przeglądać raporty i przy każdej zmianie serwerów pocztowych sprawdzać, czy plik polityki jest nadal aktualny.
Kto korzysta z hostowanej platformy pocztowej, znajdzie nazwy serwerów do polityki w ustawieniach MX tej platformy. Kto sam zarządza serwerami pocztowymi, musi pilnować ich certyfikatów: wygasły certyfikat w trybie enforce oznacza, że poczta z zewnątrz przestaje docierać.
Czego nie robi
MTA-STS nie mówi nic o tym, kto może wysyłać pocztę w Państwa imieniu; do tego nadal potrzebne są SPF, DKIM i DMARC. Nie chroni też drogi od serwera odbiorcy do skrzynki czytelnika i nie szyfruje treści na samym serwerze. Zamyka jedną konkretną lukę: nieszyfrowany powrót między dwoma serwerami pocztowymi.
Najczęściej zadawane pytania
Czy MTA-STS jest obowiązkowe?
Nie. To zalecenie, które obsługują duzi dostawcy, a nie warunek dostarczania. W niektórych sektorach i przetargach coraz częściej się go jednak wymaga.
Czy mogę ustawić MTA-STS, jeśli moja poczta jest w Microsoft 365 lub Google Workspace?
Tak. Politykę publikują Państwo samodzielnie, wpisując do niej serwery MX danej platformy. Obie platformy mają na tych serwerach ważne certyfikaty.
Co, jeśli z tej domeny tylko wysyłam i niczego na nią nie odbieram?
Wtedy MTA-STS ma dla tej domeny niewielki sens. Lepiej poświęcić czas na uwierzytelnienie i dostarczalność; to na tej podstawie oceniana jest Państwa poczta wychodząca.