Walidacja DKIM: Najlepsza praktyka uwierzytelniania e-maili
Ptak
8 kwi 2017
1 min read
Najważniejsze informacje
DKIM (DomainKeys Identified Mail) to oparty na treści metoda uwierzytelniania wiadomości e-mail, która weryfikuje, czy wiadomość została zmieniona po jej podpisaniu.
W przeciwieństwie do SPF, który waliduje ścieżkę wysyłania, DKIM waliduje treść wiadomości samą w sobie, używając podpisów kryptograficznych.
DKIM używa dwóch kluczy: klucza prywatnego do podpisywania wychodzących wiadomości i klucza publicznego opublikowanego w DNS, aby odbiorcy mogli zweryfikować podpisy.
Podpis DKIM zawiera hasze zarówno nagłówków, jak i ciała, selektory, znaczniki czasowe oraz pola tożsamości — wszystko, co odbiorca musi odtworzyć i zweryfikować.
Walidacja DKIM polega na otrzymaniu całej wiadomości najpierw, co oznacza, że błędy mogą wystąpić późno w procesie.
Rozwiązywanie problemów z nieudanymi walidacjami DKIM jest często trudne, ponieważ nadawcy i odbiorcy nie mogą odtworzyć swoich środowisk podpisywania/weryfikacji.
Nawet gdy DKIM zawiedzie, zazwyczaj nie powoduje bezpośrednio problemów z dostarczaniem na własną rękę, chyba że jest połączone z innymi negatywnymi sygnałami reputacyjnymi.
Podsumowanie pytań i odpowiedzi
Co tak naprawdę robi DKIM?
DKIM dołącza podpis kryptograficzny do wiadomości e-mail, pozwalając serwerowi odbierającemu potwierdzić, czy treść wiadomości została zmieniona po jej wysłaniu.
Jak DKIM różni się od SPF?
SPF weryfikuje kto ma prawo do wysyłania wiadomości e-mail dla danej domeny (oparte na ścieżce).
DKIM weryfikuje, czy zawartość jest nienaruszona (oparte na treści).
Oba pełnią różne funkcje i uzupełniają się nawzajem.
Co znajduje się w nagłówku DKIM-Signature?
Kluczowe pola obejmują:
v= wersja
a= algorytm
c= zasady kanonizacji
d= domena podpisu
s= wybór
h= nagłówki zawarte w podpisie
bh= hash ciała
b= dane rzeczywiste podpisu
Każda część przyczynia się do tego, jak podpis jest weryfikowany.
Jak serwer odbierający weryfikuje DKIM?
Ekstrahuje wartości d= i s=.
Wyszukuje klucz publiczny pod:
selector._domainkey.domain
Regeneruje nagłówki i sumy kontrolne treści.
Porównuje je z wartościami bh= i b= w e-mailu.
Jeśli pasują, wiadomość przechodzi DKIM.
Co powoduje, że DKIM się nie udaje?
Wiadomość zmieniona w tranzycie (nawet zmiany białych znaków, jeśli używasz ścisłej kanonizacji)
Nieprawidłowy lub brakujący klucz publiczny w DNS
Błędy formatowania DNS
Selector usunięty lub niepoprawnie rotowany
Niezgodne tożsamości (i= muszą być tym samym domeną lub subdomeną co d=)
Dlaczego błędy DKIM mogą być trudne do zdiagnozowania?
Ponieważ sygnatariusz i walidator działają w zupełnie różnych środowiskach — żadna ze stron nie może odtworzyć warunków haszowania lub stanu podpisu drugiej strony.
Sprawia to, że nieprzezroczyste błędy „niedopasowania haszy” są najtrudniejsze do zdiagnozowania.
Czy awaria DKIM oznacza, że e-mail trafi do spamu?
Niekoniecznie.
DKIM to tylko jeden sygnał. Jeśli domena ma silną reputację i przechodzi inne kontrole (SPF, zgodność DMARC, niskie wskaźniki skarg), izolowane awarie DKIM zazwyczaj nie wpływają na dostarczanie wiadomości samodzielnie.
Dlaczego w ogóle używać DKIM?
Chroni integralność wiadomości
Buduje reputację domeny
Umożliwia zgodność DMARC
Pomaga dostawcom skrzynek pocztowych rozróżnić legalnych nadawców od fałszerzy
DKIM jest uważane za najlepszą praktykę dla wszystkich poważnych nadawców e-maili.
Kiedy mówimy o „uwierzytelnianiu e-maili”, mamy na myśli technikę, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość rzeczywiście pochodzi od wskazanej źródła. Idea stojąca za takimi technikami polega na uzyskaniu pewnego poziomu obrony przed oszukańczymi e-mailami, takimi jak phishing i spoofing, które mogą osłabić zaufanie odbiorcy do otrzymywania e-maili. Należy jednak zauważyć, że wysyłanie uwierzytelnionych e-maili nie oznacza, że e-mail jest dobry lub pożądany; oznacza to tylko, że istnieje możliwość wiarygodnego ustanowienia reputacji dla uwierzytelnionej strony, która może być wykorzystywana w decyzjach dotyczących akceptacji i umieszczania e-maili.
Obecnie w użyciu są dwie formy uwierzytelniania e-maili:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście opiszę, czym jest DKIM i jak działa.
Kiedy mówimy o „uwierzytelnianiu e-maili”, mamy na myśli technikę, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość rzeczywiście pochodzi od wskazanej źródła. Idea stojąca za takimi technikami polega na uzyskaniu pewnego poziomu obrony przed oszukańczymi e-mailami, takimi jak phishing i spoofing, które mogą osłabić zaufanie odbiorcy do otrzymywania e-maili. Należy jednak zauważyć, że wysyłanie uwierzytelnionych e-maili nie oznacza, że e-mail jest dobry lub pożądany; oznacza to tylko, że istnieje możliwość wiarygodnego ustanowienia reputacji dla uwierzytelnionej strony, która może być wykorzystywana w decyzjach dotyczących akceptacji i umieszczania e-maili.
Obecnie w użyciu są dwie formy uwierzytelniania e-maili:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście opiszę, czym jest DKIM i jak działa.
Kiedy mówimy o „uwierzytelnianiu e-maili”, mamy na myśli technikę, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość rzeczywiście pochodzi od wskazanej źródła. Idea stojąca za takimi technikami polega na uzyskaniu pewnego poziomu obrony przed oszukańczymi e-mailami, takimi jak phishing i spoofing, które mogą osłabić zaufanie odbiorcy do otrzymywania e-maili. Należy jednak zauważyć, że wysyłanie uwierzytelnionych e-maili nie oznacza, że e-mail jest dobry lub pożądany; oznacza to tylko, że istnieje możliwość wiarygodnego ustanowienia reputacji dla uwierzytelnionej strony, która może być wykorzystywana w decyzjach dotyczących akceptacji i umieszczania e-maili.
Obecnie w użyciu są dwie formy uwierzytelniania e-maili:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście opiszę, czym jest DKIM i jak działa.
Przegląd DKIM
W przeciwieństwie do swojego odpowiednika uwierzytelniającego SPF, który zapewnia sposób dla domeny na autoryzację hosta do wysyłania wiadomości w jej imieniu, DKIM zapewnia sposób dla podmiotu (domena, organizacja, osoba itp.) na wzięcie odpowiedzialności za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i podmiot wysyłający będą tymi samymi lub przynajmniej ściśle powiązanymi, z DKIM nie ma wymogu, aby tak było.
Moje cele dla Ciebie w tym poście to nauczenie się i zrozumienie następujących pojęć dotyczących DKIM:
DKIM to uwierzytelnianie „oparte na treści”, w przeciwieństwie do „opartego na ścieżce” SPF.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność przez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Weryfikacja DKIM jest przeprowadzana przez odbierającą domenę próbującą wygenerować te same dwa skróty.
Weryfikacja DKIM nie może być zakończona w wielu przypadkach, aż pełna wiadomość zostanie przesłana przez serwer wysyłający.
Problemy z weryfikacją mogą być trudne do zdiagnozowania.
W przeciwieństwie do swojego odpowiednika uwierzytelniającego SPF, który zapewnia sposób dla domeny na autoryzację hosta do wysyłania wiadomości w jej imieniu, DKIM zapewnia sposób dla podmiotu (domena, organizacja, osoba itp.) na wzięcie odpowiedzialności za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i podmiot wysyłający będą tymi samymi lub przynajmniej ściśle powiązanymi, z DKIM nie ma wymogu, aby tak było.
Moje cele dla Ciebie w tym poście to nauczenie się i zrozumienie następujących pojęć dotyczących DKIM:
DKIM to uwierzytelnianie „oparte na treści”, w przeciwieństwie do „opartego na ścieżce” SPF.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność przez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Weryfikacja DKIM jest przeprowadzana przez odbierającą domenę próbującą wygenerować te same dwa skróty.
Weryfikacja DKIM nie może być zakończona w wielu przypadkach, aż pełna wiadomość zostanie przesłana przez serwer wysyłający.
Problemy z weryfikacją mogą być trudne do zdiagnozowania.
W przeciwieństwie do swojego odpowiednika uwierzytelniającego SPF, który zapewnia sposób dla domeny na autoryzację hosta do wysyłania wiadomości w jej imieniu, DKIM zapewnia sposób dla podmiotu (domena, organizacja, osoba itp.) na wzięcie odpowiedzialności za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i podmiot wysyłający będą tymi samymi lub przynajmniej ściśle powiązanymi, z DKIM nie ma wymogu, aby tak było.
Moje cele dla Ciebie w tym poście to nauczenie się i zrozumienie następujących pojęć dotyczących DKIM:
DKIM to uwierzytelnianie „oparte na treści”, w przeciwieństwie do „opartego na ścieżce” SPF.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność przez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Weryfikacja DKIM jest przeprowadzana przez odbierającą domenę próbującą wygenerować te same dwa skróty.
Weryfikacja DKIM nie może być zakończona w wielu przypadkach, aż pełna wiadomość zostanie przesłana przez serwer wysyłający.
Problemy z weryfikacją mogą być trudne do zdiagnozowania.
„Oparte na treści” uwierzytelnianie
DKIM nazywa się uwierzytelnianiem „opartym na treści”, a nie „opartym na ścieżce”, ponieważ to, czy wiadomość przechodzi walidację DKIM, zależy wyłącznie od tego, czy treść zmieniła się od momentu jej podpisania do momentu, gdy próbowano walidacji.
DKIM nazywa się uwierzytelnianiem „opartym na treści”, a nie „opartym na ścieżce”, ponieważ to, czy wiadomość przechodzi walidację DKIM, zależy wyłącznie od tego, czy treść zmieniła się od momentu jej podpisania do momentu, gdy próbowano walidacji.
DKIM nazywa się uwierzytelnianiem „opartym na treści”, a nie „opartym na ścieżce”, ponieważ to, czy wiadomość przechodzi walidację DKIM, zależy wyłącznie od tego, czy treść zmieniła się od momentu jej podpisania do momentu, gdy próbowano walidacji.
Podpisywanie i walidacja DKIM
Organizacje pragnące podpisać pocztę za pomocą DKIM najpierw generują dwa klucze kryptograficzne. Jeden z kluczy pozostaje prywatny i jest dostępny dla serwera wysyłającego do podpisywania poczty, a drugi powinien być udostępniony publicznie w DNS, aby mógł być użyty przez domeny odbierające w próbach weryfikacji podpisu. Metody generowania tych kluczy i instalowania ich są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację w DNS publicznego klucza DKIM.
Organizacje pragnące podpisać pocztę za pomocą DKIM najpierw generują dwa klucze kryptograficzne. Jeden z kluczy pozostaje prywatny i jest dostępny dla serwera wysyłającego do podpisywania poczty, a drugi powinien być udostępniony publicznie w DNS, aby mógł być użyty przez domeny odbierające w próbach weryfikacji podpisu. Metody generowania tych kluczy i instalowania ich są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację w DNS publicznego klucza DKIM.
Organizacje pragnące podpisać pocztę za pomocą DKIM najpierw generują dwa klucze kryptograficzne. Jeden z kluczy pozostaje prywatny i jest dostępny dla serwera wysyłającego do podpisywania poczty, a drugi powinien być udostępniony publicznie w DNS, aby mógł być użyty przez domeny odbierające w próbach weryfikacji podpisu. Metody generowania tych kluczy i instalowania ich są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację w DNS publicznego klucza DKIM.
Nagłówek DKIM-Signature
Aby rozpocząć nasze zrozumienie DKIM, przyjrzyjmy się najpierw nagłówkowi DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Nagłówek DKIM-Signature to seria par klucz-wartość, niektóre bardziej interesujące dla czytelnika niż inne, ale opiszę je wszystkie tutaj.
Najpierw przyjrzymy się tym, które są głównie interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna ważna wartość)
a=rsa-sha256; – Algorytm użyty do konstruowania kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy reguł dotyczących usuwania białych znaków w nagłówkach i treści, które można zastosować podczas tworzenia skrótów w podpisie DKIM; te reguły nazywane są „regułami kanonikalizacji” (stąd klucz c), a zestawy reguł są albo „relaksacyjne”, albo „ściślejsze”.
t=1454417737; – Znacznik czasu, kiedy podpis został utworzony.
Te trzy części nagłówka zawierają rzeczywiste informacje o podpisie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To jest skrót treści wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To jest lista nagłówków, które zostały użyte do utworzenia danych podpisu pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są rzeczywiste dane podpisu DKIM
Te trzy części są najbardziej interesujące dla serwera odbierającego, który będzie weryfikować podpis:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w imieniu której podpisano wiadomość. Składniowo, będzie to wyglądać jak adres e-mail i może nawet być nim; lokalna część adresu e-mail może być pusta, jak w tym przykładzie, a część domeny musi być taka sama jak lub poddomeną domeny w części d= podpisu.
Powód, dla którego te części są interesujące dla serwera odbierającego, polega na tym, że dostarczają informacje niezbędne do pomocy odbiorcy w weryfikacji podpisów.
Pole | Znaczenie | Jak Odbiorcy to Używają |
|---|---|---|
v= | Wersja DKIM (zawsze 1) | Potwierdza format podpisu |
a= | Algorytm haszowania + podpisywania (np. rsa-sha256) | Zapewnia, że walidator prawidłowo reprodukuje podpis |
c= | Reguły kanonikalizacji (nagłówek/treść) | Normalizuje białe znaki przed haszowaniem |
t= | Znacznik czasu utworzenia podpisu | Używany do kontroli świeżości i zapobiegania odtwarzaniu |
bh= | Skrót treści | Odbiorca regeneruje to, aby potwierdzić integralność treści wiadomości |
h= | Lista podpisanych pól nagłówkowych | Zapewnia, że nagłówki użyte w podpisywaniu są dostępne i niezmienione |
b= | Rzeczywisty podpis DKIM | Odbiorca weryfikuje ten podpis w porównaniu do klucza publicznego |
d= | Domena podpisująca | Używana do zlokalizowania publicznego klucza DNS podpisującego |
s= | Selektor | Połączona z domeną aby utworzyć: selector._domainkey.domain |
i= | Tożsamość podpisująca | Musi być taka sama lub poddomeną d=, identyfikuje podmiot podpisujący |
Aby rozpocząć nasze zrozumienie DKIM, przyjrzyjmy się najpierw nagłówkowi DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Nagłówek DKIM-Signature to seria par klucz-wartość, niektóre bardziej interesujące dla czytelnika niż inne, ale opiszę je wszystkie tutaj.
Najpierw przyjrzymy się tym, które są głównie interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna ważna wartość)
a=rsa-sha256; – Algorytm użyty do konstruowania kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy reguł dotyczących usuwania białych znaków w nagłówkach i treści, które można zastosować podczas tworzenia skrótów w podpisie DKIM; te reguły nazywane są „regułami kanonikalizacji” (stąd klucz c), a zestawy reguł są albo „relaksacyjne”, albo „ściślejsze”.
t=1454417737; – Znacznik czasu, kiedy podpis został utworzony.
Te trzy części nagłówka zawierają rzeczywiste informacje o podpisie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To jest skrót treści wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To jest lista nagłówków, które zostały użyte do utworzenia danych podpisu pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są rzeczywiste dane podpisu DKIM
Te trzy części są najbardziej interesujące dla serwera odbierającego, który będzie weryfikować podpis:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w imieniu której podpisano wiadomość. Składniowo, będzie to wyglądać jak adres e-mail i może nawet być nim; lokalna część adresu e-mail może być pusta, jak w tym przykładzie, a część domeny musi być taka sama jak lub poddomeną domeny w części d= podpisu.
Powód, dla którego te części są interesujące dla serwera odbierającego, polega na tym, że dostarczają informacje niezbędne do pomocy odbiorcy w weryfikacji podpisów.
Pole | Znaczenie | Jak Odbiorcy to Używają |
|---|---|---|
v= | Wersja DKIM (zawsze 1) | Potwierdza format podpisu |
a= | Algorytm haszowania + podpisywania (np. rsa-sha256) | Zapewnia, że walidator prawidłowo reprodukuje podpis |
c= | Reguły kanonikalizacji (nagłówek/treść) | Normalizuje białe znaki przed haszowaniem |
t= | Znacznik czasu utworzenia podpisu | Używany do kontroli świeżości i zapobiegania odtwarzaniu |
bh= | Skrót treści | Odbiorca regeneruje to, aby potwierdzić integralność treści wiadomości |
h= | Lista podpisanych pól nagłówkowych | Zapewnia, że nagłówki użyte w podpisywaniu są dostępne i niezmienione |
b= | Rzeczywisty podpis DKIM | Odbiorca weryfikuje ten podpis w porównaniu do klucza publicznego |
d= | Domena podpisująca | Używana do zlokalizowania publicznego klucza DNS podpisującego |
s= | Selektor | Połączona z domeną aby utworzyć: selector._domainkey.domain |
i= | Tożsamość podpisująca | Musi być taka sama lub poddomeną d=, identyfikuje podmiot podpisujący |
Aby rozpocząć nasze zrozumienie DKIM, przyjrzyjmy się najpierw nagłówkowi DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Nagłówek DKIM-Signature to seria par klucz-wartość, niektóre bardziej interesujące dla czytelnika niż inne, ale opiszę je wszystkie tutaj.
Najpierw przyjrzymy się tym, które są głównie interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna ważna wartość)
a=rsa-sha256; – Algorytm użyty do konstruowania kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy reguł dotyczących usuwania białych znaków w nagłówkach i treści, które można zastosować podczas tworzenia skrótów w podpisie DKIM; te reguły nazywane są „regułami kanonikalizacji” (stąd klucz c), a zestawy reguł są albo „relaksacyjne”, albo „ściślejsze”.
t=1454417737; – Znacznik czasu, kiedy podpis został utworzony.
Te trzy części nagłówka zawierają rzeczywiste informacje o podpisie:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To jest skrót treści wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To jest lista nagłówków, które zostały użyte do utworzenia danych podpisu pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są rzeczywiste dane podpisu DKIM
Te trzy części są najbardziej interesujące dla serwera odbierającego, który będzie weryfikować podpis:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w imieniu której podpisano wiadomość. Składniowo, będzie to wyglądać jak adres e-mail i może nawet być nim; lokalna część adresu e-mail może być pusta, jak w tym przykładzie, a część domeny musi być taka sama jak lub poddomeną domeny w części d= podpisu.
Powód, dla którego te części są interesujące dla serwera odbierającego, polega na tym, że dostarczają informacje niezbędne do pomocy odbiorcy w weryfikacji podpisów.
Pole | Znaczenie | Jak Odbiorcy to Używają |
|---|---|---|
v= | Wersja DKIM (zawsze 1) | Potwierdza format podpisu |
a= | Algorytm haszowania + podpisywania (np. rsa-sha256) | Zapewnia, że walidator prawidłowo reprodukuje podpis |
c= | Reguły kanonikalizacji (nagłówek/treść) | Normalizuje białe znaki przed haszowaniem |
t= | Znacznik czasu utworzenia podpisu | Używany do kontroli świeżości i zapobiegania odtwarzaniu |
bh= | Skrót treści | Odbiorca regeneruje to, aby potwierdzić integralność treści wiadomości |
h= | Lista podpisanych pól nagłówkowych | Zapewnia, że nagłówki użyte w podpisywaniu są dostępne i niezmienione |
b= | Rzeczywisty podpis DKIM | Odbiorca weryfikuje ten podpis w porównaniu do klucza publicznego |
d= | Domena podpisująca | Używana do zlokalizowania publicznego klucza DNS podpisującego |
s= | Selektor | Połączona z domeną aby utworzyć: selector._domainkey.domain |
i= | Tożsamość podpisująca | Musi być taka sama lub poddomeną d=, identyfikuje podmiot podpisujący |
Weryfikacja DKIM
Oprócz wymogu, o którym wspomniano, że domena i= musi być taka sama lub poddomeną domeny d=, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM sygnatariusza w DNS. Klucz to rekord TXT w DNS, który zawsze znajduje się pod lokalizacją selector._domainkey.domain. Tak więc, w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM można znaleźć w DNS pod notices._domainkey.welcome.foo.com, i może wyglądać mniej więcej tak:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Walidator używa tego klucza (bitów p=), aby wygenerować własny zestaw skrótów wiadomości; jeśli te skróty pasują, oznacza to, że wiadomość nie została zmieniona w transporcie, a zatem wiadomość może przyczynić się do, a może nawet skorzystać z, reputacji, która jest na miejscu dla sygnatariusza wiadomości.
Oprócz wymogu, o którym wspomniano, że domena i= musi być taka sama lub poddomeną domeny d=, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM sygnatariusza w DNS. Klucz to rekord TXT w DNS, który zawsze znajduje się pod lokalizacją selector._domainkey.domain. Tak więc, w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM można znaleźć w DNS pod notices._domainkey.welcome.foo.com, i może wyglądać mniej więcej tak:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Walidator używa tego klucza (bitów p=), aby wygenerować własny zestaw skrótów wiadomości; jeśli te skróty pasują, oznacza to, że wiadomość nie została zmieniona w transporcie, a zatem wiadomość może przyczynić się do, a może nawet skorzystać z, reputacji, która jest na miejscu dla sygnatariusza wiadomości.
Oprócz wymogu, o którym wspomniano, że domena i= musi być taka sama lub poddomeną domeny d=, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM sygnatariusza w DNS. Klucz to rekord TXT w DNS, który zawsze znajduje się pod lokalizacją selector._domainkey.domain. Tak więc, w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM można znaleźć w DNS pod notices._domainkey.welcome.foo.com, i może wyglądać mniej więcej tak:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Walidator używa tego klucza (bitów p=), aby wygenerować własny zestaw skrótów wiadomości; jeśli te skróty pasują, oznacza to, że wiadomość nie została zmieniona w transporcie, a zatem wiadomość może przyczynić się do, a może nawet skorzystać z, reputacji, która jest na miejscu dla sygnatariusza wiadomości.
Błąd walidacji i rozwiązywanie problemów
Wspomniałem powyżej, że problemy z DKIM mogą być trudne do zdiagnozowania, i wyjaśnię, dlaczego tak jest.
Niektóre przypadki nieprawidłowej walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak publicznego klucza domeny podpisującej w DNS lub nieprawidłowości składniowe, albo być może wiadomość została ewidentnie zmieniona w trakcie przesyłania. Gdy takie przypadki występują, łatwo jest ustalić problem i zaproponować rozwiązanie. Trudniejsze są przypadki, które prowadzą do najbardziej frustrujących doświadczeń z obsługą, to przypadki, w których wiadomość została podpisana, publiczny klucz istnieje w DNS, a zmiany w wiadomości nie były oczywiste, ale walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego te problemy są trudne do zdiagnozowania, jest to, że nie ma prawdziwego sposobu, aby którakolwiek ze stron odtworzyła warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość posiada w swoim nagłówku DKIM-Signature hashe, które zostały wygenerowane przez podpisującego w momencie podpisywania, ale walidator prawdopodobnie nie ma dostępu do infrastruktury podpisującego, więc nie może próbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora i nie ma sposobu, aby spróbować zweryfikować wiadomość w taki sposób, w jaki zrobił to walidator.
Problemy takie, jak opisuję tutaj, są rzadkimi zdarzeniami, a nieprawidłowe walidacje DKIM same w sobie zazwyczaj nie wpływają na położenie dostarczania. Podczas gdy DKIM obsługuje uwierzytelnianie wiadomości, wdrożenie kompleksowych technik walidacji e-mail zapewnia, że wysyłasz do legalnych adresów, które faktycznie mogą odbierać i uwierzytelniać Twoje wiadomości. Z mojego doświadczenia wynika, że takie problemy generują więcej zgłoszeń do wsparcia niż jakikolwiek inny rodzaj problemu DKIM.
Wspomniałem powyżej, że problemy z DKIM mogą być trudne do zdiagnozowania, i wyjaśnię, dlaczego tak jest.
Niektóre przypadki nieprawidłowej walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak publicznego klucza domeny podpisującej w DNS lub nieprawidłowości składniowe, albo być może wiadomość została ewidentnie zmieniona w trakcie przesyłania. Gdy takie przypadki występują, łatwo jest ustalić problem i zaproponować rozwiązanie. Trudniejsze są przypadki, które prowadzą do najbardziej frustrujących doświadczeń z obsługą, to przypadki, w których wiadomość została podpisana, publiczny klucz istnieje w DNS, a zmiany w wiadomości nie były oczywiste, ale walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego te problemy są trudne do zdiagnozowania, jest to, że nie ma prawdziwego sposobu, aby którakolwiek ze stron odtworzyła warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość posiada w swoim nagłówku DKIM-Signature hashe, które zostały wygenerowane przez podpisującego w momencie podpisywania, ale walidator prawdopodobnie nie ma dostępu do infrastruktury podpisującego, więc nie może próbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora i nie ma sposobu, aby spróbować zweryfikować wiadomość w taki sposób, w jaki zrobił to walidator.
Problemy takie, jak opisuję tutaj, są rzadkimi zdarzeniami, a nieprawidłowe walidacje DKIM same w sobie zazwyczaj nie wpływają na położenie dostarczania. Podczas gdy DKIM obsługuje uwierzytelnianie wiadomości, wdrożenie kompleksowych technik walidacji e-mail zapewnia, że wysyłasz do legalnych adresów, które faktycznie mogą odbierać i uwierzytelniać Twoje wiadomości. Z mojego doświadczenia wynika, że takie problemy generują więcej zgłoszeń do wsparcia niż jakikolwiek inny rodzaj problemu DKIM.
Wspomniałem powyżej, że problemy z DKIM mogą być trudne do zdiagnozowania, i wyjaśnię, dlaczego tak jest.
Niektóre przypadki nieprawidłowej walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak publicznego klucza domeny podpisującej w DNS lub nieprawidłowości składniowe, albo być może wiadomość została ewidentnie zmieniona w trakcie przesyłania. Gdy takie przypadki występują, łatwo jest ustalić problem i zaproponować rozwiązanie. Trudniejsze są przypadki, które prowadzą do najbardziej frustrujących doświadczeń z obsługą, to przypadki, w których wiadomość została podpisana, publiczny klucz istnieje w DNS, a zmiany w wiadomości nie były oczywiste, ale walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego te problemy są trudne do zdiagnozowania, jest to, że nie ma prawdziwego sposobu, aby którakolwiek ze stron odtworzyła warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość posiada w swoim nagłówku DKIM-Signature hashe, które zostały wygenerowane przez podpisującego w momencie podpisywania, ale walidator prawdopodobnie nie ma dostępu do infrastruktury podpisującego, więc nie może próbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora i nie ma sposobu, aby spróbować zweryfikować wiadomość w taki sposób, w jaki zrobił to walidator.
Problemy takie, jak opisuję tutaj, są rzadkimi zdarzeniami, a nieprawidłowe walidacje DKIM same w sobie zazwyczaj nie wpływają na położenie dostarczania. Podczas gdy DKIM obsługuje uwierzytelnianie wiadomości, wdrożenie kompleksowych technik walidacji e-mail zapewnia, że wysyłasz do legalnych adresów, które faktycznie mogą odbierać i uwierzytelniać Twoje wiadomości. Z mojego doświadczenia wynika, że takie problemy generują więcej zgłoszeń do wsparcia niż jakikolwiek inny rodzaj problemu DKIM.
