RFC 6376 opisuje kryptograficzny mechanizm potwierdzający, że wiadomość nie została zmieniona po podpisaniu.
RFC 6376 i cel podpisu DKIM
RFC 6376 definiuje mechanizm DomainKeys Identified Mail, znany jako DKIM. Nadawca poczty może dołączyć do wiadomości nagłówek DKIM-Signature zawierający podpis kryptograficzny. Podpis jest tworzony na podstawie wybranych nagłówków wiadomości oraz znormalizowanej treści umieszczonej w jej części tekstowej. Serwer odbiorcy pobiera klucz publiczny z systemu DNS i sprawdza, czy podpis pasuje do odebranych danych. Pomyślna weryfikacja oznacza, że podpisane elementy wiadomości nie zostały zmienione w sposób wykrywany przez ten mechanizm po utworzeniu podpisu.
DKIM nie szyfruje wiadomości i nie ukrywa jej treści przed serwerami pośredniczącymi. Nie jest również samodzielnym dowodem, że osoba korzystająca z adresu nadawcy jest jego właścicielem. Mechanizm potwierdza powiązanie podpisu z domeną wskazaną w parametrze d= oraz integralność określonych danych. Ocenę, czy domena podpisująca jest zgodna z domeną widoczną w polu From:, wykonują reguły DMARC, a DKIM jest jednym z mechanizmów wykorzystywanych w takiej ocenie.
Elementy nagłówka DKIM-Signature
Podpis DKIM zawiera zestaw tagów opisujących sposób weryfikacji. v=1 oznacza wersję protokołu, a= wskazuje algorytm podpisu, a d= określa domenę podpisującą. Parametr s= jest selektorem używanym do znalezienia właściwego klucza publicznego w DNS. Jeżeli selektor ma wartość mail2026, odbiorca szuka rekordu TXT pod nazwą mail2026._domainkey.example.pl. Tag h= wylicza nagłówki objęte podpisem, bh= zawiera skrót treści wiadomości, natomiast b= przechowuje właściwy podpis.
RFC 6376 opisuje między innymi algorytm podpisu rsa-sha256. W praktyce odbiorca najpierw stosuje wskazaną kanonikalizację nagłówków i treści, następnie oblicza skrót wiadomości i porównuje wynik z informacjami zapisanymi w podpisie. Dla nagłówków oraz treści można stosować tryb simple albo relaxed. Tryb relaxed toleruje część zmian formatowania, takich jak wielokrotne białe znaki, co ogranicza liczbę nieuzasadnionych błędów po przejściu wiadomości przez systemy pocztowe.
Lista w h= ma znaczenie praktyczne, ponieważ DKIM nie musi obejmować wszystkich nagłówków. Zmiana nagłówka, który nie został objęty podpisem, może nie spowodować błędu weryfikacji. Z kolei zmiana podpisanej treści, adresu wybranego w From: albo innego wskazanego nagłówka zwykle prowadzi do niezgodności skrótu lub podpisu. Opcjonalny parametr l= ogranicza podpisywaną długość treści, ale jego użycie może pozwolić na dopisanie danych poza podpisanym fragmentem, dlatego odbiorca powinien traktować taki podpis ostrożnie.
Weryfikacja, DNS i typowe przyczyny błędu
Do sprawdzenia podpisu potrzebny jest dostęp do rekordu TXT odpowiadającego parze selektora i domeny. Rekord zawiera klucz publiczny DKIM, zwykle oznaczony tagiem p=. Jeśli rekord nie istnieje, jest niedostępny, ma błędną nazwę, zawiera uszkodzony klucz albo przekroczono ograniczenia odpowiedzi DNS, odbiorca nie może poprawnie zakończyć weryfikacji. Błąd może również wystąpić wtedy, gdy podpis wskazuje inny selektor niż ten, dla którego opublikowano klucz, albo gdy rekord został zmieniony przed dotarciem wiadomości do odbiorcy.
Drugą grupę problemów stanowią modyfikacje wykonywane po podpisaniu. Bramka pocztowa, filtr antyspamowy, program dodający stopkę lub system zmieniający kodowanie może naruszyć podpisaną treść. Podobny skutek może mieć usunięcie, przepisanie albo zmiana kolejności podpisanych nagłówków. Zgodność DKIM nie zależy jednak od tego, czy wiadomość wygląda identycznie znak po znaku w każdym kliencie, ponieważ RFC 6376 przewiduje kanonikalizację. Istotne jest to, czy po zastosowaniu wskazanego trybu simple lub relaxed wynik kryptograficzny nadal odpowiada podpisowi.
Wynik kontroli może mieć postać dkim=pass, dkim=fail, dkim=none albo innego stanu zależnego od implementacji odbiorcy. pass oznacza poprawne odnalezienie klucza i zgodność podpisu. fail wskazuje, że podpis był obecny, lecz nie przeszedł weryfikacji. none zwykle oznacza brak podpisu, a nie potwierdzenie autentyczności wiadomości. Sam wynik DKIM nie określa jeszcze, czy wiadomość ma zostać dostarczona, oznaczona jako spam lub odrzucona; taką decyzję podejmują reguły systemu odbiorczego, często razem z SPF, DMARC i filtrami reputacyjnymi.
DKIM w praktyce użytkownika komputera
Na laptopie lub komputerze PC problem z DKIM najczęściej ujawnia się pośrednio: wiadomość trafia do spamu, pojawia się ostrzeżenie o nieudanej autoryzacji albo narzędzie do analizy nagłówków pokazuje dkim=fail. Klient pocztowy może wyświetlać tylko skrócony komunikat, dlatego dokładniejszą ocenę wykonuje się na pełnych nagłówkach wiadomości. Warto sprawdzić wartości d=, s=, a=, c=, h= i wynik kontroli zapisany przez serwer odbiorcy w nagłówku Authentication-Results.
Jeżeli błąd występuje tylko na jednym komputerze, należy odróżnić problem weryfikacji po stronie odbiorcy od problemu samego programu pocztowego. Można porównać tę samą wiadomość w webmailu i w aplikacji zainstalowanej lokalnie, sprawdzić pełne nagłówki oraz upewnić się, że aplikacja nie modyfikuje treści przy przekazywaniu wiadomości. Gdy identyczny błąd pojawia się u różnych odbiorców, przyczyną jest częściej niezgodność podpisu, selektora lub rekordu DNS domeny nadawcy niż awaria sprzętu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z aplikacjami pocztowymi, konfiguracją systemu oraz poprawnym odczytem nagłówków wiadomości.
