OpenDKIM

OpenDKIM to otwarta implementacja podpisywania i weryfikacji wiadomości standardem DKIM.

OpenDKIM jako warstwa podpisu wiadomości

OpenDKIM jest otwartą implementacją mechanizmu DKIM, czyli standardu pozwalającego podpisywać wiadomości wychodzące oraz weryfikować podpisy dołączone do wiadomości przychodzących. Nie jest samodzielnym serwerem pocztowym ani kompletnym systemem filtrowania spamu. Działa jako element większego środowiska pocztowego i współpracuje z programem odpowiedzialnym za przyjmowanie oraz przekazywanie poczty, najczęściej za pośrednictwem interfejsu Milter.

Podpis DKIM powstaje na podstawie wybranych nagłówków wiadomości i jej treści. Nadawca używa klucza prywatnego, który powinien pozostać dostępny wyłącznie dla właściwego procesu podpisującego. Do wiadomości dołączany jest nagłówek DKIM-Signature, zawierający między innymi domenę podpisującą, selektor klucza, listę podpisywanych nagłówków, metodę kanonikalizacji oraz skrót treści. Odbiorca odczytuje te informacje, pobiera klucz publiczny z systemu DNS i sprawdza, czy podpis odpowiada odebranej wiadomości.

Istotą rozwiązania nie jest szyfrowanie korespondencji. DKIM nie ukrywa treści przed osobami pośredniczącymi w dostarczeniu poczty. Jego zadaniem jest powiązanie wiadomości z domeną, która dysponuje kluczem prywatnym, oraz wykrycie zmian dokonanych po podpisaniu. Dzięki temu system odbiorczy może uzyskać dodatkową informację przy ocenie wiarygodności wiadomości, choć sam poprawny podpis nie stanowi pełnej gwarancji, że nadawca jest godny zaufania.

OpenDKIM, DKIM i pozostałe mechanizmy uwierzytelniania

OpenDKIM realizuje podpisywanie i weryfikację DKIM, natomiast sam standard DKIM opisuje sposób tworzenia podpisu, publikowania kluczy oraz sprawdzania integralności wiadomości. W praktycznej konfiguracji należy odróżnić kilka warstw. Program pocztowy odpowiada za transport wiadomości, OpenDKIM wykonuje operacje kryptograficzne i przekazuje wynik do transportu, DNS udostępnia klucz publiczny, a polityki domenowe mogą określać sposób interpretacji rezultatów.

DKIM różni się od SPF zakresem informacji. SPF sprawdza, czy adres IP systemu wysyłającego jest uprawniony do korzystania z danej domeny w określonym kontekście transportowym. DKIM ocenia podpis związany z wiadomością i domeną wskazaną w podpisie. Oba mechanizmy mogą działać równolegle, ponieważ odpowiadają na inne pytania. SPF jest bardziej związany z trasą dostarczenia, a DKIM z integralnością treści i wybranych nagłówków.

Ważnym uzupełnieniem jest DMARC. Ta polityka pozwala określić, jak traktować wiadomości, które nie przechodzą kontroli, oraz umożliwia otrzymywanie raportów od systemów odbiorczych. DMARC bierze pod uwagę zgodność domeny widocznej w adresie nadawcy z domeną potwierdzoną przez SPF albo DKIM. Z tego powodu poprawne uruchomienie OpenDKIM powinno uwzględniać nie tylko sam proces podpisywania, lecz także dobór domeny podpisującej i spójność konfiguracji DNS.

Warto też pamiętać, że podpis może przetrwać przekazywanie wiadomości, ale nie każdą modyfikację. Zmiana tematu, części nagłówków, kodowania albo treści przez pośredni system może spowodować niepowodzenie weryfikacji. Zależnie od ustawień podpisywane są tylko wybrane nagłówki, dlatego konfiguracja powinna uwzględniać typowe zachowanie używanego oprogramowania pocztowego i pośrednich bram.

OpenDKIM a typowe problemy konfiguracyjne

Jednym z najczęstszych problemów jest brak lub błędna publikacja rekordu TXT w DNS. Nazwa rekordu musi uwzględniać selektor oraz domenę, a zawartość powinna zawierać właściwy klucz publiczny. Literówka w selektorze, niepoprawny podział długiego rekordu albo pozostawienie starego klucza powoduje, że odbiorca nie może dopasować danych DNS do podpisu. Zmiany w DNS mogą być widoczne z opóźnieniem, dlatego testowanie bezpośrednio po edycji może prowadzić do mylnej oceny.

Drugą grupę trudności stanowi niewłaściwe wskazanie klucza prywatnego. Proces OpenDKIM musi mieć możliwość odczytu pliku, ale dostęp do niego powinien być ograniczony. Zbyt szerokie uprawnienia zwiększają ryzyko ujawnienia klucza, natomiast zbyt restrykcyjne ustawienia mogą uniemożliwić podpisywanie. Po zmianie właściciela procesu, ścieżki pliku lub sposobu uruchamiania usługi pojawiają się niekiedy błędy, które w logach wyglądają jak problem z samą kryptografią.

Nieprawidłowy rezultat może wynikać także z mapowania domen i selektorów. W środowisku obsługującym kilka domen należy ustalić, czy jedna domena ma korzystać z jednego klucza, czy każda z nich otrzyma osobny selektor. Trzeba również sprawdzić, czy wiadomości lokalne, przekazywane oraz wychodzące przez różne trasy są podpisywane zgodnie z założeniami. Sama obecność nagłówka DKIM-Signature nie wystarcza, ponieważ podpis może mieć status negatywny.

Przy diagnozowaniu warto rozróżnić błąd związany z pobraniem klucza, błąd kryptograficzny, zmianę treści po podpisaniu oraz odrzucenie wiadomości przez politykę odbiorcy. Pomocne są nagłówki otrzymane po dostarczeniu, komunikaty zwrotne, logi usługi pocztowej i raporty DMARC. Analiza powinna obejmować pełną drogę wiadomości, ponieważ problem może pojawić się zarówno podczas tworzenia podpisu, jak i na etapie późniejszego przekazania korespondencji.

OpenDKIM i praktyczne wskazówki dla stabilnej pracy

Przed rozpoczęciem konfiguracji powinno się ustalić, która domena ma podpisywać wiadomości, jakie selektory będą używane oraz gdzie bezpiecznie przechowywane będą klucze. Selek­tory warto dobierać w sposób pozwalający na późniejszą wymianę klucza bez przerywania wysyłki. Rotacja może wtedy polegać na opublikowaniu nowego klucza, przełączeniu podpisywania i usunięciu poprzedniego dopiero po czasie potrzebnym na odświeżenie informacji DNS.

Klucz prywatny należy chronić podobnie jak inne dane uwierzytelniające. Nie powinien być umieszczany w publicznie dostępnych katalogach, kopiach konfiguracji ani niekontrolowanych archiwach. Przy podejrzeniu ujawnienia klucza trzeba opublikować nowy klucz publiczny i zmienić konfigurację podpisywania. Samo usunięcie pliku prywatnego bez aktualizacji DNS nie rozwiązuje problemu, ponieważ odbiorcy nadal mogą próbować weryfikować wiadomości przy użyciu starego klucza.

Po wdrożeniu warto wysłać wiadomości testowe do kilku niezależnych skrzynek i sprawdzić pełne nagłówki. Należy zweryfikować wynik DKIM, domenę podpisującą, selektor, listę nagłówków oraz zgodność treści po przejściu przez używane filtry. Test powinien obejmować zwykłą wiadomość tekstową, wiadomość HTML, załącznik oraz przypadek przekazania przez dodatkowy element pośredni, jeżeli występuje w danej konfiguracji.

Nie powinno się traktować pojedynczego wyniku jako dowodu poprawności całego rozwiązania. Zmiana dostawcy DNS, aktualizacja programu pocztowego, modyfikacja filtrów albo dodanie nowej domeny może zmienić zachowanie systemu. Dobrą praktyką jest zachowanie dokumentacji selektorów, lokalizacji kluczy, zakresu podpisywanych domen oraz sposobu sprawdzania logów. Ułatwia to późniejszą analizę i ogranicza ryzyko przypadkowego usunięcia potrzebnego rekordu.

OpenDKIM i moment zgłoszenia problemu do serwisu

Do konsultacji warto zgłosić się wtedy, gdy wiadomości regularnie trafiają do spamu mimo poprawnej konfiguracji, odbiorcy zgłaszają nieudane sprawdzanie podpisu albo po zmianie DNS przestaje działać wysyłanie poczty. Wskazaniem jest również sytuacja, w której logi wskazują na brak dostępu do klucza, niezgodność domeny, odrzucenie przez interfejs Milter lub zmianę treści po podpisaniu. Pomocne będzie przekazanie przykładowych nagłówków, komunikatów błędów i informacji o ostatnich zmianach, bez udostępniania klucza prywatnego.

Jeżeli problem z OpenDKIM wiąże się z konfiguracją komputera, dostępem do plików, działaniem usługi pocztowej albo analizą logów, można zgłosić urządzenie do firmy Warszawskie Pogotowie Komputerowe 24/7. Przed rozpoczęciem prac warto opisać, czy błąd dotyczy wszystkich wiadomości, jednej domeny, konkretnego odbiorcy czy tylko wiadomości z załącznikami. Takie rozróżnienie ułatwia oddzielenie problemu lokalnego od błędu w DNS lub po stronie systemu odbiorczego.

Nie należy przekazywać osobom postronnym haseł, kluczy prywatnych ani pełnych danych dostępowych bez ustalenia bezpiecznego sposobu pracy. Do wstępnej analizy zwykle wystarczają komunikaty błędów, zanonimizowane nagłówki oraz publiczne informacje o rekordzie DKIM. Dopiero po zebraniu tych danych można ocenić, czy przyczyną jest sam OpenDKIM, transport wiadomości, DNS, filtr pośredni czy polityka zastosowana przez odbiorcę.