MTA-STS, TLS-RPT i BIMI: kolejne kroki po DMARC

MTA-STS: dostarczenie szyfrowane albo żadne

Serwery pocztowe szyfrują przez STARTTLS, gdy obie strony to obsługują, ale gdy oferty brak, wracają do zwykłego tekstu — a atakujący na trasie może ją usunąć. MTA-STS (RFC 8461) publikuje obietnicę: „moje hosty MX zawsze mają ważne certyfikaty; nie dostarczaj bez TLS”. Potrzeba do tego rekordu DNS i małego pliku tekstowego na serwerze WWW:

; announces the policy; change id whenever the policy file changes
_mta-sts.example.com.  3600 IN TXT   "v=STSv1; id=20261013T1200"
; the web host that serves the policy file over HTTPS
mta-sts.example.com.   3600 IN CNAME static-host.example.

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

• mode: testing raportuje błędy, ale nadal dostarcza; enforce odmawia dostarczenia bez ważnego TLS; none wycofuje politykę.
• mx: jedna linia na każdy host MX, dokładnie jak w rekordach MX. Początkowe *. dopasowuje jedną etykietę — dla dostawców z wieloma hostami.
• max_age: jak długo nadawcy trzymają politykę w cache, w sekundach. Tydzień (604800) podczas testów; kilka miesięcy, gdy wszystko jest stabilne.

1. Zdobądź ważny certyfikat dla mta-sts.example.com i udostępnij plik pod /.well-known/mta-sts.txt — wystarczy dowolny hosting statyczny.
2. Opublikuj _mta-sts z nowym id (wygodny jest znacznik czasu).
3. Dodaj rekord TLS-RPT z następnej sekcji i działaj w trybie testing przez dwa do czterech tygodni.
4. Gdy raporty są czyste, zmień mode na enforce i zaktualizuj id.

TLS-RPT: raporty o nieudanym szyfrowaniu

TLS-RPT (RFC 8460) prosi serwery wysyłające o codzienne podsumowanie ich połączeń TLS z Twoimi serwerami pocztowymi: ile się udało i dlaczego pozostałe zawiodły — wygasły certyfikat, niezgodna nazwa, brak STARTTLS, błąd pobrania polityki.

_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Google, Microsoft i inni duzi dostawcy wysyłają te raporty jako pliki JSON. Sam rekord nie zmienia niczego w dostarczaniu, więc bezpiecznie jest opublikować go jako pierwszy. Przy MTA-STS w trybie testing to z niego dowiesz się, czy enforce coś zepsuje.

BIMI: Twoje logo w skrzynce

BIMI (Brand Indicators for Message Identification) pozwala obsługującym je skrzynkom pokazywać Twoje logo zamiast inicjału przy wiadomościach, które przechodzą DMARC. Rekord wskazuje logo i zwykle certyfikat, który potwierdza, że możesz go używać:

default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/vmc.pem"

• DMARC musi być egzekwowany: p=quarantine albo p=reject w domenie, bez pct poniżej 100 i bez sp=none.
• Logo to kwadratowy SVG w ograniczonym profilu „SVG Tiny Portable/Secure”, udostępniany przez HTTPS. Zwykły eksport SVG jest zwykle odrzucany.
• Gmail pokazuje logo tylko z certyfikatem: VMC (Verified Mark Certificate), który wymaga zarejestrowanego znaku towarowego, albo CMC (Common Mark Certificate), który wymaga, by logo było używane od co najmniej roku. Yahoo może je pokazać bez certyfikatu.

W jakiej kolejności

1. SPF, DKIM i DMARC z p=none i raportami (zobacz Konfiguracja DMARC).
2. TLS-RPT — darmowy, nieszkodliwy i informacyjny od pierwszego dnia.
3. MTA-STS w trybie testing, a potem enforce, gdy raporty TLS są czyste.
4. DMARC podniesiony do p=quarantine, a potem p=reject.
5. BIMI, jeśli logo w skrzynce jest dla Ciebie warte certyfikatu.