Walidacja DKIM: Najlepsza praktyka w autoryzacji e-maili
Ptak
8 kwi 2017
1 min read
Kluczowe Wnioski
DKIM (DomainKeys Identified Mail) to metoda uwierzytelniania wiadomości e-mail oparta na treści, która weryfikuje, czy wiadomość została zmieniona po jej podpisaniu.
W przeciwieństwie do SPF, który weryfikuje ścieżkę wysyłania, DKIM weryfikuje samą treść wiadomości za pomocą podpisów kryptograficznych.
DKIM korzysta z dwóch kluczy: prywatnego klucza do podpisywania wychodzących wiadomości oraz klucza publicznego opublikowanego w DNS, aby odbiorcy mogli zweryfikować podpisy.
Podpis DKIM zawiera hashe zarówno nagłówków, jak i treści, wybieralniki, znaczniki czasu i pola tożsamości — wszystkie te elementy odbiorca musi odtworzyć i zweryfikować.
Weryfikacja DKIM polega na najpierw otrzymaniu całej wiadomości, co oznacza, że błędy mogą wystąpić na późnym etapie procesu.
Rozwiązywanie problemów z nieudanym uwierzytelnianiem DKIM jest często trudne, ponieważ nadawcy i odbiorcy nie mogą odwzorować środowisk podpisywania/weryfikacji innych.
Nawet gdy DKIM zawodzi, zazwyczaj nie powoduje bezpośrednich problemów z dostarczaniem do Inbox, chyba że w połączeniu z innymi negatywnymi sygnałami reputacyjnymi.
Q&A Highlights
Co faktycznie robi DKIM?
DKIM dołącza podpis kryptograficzny do e-maila, umożliwiając serwerowi odbierającemu potwierdzenie, czy treść wiadomości została zmodyfikowana po jej wysłaniu.
Jak DKIM różni się od SPF?
SPF sprawdza kto jest uprawniony do wysyłania poczty dla domeny (oparte na ścieżce).
DKIM sprawdza, czy zawartość jest nienaruszona (oparte na zawartości).
Oba służą różnym celom i wzajemnie się uzupełniają.
Co znajduje się w nagłówku DKIM-Signature?
Kluczowe pola obejmują:
v= wersja
a= algorytm
c= zasady kanonikalizacji
d= domena podpisująca
s= selektor
h= nagłówki uwzględnione w podpisie
bh= skrót ciała
b= rzeczywiste dane podpisu
Każda część przyczynia się do sposobu, w jaki podpis jest weryfikowany.
Jak serwer odbierający weryfikuje DKIM?
Pobiera wartości d= i s=.
Sprawdza klucz publiczny na:
selector._domainkey.domain
Regeneruje nagłówki i skróty treści.
Porównuje je z wartościami bh= i b= w e-mailu.
Jeśli pasują, wiadomość przechodzi DKIM.
Co powoduje, że DKIM zawodzi?
Wiadomość zmieniona podczas przesyłu (nawet zmiany w białych znakach, jeśli używana jest surowa kanonizacja)
Niepoprawny lub brakujący klucz publiczny w DNS
Błędy formatowania DNS
Selector usunięty lub niewłaściwie obrócony
Niezgodne tożsamości (i= muszą być tym samym domeną lub subdomeną d=)
Dlaczego problemy z DKIM mogą być trudne do rozwiązywania?
Ponieważ sygnatariusz i walidator działają w zupełnie różnych środowiskach — żadna ze stron nie może odtworzyć warunków haszowania ani stanu podpisu drugiej strony.
To sprawia, że niejasne błędy „hash mismatch” są najtrudniejsze do zdiagnozowania.
Czy awaria DKIM oznacza, że email trafi do spamu?
Niekoniecznie.
DKIM jest tylko jednym sygnałem. Jeśli domena ma silną reputację i przechodzi inne kontrole (SPF, dopasowanie DMARC, niskie wskaźniki skarg), izolowane niepowodzenia DKIM zazwyczaj nie wpływają na umieszczanie wiadomości w skrzynce odbiorczej samodzielnie.
Dlaczego w ogóle używać DKIM?
Chroni integralność wiadomości
Buduje reputację domeny
Umożliwia zgodność z DMARC
Pomaga dostawcom skrzynek pocztowych odróżniać prawdziwych nadawców od oszustów
DKIM jest uważane za najlepszą praktykę dla wszystkich poważnych nadawców e-mail.
Kiedy mówimy o "Email Authentication", odnosimy się do techniki, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość faktycznie pochodzi od rzekomego źródła wiadomości. Idea stojąca za takimi technikami polega na osiągnięciu pewnego poziomu obrony przed oszukańczym e-mailem, takim jak phishing i spoofing, wiadomościami, które mogą podważyć zaufanie odbiorcy do otrzymywania e-maili. To powiedziawszy, akt wysyłania uwierzytelnionego e-maila nie oznacza, że e-mail jest dobry lub pożądany; oznacza tylko, że wiadomość jest taka, że reputacja stron uwierzytelnionych może być rzetelnie ustalona i użyta w decyzjach dotyczących akceptacji i umiejscowienia e-maila.
Obecnie stosowane są dwie formy uwierzytelniania e-mail:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście omówię, czym jest DKIM i jak działa.
Kiedy mówimy o "Email Authentication", odnosimy się do techniki, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość faktycznie pochodzi od rzekomego źródła wiadomości. Idea stojąca za takimi technikami polega na osiągnięciu pewnego poziomu obrony przed oszukańczym e-mailem, takim jak phishing i spoofing, wiadomościami, które mogą podważyć zaufanie odbiorcy do otrzymywania e-maili. To powiedziawszy, akt wysyłania uwierzytelnionego e-maila nie oznacza, że e-mail jest dobry lub pożądany; oznacza tylko, że wiadomość jest taka, że reputacja stron uwierzytelnionych może być rzetelnie ustalona i użyta w decyzjach dotyczących akceptacji i umiejscowienia e-maila.
Obecnie stosowane są dwie formy uwierzytelniania e-mail:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście omówię, czym jest DKIM i jak działa.
Kiedy mówimy o "Email Authentication", odnosimy się do techniki, która zapewnia odbiorcy wiadomości pewien poziom pewności, że wiadomość faktycznie pochodzi od rzekomego źródła wiadomości. Idea stojąca za takimi technikami polega na osiągnięciu pewnego poziomu obrony przed oszukańczym e-mailem, takim jak phishing i spoofing, wiadomościami, które mogą podważyć zaufanie odbiorcy do otrzymywania e-maili. To powiedziawszy, akt wysyłania uwierzytelnionego e-maila nie oznacza, że e-mail jest dobry lub pożądany; oznacza tylko, że wiadomość jest taka, że reputacja stron uwierzytelnionych może być rzetelnie ustalona i użyta w decyzjach dotyczących akceptacji i umiejscowienia e-maila.
Obecnie stosowane są dwie formy uwierzytelniania e-mail:
Sender Policy Framework (SPF)
Domain Keys Identifed Mail (DKIM)
W dzisiejszym poście omówię, czym jest DKIM i jak działa.
DKIM Przegląd
W przeciwieństwie do swojego odpowiednika uwierzytelniania SPF, który zapewnia sposób, aby domena mogła autoryzować hosta do wysyłania poczty w jej imieniu, DKIM oferuje sposób, aby podmiot (domena, organizacja, osoba itd.) mógł wziąć odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie ją wysłał. Chociaż w wielu przypadkach podmiot odpowiedzialny i podmiot wysyłający będą takimi samymi lub przynajmniej blisko spokrewnionymi, z DKIM nie ma wymogu, aby tak było.
Moje cele dla ciebie z tym postem to, abyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie „oparte na treści”, w przeciwieństwie do „opartego na ścieżce” SPF.
Podmiot odpowiedzialny potwierdza swoją odpowiedzialność, „podpisując” wiadomość parą kryptograficznych skrótów wstawionych w nagłówek wiadomości.
Walidacja DKIM jest wykonywana przez domenę odbierającą, próbującą wygenerować te same dwa skróty.
Walidacja DKIM nie może zostać ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Trudności z walidacją mogą być trudne do rozwiązania.
W przeciwieństwie do swojego odpowiednika uwierzytelniania SPF, który zapewnia sposób, aby domena mogła autoryzować hosta do wysyłania poczty w jej imieniu, DKIM oferuje sposób, aby podmiot (domena, organizacja, osoba itd.) mógł wziąć odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie ją wysłał. Chociaż w wielu przypadkach podmiot odpowiedzialny i podmiot wysyłający będą takimi samymi lub przynajmniej blisko spokrewnionymi, z DKIM nie ma wymogu, aby tak było.
Moje cele dla ciebie z tym postem to, abyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie „oparte na treści”, w przeciwieństwie do „opartego na ścieżce” SPF.
Podmiot odpowiedzialny potwierdza swoją odpowiedzialność, „podpisując” wiadomość parą kryptograficznych skrótów wstawionych w nagłówek wiadomości.
Walidacja DKIM jest wykonywana przez domenę odbierającą, próbującą wygenerować te same dwa skróty.
Walidacja DKIM nie może zostać ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Trudności z walidacją mogą być trudne do rozwiązania.
W przeciwieństwie do swojego odpowiednika uwierzytelniania SPF, który zapewnia sposób, aby domena mogła autoryzować hosta do wysyłania poczty w jej imieniu, DKIM oferuje sposób, aby podmiot (domena, organizacja, osoba itd.) mógł wziąć odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie ją wysłał. Chociaż w wielu przypadkach podmiot odpowiedzialny i podmiot wysyłający będą takimi samymi lub przynajmniej blisko spokrewnionymi, z DKIM nie ma wymogu, aby tak było.
Moje cele dla ciebie z tym postem to, abyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie „oparte na treści”, w przeciwieństwie do „opartego na ścieżce” SPF.
Podmiot odpowiedzialny potwierdza swoją odpowiedzialność, „podpisując” wiadomość parą kryptograficznych skrótów wstawionych w nagłówek wiadomości.
Walidacja DKIM jest wykonywana przez domenę odbierającą, próbującą wygenerować te same dwa skróty.
Walidacja DKIM nie może zostać ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Trudności z walidacją mogą być trudne do rozwiązania.
„Content-Based” Uwierzytelnianie
DKIM jest określany jako uwierzytelnianie "oparte na treści", a nie "na ścieżce", ponieważ to, czy wiadomość przechodzi walidację DKIM, zależy wyłącznie od tego, czy zawartość zmieniła się pomiędzy momentem podpisania a próbą walidacji.
DKIM jest określany jako uwierzytelnianie "oparte na treści", a nie "na ścieżce", ponieważ to, czy wiadomość przechodzi walidację DKIM, zależy wyłącznie od tego, czy zawartość zmieniła się pomiędzy momentem podpisania a próbą walidacji.
DKIM jest określany jako uwierzytelnianie "oparte na treści", a nie "na ścieżce", ponieważ to, czy wiadomość przechodzi walidację DKIM, zależy wyłącznie od tego, czy zawartość zmieniła się pomiędzy momentem podpisania a próbą walidacji.
DKIM Podpisywanie i Weryfikacja
Organizacje, które chcą podpisywać pocztę za pomocą DKIM, najpierw wygenerują dwa klucze kryptograficzne. Jeden z kluczy jest przechowywany w tajemnicy i dostępny dla serwera wysyłającego do podpisywania poczty, a drugi ma być publiczny w DNS dla wykorzystania przez domeny odbierające w celu próby weryfikacji podpisu. Metody generowania i instalacji tych kluczy są zależne od platformy i wykraczają poza zakres tego posta, jednak później opiszę publikację w DNS publicznego klucza DKIM.
Organizacje, które chcą podpisywać pocztę za pomocą DKIM, najpierw wygenerują dwa klucze kryptograficzne. Jeden z kluczy jest przechowywany w tajemnicy i dostępny dla serwera wysyłającego do podpisywania poczty, a drugi ma być publiczny w DNS dla wykorzystania przez domeny odbierające w celu próby weryfikacji podpisu. Metody generowania i instalacji tych kluczy są zależne od platformy i wykraczają poza zakres tego posta, jednak później opiszę publikację w DNS publicznego klucza DKIM.
Organizacje, które chcą podpisywać pocztę za pomocą DKIM, najpierw wygenerują dwa klucze kryptograficzne. Jeden z kluczy jest przechowywany w tajemnicy i dostępny dla serwera wysyłającego do podpisywania poczty, a drugi ma być publiczny w DNS dla wykorzystania przez domeny odbierające w celu próby weryfikacji podpisu. Metody generowania i instalacji tych kluczy są zależne od platformy i wykraczają poza zakres tego posta, jednak później opiszę publikację w DNS publicznego klucza DKIM.
Nagłówek DKIM-Signature
Aby rozpocząć nasze zrozumienie DKIM, najpierw przyjrzyjmy się 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ą dla czytelnika głównie przejściowo interesujące:
v=1; – Określa wersję DKIM (1 jest jedyną prawidłową wartością)
a=rsa-sha256; – Algorytm używany do tworzenia kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy reguł dotyczących usuwania odstępów w nagłówkach i treści wiadomości, które można zastosować podczas tworzenia skrótów w sygnaturze DKIM; te reguły nazywają się „zasadami kanonicznymi” (stąd klucz c), a zestawy reguł mogą być „luźne” lub „surowe”.
t=1454417737; – Znacznik czasowy, kiedy sygnatura została utworzona.
Te trzy części nagłówka zawierają faktyczne informacje o sygnaturze:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To skrót treści wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To lista nagłówków, które zostały użyte do stworzenia danych sygnatury pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są rzeczywiste dane sygnatury DKIM
Te trzy części są najbardziej interesujące dla serwera odbierającego, który będzie weryfikować sygnaturę:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selector; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w czyim imieniu została podpisana wiadomość. Syntaktycznie będzie to wyglądać jak adres e-mail i może nawet nim być; lokalna część adresu e-mail może być pusta, tak jak w tym przykładzie, a część domenowa musi być taka sama jak lub poddomena domeny w części d= sygnatury.
Powodem, dla którego te części są interesujące dla serwera odbierającego, jest to, że dostarczają informacji niezbędnych do pomocy odbiorcy w weryfikacji sygnatur.
Pole | Znaczenie | Jak używają tego odbiorcy |
|---|---|---|
v= | Wersja DKIM (zawsze 1) | Potwierdza format sygnatury |
a= | Algorytm haszujący + podpisujący (np. rsa-sha256) | Upewnia się, że walidator odtwarza sygnaturę poprawnie |
c= | Zasady kanoniczne (nagłówek/treść) | Normalizuje odstępy przed haszowaniem |
t= | Znacznik czasowy utworzenia sygnatury | Używany do kontroli świeżości i zapobiegania powtórzeniom |
bh= | Skrót treści | Odbiorca regeneruje to, aby potwierdzić integralność treści wiadomości |
h= | Lista podpisanych pól nagłówka | Upewnia się, że nagłówki używane do podpisu są dostępne i niezmienione |
b= | Rzeczywista sygnatura DKIM | Odbiorca weryfikuje tę sygnaturę z kluczem publicznym |
d= | Domena podpisująca | Używana do zlokalizowania klucza publicznego DNS podpisującego |
s= | Selector | Łączona z domeną, aby utworzyć: selector._domainkey.domain |
i= | Tożsamość podpisująca | Musi być taka sama lub poddomena d=, identyfikuje podmiot podpisujący |
Aby rozpocząć nasze zrozumienie DKIM, najpierw przyjrzyjmy się 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ą dla czytelnika głównie przejściowo interesujące:
v=1; – Określa wersję DKIM (1 jest jedyną prawidłową wartością)
a=rsa-sha256; – Algorytm używany do tworzenia kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy reguł dotyczących usuwania odstępów w nagłówkach i treści wiadomości, które można zastosować podczas tworzenia skrótów w sygnaturze DKIM; te reguły nazywają się „zasadami kanonicznymi” (stąd klucz c), a zestawy reguł mogą być „luźne” lub „surowe”.
t=1454417737; – Znacznik czasowy, kiedy sygnatura została utworzona.
Te trzy części nagłówka zawierają faktyczne informacje o sygnaturze:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To skrót treści wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To lista nagłówków, które zostały użyte do stworzenia danych sygnatury pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są rzeczywiste dane sygnatury DKIM
Te trzy części są najbardziej interesujące dla serwera odbierającego, który będzie weryfikować sygnaturę:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selector; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w czyim imieniu została podpisana wiadomość. Syntaktycznie będzie to wyglądać jak adres e-mail i może nawet nim być; lokalna część adresu e-mail może być pusta, tak jak w tym przykładzie, a część domenowa musi być taka sama jak lub poddomena domeny w części d= sygnatury.
Powodem, dla którego te części są interesujące dla serwera odbierającego, jest to, że dostarczają informacji niezbędnych do pomocy odbiorcy w weryfikacji sygnatur.
Pole | Znaczenie | Jak używają tego odbiorcy |
|---|---|---|
v= | Wersja DKIM (zawsze 1) | Potwierdza format sygnatury |
a= | Algorytm haszujący + podpisujący (np. rsa-sha256) | Upewnia się, że walidator odtwarza sygnaturę poprawnie |
c= | Zasady kanoniczne (nagłówek/treść) | Normalizuje odstępy przed haszowaniem |
t= | Znacznik czasowy utworzenia sygnatury | Używany do kontroli świeżości i zapobiegania powtórzeniom |
bh= | Skrót treści | Odbiorca regeneruje to, aby potwierdzić integralność treści wiadomości |
h= | Lista podpisanych pól nagłówka | Upewnia się, że nagłówki używane do podpisu są dostępne i niezmienione |
b= | Rzeczywista sygnatura DKIM | Odbiorca weryfikuje tę sygnaturę z kluczem publicznym |
d= | Domena podpisująca | Używana do zlokalizowania klucza publicznego DNS podpisującego |
s= | Selector | Łączona z domeną, aby utworzyć: selector._domainkey.domain |
i= | Tożsamość podpisująca | Musi być taka sama lub poddomena d=, identyfikuje podmiot podpisujący |
Aby rozpocząć nasze zrozumienie DKIM, najpierw przyjrzyjmy się 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ą dla czytelnika głównie przejściowo interesujące:
v=1; – Określa wersję DKIM (1 jest jedyną prawidłową wartością)
a=rsa-sha256; – Algorytm używany do tworzenia kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy reguł dotyczących usuwania odstępów w nagłówkach i treści wiadomości, które można zastosować podczas tworzenia skrótów w sygnaturze DKIM; te reguły nazywają się „zasadami kanonicznymi” (stąd klucz c), a zestawy reguł mogą być „luźne” lub „surowe”.
t=1454417737; – Znacznik czasowy, kiedy sygnatura została utworzona.
Te trzy części nagłówka zawierają faktyczne informacje o sygnaturze:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – To skrót treści wiadomości.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – To lista nagłówków, które zostały użyte do stworzenia danych sygnatury pokazanych poniżej.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – To są rzeczywiste dane sygnatury DKIM
Te trzy części są najbardziej interesujące dla serwera odbierającego, który będzie weryfikować sygnaturę:
d=welcome.foo.com; – To identyfikuje domenę, która podpisała wiadomość
s=notices; – Selector; domeny mogą mieć wiele selektorów, które używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w czyim imieniu została podpisana wiadomość. Syntaktycznie będzie to wyglądać jak adres e-mail i może nawet nim być; lokalna część adresu e-mail może być pusta, tak jak w tym przykładzie, a część domenowa musi być taka sama jak lub poddomena domeny w części d= sygnatury.
Powodem, dla którego te części są interesujące dla serwera odbierającego, jest to, że dostarczają informacji niezbędnych do pomocy odbiorcy w weryfikacji sygnatur.
Pole | Znaczenie | Jak używają tego odbiorcy |
|---|---|---|
v= | Wersja DKIM (zawsze 1) | Potwierdza format sygnatury |
a= | Algorytm haszujący + podpisujący (np. rsa-sha256) | Upewnia się, że walidator odtwarza sygnaturę poprawnie |
c= | Zasady kanoniczne (nagłówek/treść) | Normalizuje odstępy przed haszowaniem |
t= | Znacznik czasowy utworzenia sygnatury | Używany do kontroli świeżości i zapobiegania powtórzeniom |
bh= | Skrót treści | Odbiorca regeneruje to, aby potwierdzić integralność treści wiadomości |
h= | Lista podpisanych pól nagłówka | Upewnia się, że nagłówki używane do podpisu są dostępne i niezmienione |
b= | Rzeczywista sygnatura DKIM | Odbiorca weryfikuje tę sygnaturę z kluczem publicznym |
d= | Domena podpisująca | Używana do zlokalizowania klucza publicznego DNS podpisującego |
s= | Selector | Łączona z domeną, aby utworzyć: selector._domainkey.domain |
i= | Tożsamość podpisująca | Musi być taka sama lub poddomena d=, identyfikuje podmiot podpisujący |
DKIM Validation
Oprócz wspomnianego wymagania, że domena i= musi być taka sama jak lub poddomena domeny d=, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM podpisującego w DNS. Klucz jest rekordem TXT w DNS i zawsze znajduje się w lokalizacji selector._domainkey.domain. Tak więc, w naszym przykładzie tutaj, z s=notices i d=welcome.foo.com, publiczny klucz DKIM można znaleźć w DNS pod adresem notices._domainkey.welcome.foo.com, i może wyglądać to 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 (bity p=) do wygenerowania własnego zestawu skrótów wiadomości; jeśli te skróty pasują, wiadomość nie została zmieniona w trakcie przesyłania, a więc wiadomość może przyczynić się do oraz ewentualnie korzystać z istniejącej reputacji nadawcy wiadomości.
Oprócz wspomnianego wymagania, że domena i= musi być taka sama jak lub poddomena domeny d=, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM podpisującego w DNS. Klucz jest rekordem TXT w DNS i zawsze znajduje się w lokalizacji selector._domainkey.domain. Tak więc, w naszym przykładzie tutaj, z s=notices i d=welcome.foo.com, publiczny klucz DKIM można znaleźć w DNS pod adresem notices._domainkey.welcome.foo.com, i może wyglądać to 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 (bity p=) do wygenerowania własnego zestawu skrótów wiadomości; jeśli te skróty pasują, wiadomość nie została zmieniona w trakcie przesyłania, a więc wiadomość może przyczynić się do oraz ewentualnie korzystać z istniejącej reputacji nadawcy wiadomości.
Oprócz wspomnianego wymagania, że domena i= musi być taka sama jak lub poddomena domeny d=, bity d= i s= są używane przez walidator do wyszukiwania publicznego klucza DKIM podpisującego w DNS. Klucz jest rekordem TXT w DNS i zawsze znajduje się w lokalizacji selector._domainkey.domain. Tak więc, w naszym przykładzie tutaj, z s=notices i d=welcome.foo.com, publiczny klucz DKIM można znaleźć w DNS pod adresem notices._domainkey.welcome.foo.com, i może wyglądać to 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 (bity p=) do wygenerowania własnego zestawu skrótów wiadomości; jeśli te skróty pasują, wiadomość nie została zmieniona w trakcie przesyłania, a więc wiadomość może przyczynić się do oraz ewentualnie korzystać z istniejącej reputacji nadawcy wiadomości.
Validation Failure i Rozwiązywanie problemów
Wspomniałem powyżej, że błędy DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre błędy walidacji DKIM mają oczywiste przyczyny, takie jak wiadomość, która nie została podpisana, lub publiczny klucz domeny podpisującej, który nie został znaleziony w DNS lub jest niepoprawny syntaktycznie, lub być może wiadomość została oczywiście zmieniona podczas przesyłania. Kiedy takie błędy się pojawiają, łatwo jest zidentyfikować problem i polecić rozwiązanie. Te trudne, jednak, i te, które prowadzą do najbardziej frustrującego doświadczenia wsparcia, to przypadki, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie została oczywiście zmieniona, ale walidator zgłasza, że podpis nie został zweryfikowany.
Powód, dla którego te są trudne do rozwiązania, polega na tym, że nie ma realnego sposobu, aby którakolwiek ze stron odtworzyła warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość ma w 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 i dlatego nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora i dlatego nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Błędy, jak te, które tutaj opisuję, są rzadkimi przypadkami, a błędy walidacji DKIM same w sobie zwykle nie mają wpływu na umieszczenie w dostawie. Podczas gdy DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik walidacji email zapewnia, że wysyłasz na legalne adresy, które mogą faktycznie odbierać i uwierzytelniać twoje wiadomości. Z mojego doświadczenia wynika, że takie błędy generują więcej zgłoszeń wsparcia niż jakiekolwiek inne rodzaje problemów DKIM.
Wspomniałem powyżej, że błędy DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre błędy walidacji DKIM mają oczywiste przyczyny, takie jak wiadomość, która nie została podpisana, lub publiczny klucz domeny podpisującej, który nie został znaleziony w DNS lub jest niepoprawny syntaktycznie, lub być może wiadomość została oczywiście zmieniona podczas przesyłania. Kiedy takie błędy się pojawiają, łatwo jest zidentyfikować problem i polecić rozwiązanie. Te trudne, jednak, i te, które prowadzą do najbardziej frustrującego doświadczenia wsparcia, to przypadki, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie została oczywiście zmieniona, ale walidator zgłasza, że podpis nie został zweryfikowany.
Powód, dla którego te są trudne do rozwiązania, polega na tym, że nie ma realnego sposobu, aby którakolwiek ze stron odtworzyła warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość ma w 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 i dlatego nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora i dlatego nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Błędy, jak te, które tutaj opisuję, są rzadkimi przypadkami, a błędy walidacji DKIM same w sobie zwykle nie mają wpływu na umieszczenie w dostawie. Podczas gdy DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik walidacji email zapewnia, że wysyłasz na legalne adresy, które mogą faktycznie odbierać i uwierzytelniać twoje wiadomości. Z mojego doświadczenia wynika, że takie błędy generują więcej zgłoszeń wsparcia niż jakiekolwiek inne rodzaje problemów DKIM.
Wspomniałem powyżej, że błędy DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre błędy walidacji DKIM mają oczywiste przyczyny, takie jak wiadomość, która nie została podpisana, lub publiczny klucz domeny podpisującej, który nie został znaleziony w DNS lub jest niepoprawny syntaktycznie, lub być może wiadomość została oczywiście zmieniona podczas przesyłania. Kiedy takie błędy się pojawiają, łatwo jest zidentyfikować problem i polecić rozwiązanie. Te trudne, jednak, i te, które prowadzą do najbardziej frustrującego doświadczenia wsparcia, to przypadki, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie została oczywiście zmieniona, ale walidator zgłasza, że podpis nie został zweryfikowany.
Powód, dla którego te są trudne do rozwiązania, polega na tym, że nie ma realnego sposobu, aby którakolwiek ze stron odtworzyła warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość ma w 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 i dlatego nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora i dlatego nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Błędy, jak te, które tutaj opisuję, są rzadkimi przypadkami, a błędy walidacji DKIM same w sobie zwykle nie mają wpływu na umieszczenie w dostawie. Podczas gdy DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik walidacji email zapewnia, że wysyłasz na legalne adresy, które mogą faktycznie odbierać i uwierzytelniać twoje wiadomości. Z mojego doświadczenia wynika, że takie błędy generują więcej zgłoszeń wsparcia niż jakiekolwiek inne rodzaje problemów DKIM.
