A DKIM-Signature to zestaw oddzielonych średnikami znaczników opisujących sposób, w jaki domena podpisała wiadomość. Czytanie tych pól pomaga wybrać właściwą ścieżkę wyszukiwania i badania DNS . Nie pozwala na sprawdzenie kryptografii naocznie. Zachowaj oryginalną wiadomość przed skopiowaniem lub ponownym sformatowaniem podpisu w celu sprawdzenia.
Zacznij od pól wyszukiwania i algorytmów
Wymagana wartość d= to domena podpisująca; wymagane s= to selektor. W przypadku normalnej metody zapytania DNS TXT prowadzą one do s. _domainkey.d. Znacznik a= identyfikuje algorytm podpisywania i mieszania. Wymagany znacznik v= musi mieć wartość 1 dla składni podpisu RFC 6376 . Różni się to od znacznika wersji w rekordzie klucza DNS . Wartości te opisują podpis, a nie wynik jego weryfikacji. RFC 6376 §3.5, RFC 6376 §3.6.2.
Fragment ilustracyjny, celowo niekompletny i nieprawidłowy podpis: d=example.com; s=outbound2026; a=rsa-sha256; c=relaxed/relaxed; h=from:to:subject:date. Jego nazwa wyszukiwania to outbound2026._domainkey.example.com . Jego kanonizacja wykorzystuje zrelaksowane przetwarzanie zarówno dla nagłówków, jak i treści. Lista podpisanych nagłówków zawiera nazwy wybranych pól nagłówka. Fragment pomija wymagane wartości kryptograficzne i nie może być nigdy używany jako zapis produkcyjny.
Odróżnij zakres treści od danych podpisu
Znacznik h= wyświetla pola nagłówka dostarczone do operacji podpisywania, w ich określonej kolejności. To nie jest algorytm mieszający. Od musi być zawarte w prawidłowym podpisie DKIM . Powtarzające się nazwy nagłówków i zduplikowane pola wiadomości wymagają reguł wyboru zawartych w specyfikacji; przypadkowe spojrzenie na listę nie jest w stanie rozwiązać wszystkich pytań dotyczących zasięgu.
Znacznik bh= przechowuje skrót ciała. Znacznik b= przechowuje wartość podpisu. Dopasowane lub wiarygodnie wyglądające kodowania nie dowodzą ważności. Znacznik c= opisuje kanonizację, która pozwala na specyficzną normalizację podpisanej reprezentacji. Nie pozwala na dowolne przepisywanie komunikatu. Jeśli pominięto c=, wartością domyślną jest prosty/prosty; jeśli zostanie nazwany tylko jeden algorytm, ma on zastosowanie do nagłówków, a treść domyślnie jest prosta. RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §5.4.
Opcjonalny znacznik l= ogranicza liczbę zawartych w kanonizowanych oktetach treści. Jego obecność wymaga ostrożności: ważny podpis nie może obejmować treści dołączonej powyżej tej długości. Nie opisuj każdego DKIM przekazać jako dowód, że każdy widoczny bajt pozostaje niezmieniony. RFC 6376 §3.5, RFC 6376 §8.2.
Ostrożnie interpretuj tożsamość i czas
Opcjonalna wartość i= to identyfikator agenta lub użytkownika potwierdzony zgodnie z regułami domeny podpisującej; niekoniecznie jest to działająca skrzynka pocztowa. DMARC używa sprawdzonego d=, a nie i=, dla DKIM wyrównanie. Tagi t= i x= opisują czas podpisania i wygaśnięcie podpisu. RFC 6376 §3.5 formalnie oznacza oba ZALECANE, chociaż mogą być nieobecne. Są to metadane podpisu, a nie dowód faktycznego czasu przybycia SMTP . Zachowaj odebrane nagłówki i dzienniki systemowe do analizy transportu.
Podpisu wykorzystującego przestarzałą kryptografię nie należy akceptować tylko dlatego, że jego pola są analizowane. RFC 8301 §3.1 zabrania rsa-sha1; RFC 8301 §3.2 aktualizuje kluczowe wymagania RSA. Zamiast ręcznie przeprowadzać kontrole z tego przewodnika, korzystaj z obsługiwanego oprogramowania weryfikacyjnego i aktualnych wskazówek dostawcy.
Zakończ z wynikiem odbiornika
Zbierz parę d/s, algorytm, odpowiednie pola zasięgu, zaufany wynik DKIM i przyczynę niepowodzenia. Jeśli brakuje DNS , sprawdź dokładną nazwę właściciela i cykl życia klucza. Jeśli klucz jest dostępny, ale weryfikacja się nie powiedzie, porównaj ścieżki podpisania i dostarczenia bez zmiany oryginalnego dowodu. Potwierdź wszelkie działania naprawcze za pomocą nowo wysłanej wiadomości i wyniku zaufanego odbiorcy. Celem jest możliwe do obrony wyjaśnienie podpisu, a nie wizualne odgadnięcie pozytywnego/negatywnego wyniku.
Zastosuj rozróżnienie
Przeczytaj fragment ilustracyjny w czterech grupach: d/s wybiera tożsamość i wyszukiwanie; a/c określa algorytm i kanonizację; h i dowolne l definiują zasięg; b/bh niosą wartości weryfikowane przez oprogramowanie. Brak wymaganego v/b/bh oznacza, że fragment nie jest prawidłowym podpisem. Jeśli w sygnaturze rzeczywistej pojawia się l=0 , oktety z treścią zerową są szyfrowane, więc integralność treści nie jest chroniona; RFC 6376 §3.5 definiuje ten mechanizm długości. Żadna z tych obserwacji nie jest przepustką kryptograficzną.