Krótkie wyjaśnienie MTA-STS i TLS-RPT
MTA-STS i TLS-RPT to dwa ustawienia dla Państwa domeny, które dotyczą szyfrowania poczty przychodzącej. Można się z nimi spotkać w testach takich jak internet.nl lub w raporcie ze skanu bezpieczeństwa. W tym artykule dowiedzą się Państwo, co robią te ustawienia, jak wyglądają i czy są potrzebne. Krótka odpowiedź z góry: dla większości klientów nie jest to konieczne.
Jaki problem rozwiązuje?
Kiedy serwer pocztowy dostarcza pocztę do serwera pocztowego odbiorcy, połączenie jest szyfrowane, jeśli to możliwe (STARTTLS). Jeśli się to nie uda, poczta zazwyczaj zostaje wysłana bez szyfrowania. Certyfikat serwera odbierającego również często nie jest ściśle sprawdzany. Ktoś, kto może modyfikować ruch po drodze, może w ten sposób wyłączyć szyfrowanie lub przekierować pocztę na własny serwer.
Dzięki MTA-STS jako odbiorca informują Państwo: poczta do mojej domeny musi być zawsze szyfrowana i może trafiać wyłącznie do tych serwerów pocztowych, które posiadają ważny certyfikat. Nadawca obsługujący MTA-STS przestrzega tej zasady.
Dwa elementy MTA-STS
1. Rekord TXT na nazwie _mta-sts, który informuje, że istnieje zasada (policy):
_mta-sts.jouwdomein.nl. TXT "v=STSv1; id=20261108T120000;"
id to numer wersji, który wybierają Państwo samodzielnie. Jeśli zmienią Państwo zasadę, należy również zmienić id, aby nadawcy pobrali nową zasadę.
2. Plik zasad (policy) pod dokładnie tym adresem, przez https z ważnym certyfikatem:
https://mta-sts.jouwdomein.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Linia | Znaczenie |
|---|---|
mode: testing | Nadawcy dostarczają pocztę jak zwykle, ale zgłaszają problemy za pośrednictwem TLS-RPT. Od tego warto zacząć. |
mode: enforce | Nadawcy dostarczają pocztę wyłącznie przez szyfrowane połączenie z ważnym certyfikatem, do jednego z wymienionych serwerów pocztowych. Jeśli się to nie uda, poczta pozostaje w kolejce u nadawcy. |
mode: none | Nie ma (już) żadnej zasady. |
mx: | Nazwa Państwa serwera pocztowego, dokładnie taka, jak w rekordzie MX. Jeśli mają Państwo więcej rekordów MX, każdą nazwę należy umieścić w osobnej linii. W przypadku pakietu WebOké jest to zazwyczaj nazwa serwera Państwa pakietu, tak jak w przykładzie; certyfikat naszego serwera pocztowego jest wystawiony na tę nazwę. Jeśli Państwa MX wskazuje na własną nazwę domeny, certyfikat może do niej nie pasować i nie wolno wtedy używać trybu enforce. |
max_age: | Jak długo nadawca może pamiętać zasadę, w sekundach. 604800 to tydzień. |
Nadawca zapamiętuje zasadę. Dlatego MTA-STS nie chroni przy pierwszym kontakcie od danego nadawcy, ale chroni przy kolejnych.
TLS-RPT: raporty dotyczące szyfrowania
Dzięki TLS-RPT proszą Państwo nadawców o codzienny raport dotyczący nieudanego szyfrowania, na przykład z powodu wygasłego certyfikatu lub nazwy serwera pocztowego, której nie ma w Państwa zasadzie. To jeden rekord TXT na nazwie _smtp._tls:
_smtp._tls.jouwdomein.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@jouwdomein.nl"
Raporty są plikami technicznymi (JSON). Podobnie jak w przypadku raportów DMARC, warto użyć do tego osobnej skrzynki pocztowej. Zobacz Odczytywanie raportu DMARC.
Kolejność: najpierw TLS-RPT, następnie MTA-STS w trybie testing, przez kilka tygodni analiza raportów, a dopiero potem enforce.
MTA-STS czy DANE?
DANE robi to samo w inny sposób: odcisk cyfrowy (fingerprint) certyfikatu Państwa serwera pocztowego znajduje się w DNS (rekord TLSA), zabezpieczony przez DNSSEC. DANE chroni również pierwsze połączenie, ale działa tylko wtedy, gdy DNSSEC jest włączony. MTA-STS nie wymaga DNSSEC, ale wymaga strony internetowej z certyfikatem. Można ich używać obok siebie; nadawca obsługujący DANE daje wtedy pierwszeństwo DANE.
Jeśli Państwa poczta znajduje się u WebOké, mogą Państwo włączyć DANE w Moje WebOké w tym samym miejscu co DNSSEC. WebOké zajmuje się wtedy samodzielnie rekordami TLSA. Zobacz DNSSEC i DANE oraz Lista kontrolna Internet.nl: jak osiągnąć 100% dla strony internetowej i poczty e-mail.
Czy jest to Państwu potrzebne?
Dla większości klientów nie. Poczta między dużymi serwerami pocztowymi jest obecnie prawie zawsze szyfrowana, a jeśli chcą Państwo dodatkowo zabezpieczyć swoją pocztę u WebOké, DANE jest najprostszym krokiem. MTA-STS jest szczególnie przydatny, jeśli wymaga tego Państwa organizacja lub jeśli spodziewają się Państwo odbiorców, którzy używają MTA-STS, ale nie DANE. Dla poczty wychodzącej nie muszą Państwo nic ustawiać: decyduje o tym serwer, który wysyła Państwa pocztę.
Samodzielna konfiguracja w pakiecie hostingowym
Dwa rekordy TXT ustawiają Państwo w DNS Beheer w DirectAdmin lub na karcie DNS w Moje WebOké. Zobacz Zarządzanie rekordami DNS w Moje WebOké (z przykładami dla CNAME, TXT i usług zewnętrznych).
Plik zasad musi znajdować się na subdomenie mta-sts. W swoim pakiecie mogą Państwo utworzyć tę subdomenę w Subdomein Beheer; DirectAdmin automatycznie wystąpi wtedy o certyfikat SSL. Zobacz Tworzenie i usuwanie subdomen oraz Certyfikat dla www, subdomen i wildcard. W folderze subdomeny należy utworzyć folder .well-known, a w nim plik mta-sts.txt.
enforce bez przygotowania. Jeśli nazwa serwera pocztowego jest nieprawidłowa lub certyfikat serwera pocztowego nie pasuje do tej nazwy, poczta przestanie docierać od nadawców stosujących MTA-STS. Plik zasad musi być ponadto dostępny bezpośrednio: nadawcy nie podążają za przekierowaniem na inny adres. Proszę zacząć od trybu testing, przeanalizować raporty TLS-RPT, a w razie wątpliwości najpierw skontaktować się z nami.Dodatkowe informacje: RFC 8461 (MTA-STS) oraz RFC 8460 (TLS-RPT).