RFC 6376

RFC 6376 to specyfikacja standardu DKIM opisująca podpisywanie i weryfikację wiadomości.

RFC 6376 jako opis mechanizmu DKIM

RFC 6376 jest dokumentem technicznym, który porządkuje sposób działania standardu DKIM, czyli DomainKeys Identified Mail. Mechanizm ten służy do dołączania do wiadomości podpisu kryptograficznego oraz do późniejszej weryfikacji, czy podpis odpowiada treści i domenie wskazanej przez nadawcę. Nie jest to szyfrowanie poczty. Zawartość wiadomości nadal może być odczytana przez uprawnione systemy pośredniczące i odbiorcę, natomiast podpis pozwala sprawdzić pochodzenie komunikatu oraz wykryć zmianę wybranych elementów po jego podpisaniu.

W praktyce DKIM działa na styku dwóch obszarów. Pierwszym jest system wysyłający pocztę, który oblicza skrót wybranych nagłówków i treści, a następnie tworzy podpis z użyciem prywatnego klucza. Drugim jest domena nadawcy, która publikuje odpowiadający mu klucz publiczny w systemie DNS. Serwer odbiorczy odczytuje dane z nagłówka DKIM-Signature, pobiera rekord TXT dla wskazanego selektora i domeny, po czym wykonuje weryfikację. Wynik nie przesądza samodzielnie o dostarczeniu wiadomości, ale może być wykorzystany przez filtry antyspamowe i reguły DMARC.

Warto rozdzielić trzy pojęcia: autoryzację techniczną, integralność oraz reputację. Podpis DKIM może być poprawny, a mimo to sama wiadomość nie musi być oczekiwana ani godna zaufania. Z kolei brak poprawnego podpisu może wynikać z błędnej konfiguracji, przekazania poczty przez system, który zmienił treść, albo z usunięcia odpowiednich nagłówków. RFC 6376 opisuje mechanizm w sposób umożliwiający interpretację tych sytuacji, lecz nie zastępuje polityk antyspamowych i analizy kontekstu.

RFC 6376, podpis DKIM i porównanie z SPF

DKIM oraz SPF często są wdrażane razem, ale sprawdzają różne właściwości wiadomości. SPF odnosi się przede wszystkim do tego, czy określony serwer może wysyłać pocztę dla domeny użytej w adresie koperty SMTP. DKIM wiąże natomiast podpis z domeną umieszczoną w polu d= nagłówka podpisu i z konkretną treścią komunikatu. SPF może stracić znaczenie po przekazaniu wiadomości przez kolejne systemy, ponieważ adres serwera widziany przez odbiorcę może się zmienić. Podpis DKIM może pozostać możliwy do zweryfikowania, o ile po drodze nie zmieniono elementów objętych podpisem.

Istotną rolę odgrywa także DMARC. Ten mechanizm pozwala określić, jak należy oceniać zgodność domeny widocznej dla odbiorcy z domeną używaną przez SPF lub DKIM, a także jak postępować z wiadomościami niespełniającymi wymaganej polityki. RFC 6376 nie definiuje całego DMARC, ale dostarcza podstaw dla oceny podpisu DKIM. W skrócie można przyjąć, że SPF odpowiada na pytanie o uprawnienie serwera do wysyłki, DKIM o integralność i powiązanie podpisu z domeną, a DMARC o zgodność tych wyników z adresem prezentowanym odbiorcy.

Podpis DKIM nie jest równoznaczny z podpisem osobistym konkretnego człowieka. Najczęściej podpisuje go system pocztowy działający w imieniu domeny. Może to być system organizacji, platforma do wysyłki biuletynów albo aplikacja generująca powiadomienia. Dlatego poprawny podpis potwierdza przede wszystkim techniczne powiązanie wiadomości z domeną podpisującą. Ocena nadawcy nadal wymaga ostrożności, sprawdzenia adresu, treści, załączników i oczekiwanego kontekstu kontaktu.

RFC 6376 a nagłówki, selektory i rekordy DNS

Najbardziej widocznym elementem DKIM jest nagłówek DKIM-Signature. Zawiera on zestaw pól opisujących sposób podpisania wiadomości. Parametr v wskazuje wersję mechanizmu, d określa domenę podpisującą, a s identyfikuje selektor używany do odnalezienia klucza publicznego w DNS. Pole h wylicza nagłówki objęte podpisem, natomiast bh zawiera skrót treści wiadomości. Pole b przechowuje właściwy podpis kryptograficzny. Występują także parametry opisujące algorytm kanonikalizacji, typ podpisanego materiału i ograniczenia czasowe.

Selektor pozwala korzystać z wielu kluczy dla jednej domeny. Dzięki temu można oddzielić podpisy używane przez różne systemy, okresy wdrożeniowe lub zastosowania. Klucz publiczny jest publikowany w rekordzie TXT pod nazwą zbudowaną z selektora i domeny podpisującej. Jeżeli podpis wskazuje selector1 oraz example.pl, system odbiorczy szuka rekordu odpowiadającego nazwie selector1._domainkey.example.pl. Przy diagnozowaniu problemów ważne jest sprawdzenie, czy nazwa jest tworzona dokładnie, czy DNS zwraca właściwy rekord oraz czy nie występują błędy wynikające z limitów długości i składni.

RFC 6376 opisuje dwa podejścia do kanonikalizacji: simple i relaxed. Pierwsze jest bardziej wrażliwe na zmiany formatowania, drugie dopuszcza określone, nieszkodliwe różnice w białych znakach. Nie oznacza to jednak, że dowolna modyfikacja wiadomości pozostanie niewykryta. Zmiana tematu, adresu nadawcy, części treści albo nagłówka objętego podpisem może spowodować niepowodzenie weryfikacji. Zakres ochrony wynika bezpośrednio z listy nagłówków oraz z parametrów podpisu.

Weryfikacja przebiega w kilku etapach. Najpierw odczytywany jest nagłówek DKIM-Signature, potem pobierany jest klucz publiczny z DNS. Następnie obliczany jest skrót treści zgodnie z deklarowanymi zasadami, a także sprawdzana jest zgodność podpisanych nagłówków. Na końcu wykonywane jest sprawdzenie kryptograficzne podpisu. Wynik może być pozytywny, negatywny albo niejednoznaczny z powodu braku klucza, błędu tymczasowego DNS lub niepełnych danych. Z tego powodu komunikat diagnostyczny powinien być analizowany razem z pełnymi nagłówkami wiadomości.

RFC 6376 i typowe problemy z pocztą elektroniczną

Jednym z częstszych problemów jest brak rekordu DKIM w DNS albo opublikowanie go pod inną nazwą niż ta wskazana w podpisie. Przyczyną może być literówka w selektorze, pomylenie domeny podpisującej z domeną używaną w adresie nadawcy lub pozostawienie starego klucza po zmianie konfiguracji. Nieprawidłowy rekord TXT może być widoczny tylko z części serwerów DNS, jeśli nie zakończyła się propagacja zmian albo występuje problem z delegacją strefy.

Inna grupa błędów pojawia się wtedy, gdy wiadomość jest modyfikowana po podpisaniu. System pośredni może zmienić temat, dodać własny nagłówek, przekształcić kodowanie treści, zmienić sposób zawijania wierszy albo wstawić stopkę. Nie każda taka zmiana musi unieważnić podpis, ponieważ zależy to od zakresu podpisanych danych i wybranej kanonikalizacji. Jeśli jednak zmodyfikowano element objęty podpisem, odbiorca może otrzymać wynik fail.

Problematyczne bywa również użycie kilku systemów wysyłających pocztę dla jednej domeny. Każdy z nich powinien mieć spójnie zaplanowany sposób podpisywania, własny selektor lub jasno zarządzany klucz. Należy unikać sytuacji, w której jeden system podpisuje wiadomości kluczem usuniętym z DNS, a inny korzysta z rekordu o tym samym selektorze. W razie podejrzenia przejęcia klucza konieczna jest jego wymiana i usunięcie starego rekordu po przygotowaniu nowej konfiguracji.

Warto pamiętać o różnicy między domeną widoczną w polu From a domeną znajdującą się w parametrze d. Obie mogą być różne, a sam poprawny podpis nie zawsze zapewni zgodność wymaganą przez politykę DMARC. Należy też odróżniać problemy DKIM od błędów transportu, odrzucenia przez filtr, nieprawidłowego certyfikatu TLS, blokady adresu IP oraz problemów z lokalnym programem pocztowym. Dokładne rozpoznanie wymaga zebrania pełnych nagłówków i ustalenia, na którym etapie powstała niezgodność.

RFC 6376 w praktyce i bezpieczna diagnostyka

Przy sprawdzaniu podpisu powinno się rozpocząć od obejrzenia oryginalnych nagłówków wiadomości, a nie od samego widoku skrzynki odbiorczej. W nagłówkach można znaleźć wynik Authentication-Results, informacje o nazwie domeny, selektorze, zastosowanym algorytmie oraz ewentualnym komunikacie błędu. Warto porównać te dane z konfiguracją DNS i ustalić, czy wiadomość przeszła przez dodatkowe systemy po podpisaniu. Pomocne jest także wysłanie kontrolnego komunikatu do kilku niezależnych skrzynek, ponieważ różne systemy odbiorcze mogą inaczej prezentować szczegóły autoryzacji.

Podczas konfiguracji należy chronić klucz prywatny, ograniczyć dostęp do systemu podpisującego oraz zaplanować okresową wymianę kluczy. Klucz publiczny powinien być publikowany z poprawnym typem rekordu i bez przypadkowych znaków. Przed zmianą selektora dobrze jest uruchomić nowy podpis równolegle, sprawdzić wyniki weryfikacji, a dopiero później wycofać poprzednią konfigurację. Pozwala to uniknąć przerw w dostarczaniu wiadomości i ułatwia powrót do wcześniejszego ustawienia, gdy pojawi się błąd.

Nie należy traktować pojedynczego wyniku jako pełnej diagnozy bezpieczeństwa. Wynik pass świadczy o poprawnej weryfikacji podpisu w danym momencie, ale nie potwierdza, że wiadomość jest oczekiwana. Wynik fail wskazuje na problem z integralnością lub kluczem, lecz nie zawsze oznacza próbę oszustwa. Wynik none może być normalny dla wiadomości pochodzącej z systemu, który nie został skonfigurowany do podpisywania, natomiast wynik temperror może wymagać ponowienia kontroli po usunięciu chwilowej niedostępności DNS.

RFC 6376 i moment zgłoszenia problemu do serwisu

Do serwisu warto zgłosić się wtedy, gdy wiadomości z własnej domeny regularnie trafiają do spamu, podpis DKIM zmienia wynik po przejściu przez określony system albo korespondencja jest odrzucana mimo pozornie poprawnych ustawień. Przydatne będzie przekazanie pełnych nagłówków przykładowej wiadomości, informacji o używanym programie pocztowym oraz opisu tego, czy problem dotyczy wszystkich odbiorców, czy tylko wybranych domen. Takie dane skracają drogę do ustalenia, czy przyczyna leży w DNS, konfiguracji podpisującego, modyfikacji wiadomości czy w filtrach odbiorcy.

W przypadku problemów z komputerem używanym do obsługi poczty, błędów programu, utraty dostępu do konta lub podejrzenia niepożądanej zmiany ustawień można skorzystać z pomocy firmy Warszawskie Pogotowie Komputerowe 24/7. Przed przekazaniem sprzętu albo danych należy przygotować opis objawów i nie usuwać pochopnie komunikatów, nagłówków czy logów, ponieważ mogą być potrzebne do odtworzenia przebiegu zdarzenia. Przy diagnostyce poczty szczególne znaczenie ma rozdzielenie problemu lokalnego urządzenia od ustawień domeny i systemu odbiorczego.

RFC 6376 pozostaje użytecznym punktem odniesienia przy analizie podpisów DKIM, ale skuteczna diagnoza wymaga spojrzenia na cały łańcuch dostarczania wiadomości. Należy uwzględnić konfigurację DNS, wybór domeny i selektora, ochronę klucza prywatnego, sposób modyfikowania wiadomości przez systemy pośrednie oraz współdziałanie z SPF i DMARC. Dopiero zestawienie tych elementów pozwala ocenić, czy problem wynika z błędnej konfiguracji, naturalnej zmiany treści podczas transportu, chwilowej awarii czy rzeczywistego naruszenia wiarygodności nadawcy.