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.
Przegląd DKIM
W przeciwieństwie do swojego odpowiednika autoryzacyjnego SPF, który zapewnia sposób, aby domena autoryzowała hosta do wysłania poczty w jego imieniu, DKIM zapewnia sposób, aby podmiot (domena, organizacja, osoba, itp.) wziął odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i wysyłający podmiot będą tym samym lub przynajmniej ściśle powiązanym, z DKIM nie ma obowiązku, aby tak było.
Moje cele dla ciebie z tym postem są takie, żebyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie oparte na „zawartości”, w przeciwieństwie do SPF opartego na „ścieżce”.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność poprzez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Walidacja DKIM odbywa się przez domenę odbierającą, która próbuje wygenerować te same dwa skróty.
Walidacja DKIM nie może być ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Niepowodzenia walidacji mogą być trudne do rozwiązywania.
W przeciwieństwie do swojego odpowiednika autoryzacyjnego SPF, który zapewnia sposób, aby domena autoryzowała hosta do wysłania poczty w jego imieniu, DKIM zapewnia sposób, aby podmiot (domena, organizacja, osoba, itp.) wziął odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i wysyłający podmiot będą tym samym lub przynajmniej ściśle powiązanym, z DKIM nie ma obowiązku, aby tak było.
Moje cele dla ciebie z tym postem są takie, żebyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie oparte na „zawartości”, w przeciwieństwie do SPF opartego na „ścieżce”.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność poprzez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Walidacja DKIM odbywa się przez domenę odbierającą, która próbuje wygenerować te same dwa skróty.
Walidacja DKIM nie może być ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Niepowodzenia walidacji mogą być trudne do rozwiązywania.
W przeciwieństwie do swojego odpowiednika autoryzacyjnego SPF, który zapewnia sposób, aby domena autoryzowała hosta do wysłania poczty w jego imieniu, DKIM zapewnia sposób, aby podmiot (domena, organizacja, osoba, itp.) wziął odpowiedzialność za wiadomość, niezależnie od podmiotu, który faktycznie wysłał wiadomość. Chociaż w wielu przypadkach odpowiedzialny podmiot i wysyłający podmiot będą tym samym lub przynajmniej ściśle powiązanym, z DKIM nie ma obowiązku, aby tak było.
Moje cele dla ciebie z tym postem są takie, żebyś nauczył się i zrozumiał następujące pojęcia dotyczące DKIM:
DKIM to uwierzytelnianie oparte na „zawartości”, w przeciwieństwie do SPF opartego na „ścieżce”.
Odpowiedzialny podmiot potwierdza swoją odpowiedzialność poprzez „podpisanie” wiadomości parą kryptograficznych skrótów umieszczonych w nagłówku wiadomości.
Walidacja DKIM odbywa się przez domenę odbierającą, która próbuje wygenerować te same dwa skróty.
Walidacja DKIM nie może być ukończona w wielu przypadkach, dopóki pełna wiadomość nie zostanie przesłana przez serwer wysyłający.
Niepowodzenia walidacji mogą być trudne do rozwiązywania.
„Content-Based” Authentication
DKIM jest określany jako uwierzytelnianie „oparte na treści”, a nie „oparte na ścieżce”, ponieważ to, czy wiadomość przejdzie walidację DKIM, zależy wyłącznie od tego, czy treść zmieniła się pomiędzy momentem podpisania a momentem, w którym próbowano przeprowadzić walidację.
DKIM jest określany jako uwierzytelnianie „oparte na treści”, a nie „oparte na ścieżce”, ponieważ to, czy wiadomość przejdzie walidację DKIM, zależy wyłącznie od tego, czy treść zmieniła się pomiędzy momentem podpisania a momentem, w którym próbowano przeprowadzić walidację.
DKIM jest określany jako uwierzytelnianie „oparte na treści”, a nie „oparte na ścieżce”, ponieważ to, czy wiadomość przejdzie walidację DKIM, zależy wyłącznie od tego, czy treść zmieniła się pomiędzy momentem podpisania a momentem, w którym próbowano przeprowadzić walidację.
Podpisywanie i walidacja 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 należy upublicznić w DNS do użytku przez domeny odbierające w celu weryfikacji podpisu. Metody generowania tych kluczy i ich instalacji są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację publicznego klucza DKIM w DNS.
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 należy upublicznić w DNS do użytku przez domeny odbierające w celu weryfikacji podpisu. Metody generowania tych kluczy i ich instalacji są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację publicznego klucza DKIM w DNS.
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 należy upublicznić w DNS do użytku przez domeny odbierające w celu weryfikacji podpisu. Metody generowania tych kluczy i ich instalacji są zależne od platformy i wykraczają poza zakres tego wpisu, chociaż później opiszę publikację publicznego klucza DKIM w DNS.
Nagłówek DKIM-Signature
Aby rozpocząć 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ść, które mogą być bardziej intersujące dla czytelnika niż inne, ale opiszę wszystkie tutaj.
Najpierw przyjrzymy się tym, które są zazwyczaj mniej interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna prawidłowa wartość)
a=rsa-sha256; – Algorytm używany do tworzenia kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy zasad 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 zasady nazywają się „zasadami kanoniczności” (stąd klucz c), a zestawy zasad to albo „relaxed” albo „strict”.
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 użytych 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; – Identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, których używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w imieniu której wiadomość została podpisana. Syntaktycznie będzie wyglądać jak adres e-mail, i może nawet nim być; lokalna część adresu e-mail może być pusta, jak w tym przykładzie, a część domenowa musi być taka sama jak w części d= podpisu lub być subdomeną tej domeny.
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 podpisów.
Aby rozpocząć 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ść, które mogą być bardziej intersujące dla czytelnika niż inne, ale opiszę wszystkie tutaj.
Najpierw przyjrzymy się tym, które są zazwyczaj mniej interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna prawidłowa wartość)
a=rsa-sha256; – Algorytm używany do tworzenia kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy zasad 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 zasady nazywają się „zasadami kanoniczności” (stąd klucz c), a zestawy zasad to albo „relaxed” albo „strict”.
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 użytych 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; – Identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, których używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w imieniu której wiadomość została podpisana. Syntaktycznie będzie wyglądać jak adres e-mail, i może nawet nim być; lokalna część adresu e-mail może być pusta, jak w tym przykładzie, a część domenowa musi być taka sama jak w części d= podpisu lub być subdomeną tej domeny.
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 podpisów.
Aby rozpocząć 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ść, które mogą być bardziej intersujące dla czytelnika niż inne, ale opiszę wszystkie tutaj.
Najpierw przyjrzymy się tym, które są zazwyczaj mniej interesujące dla czytelnika:
v=1; – Określa wersję DKIM (1 to jedyna prawidłowa wartość)
a=rsa-sha256; – Algorytm używany do tworzenia kryptograficznych skrótów
c=relaxed/relaxed; – Istnieją dwa zestawy zasad 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 zasady nazywają się „zasadami kanoniczności” (stąd klucz c), a zestawy zasad to albo „relaxed” albo „strict”.
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 użytych 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; – Identyfikuje domenę, która podpisała wiadomość
s=notices; – Selektor; domeny mogą mieć wiele selektorów, których używają podczas podpisywania wiadomości.
i=@welcome.foo.com; – To jest tożsamość, w imieniu której wiadomość została podpisana. Syntaktycznie będzie wyglądać jak adres e-mail, i może nawet nim być; lokalna część adresu e-mail może być pusta, jak w tym przykładzie, a część domenowa musi być taka sama jak w części d= podpisu lub być subdomeną tej domeny.
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 podpisów.
DKIM Validation
Oprócz wymogu, że domena i= musi być taka sama jak domena d= lub jej subdomena, 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ę pod adresem selector._domainkey.domain. Tak więc w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM znajdowałby się w DNS pod adresem notices._domainkey.welcome.foo.com i może wyglądać 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 generowania własnych zestawów skrótów z wiadomości; jeśli te skróty się zgadzają, oznacza to, że wiadomość nie została zmieniona podczas przesyłania i w ten sposób wiadomość może przyczynić się do reputacji podpisującego wiadomość, a nawet z niej skorzystać.
Oprócz wymogu, że domena i= musi być taka sama jak domena d= lub jej subdomena, 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ę pod adresem selector._domainkey.domain. Tak więc w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM znajdowałby się w DNS pod adresem notices._domainkey.welcome.foo.com i może wyglądać 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 generowania własnych zestawów skrótów z wiadomości; jeśli te skróty się zgadzają, oznacza to, że wiadomość nie została zmieniona podczas przesyłania i w ten sposób wiadomość może przyczynić się do reputacji podpisującego wiadomość, a nawet z niej skorzystać.
Oprócz wymogu, że domena i= musi być taka sama jak domena d= lub jej subdomena, 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ę pod adresem selector._domainkey.domain. Tak więc w naszym przykładzie, z s=notices i d=welcome.foo.com, publiczny klucz DKIM znajdowałby się w DNS pod adresem notices._domainkey.welcome.foo.com i może wyglądać 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 generowania własnych zestawów skrótów z wiadomości; jeśli te skróty się zgadzają, oznacza to, że wiadomość nie została zmieniona podczas przesyłania i w ten sposób wiadomość może przyczynić się do reputacji podpisującego wiadomość, a nawet z niej skorzystać.
Błąd walidacji i rozwiązywanie problemów
Wspomniałem wcześniej, że niepowodzenia DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre niepowodzenia w walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak odnalezienia klucza publicznego domeny podpisującej w DNS lub brak poprawności składniowej, lub być może wiadomość została wyraźnie zmieniona podczas przesyłania. Gdy mają miejsce takie rodzaje niepowodzeń, łatwo jest zidentyfikować problem i zarekomendować rozwiązanie. Jednakże te trudne przypadki i te, które prowadzą do najbardziej frustrujących doświadczeń wsparcia, to sytuacje, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie była wyraźnie zmieniona, lecz walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego są one trudne do rozstrzygnięcia, jest to, że nie ma rzeczywistego sposobu dla żadnej ze stron, aby odtworzyć warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość zawiera 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, a zatem nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora, a więc nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Niepowodzenia, które tutaj opisuję, zdarzają się rzadko, a same niepowodzenia w walidacji DKIM zazwyczaj nie mają wpływu na umiejscowienie dostarczenia. Chociaż DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik weryfikacji emaili zapewnia wysyłanie na prawdziwe adresy, które rzeczywiście mogą odbierać i uwierzytelniać wiadomości. Z mojego doświadczenia wynika, że takie niepowodzenia generują więcej zgłoszeń wsparcia niż jakiejkolwiek inne problemy związane z DKIM.
Wspomniałem wcześniej, że niepowodzenia DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre niepowodzenia w walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak odnalezienia klucza publicznego domeny podpisującej w DNS lub brak poprawności składniowej, lub być może wiadomość została wyraźnie zmieniona podczas przesyłania. Gdy mają miejsce takie rodzaje niepowodzeń, łatwo jest zidentyfikować problem i zarekomendować rozwiązanie. Jednakże te trudne przypadki i te, które prowadzą do najbardziej frustrujących doświadczeń wsparcia, to sytuacje, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie była wyraźnie zmieniona, lecz walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego są one trudne do rozstrzygnięcia, jest to, że nie ma rzeczywistego sposobu dla żadnej ze stron, aby odtworzyć warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość zawiera 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, a zatem nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora, a więc nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Niepowodzenia, które tutaj opisuję, zdarzają się rzadko, a same niepowodzenia w walidacji DKIM zazwyczaj nie mają wpływu na umiejscowienie dostarczenia. Chociaż DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik weryfikacji emaili zapewnia wysyłanie na prawdziwe adresy, które rzeczywiście mogą odbierać i uwierzytelniać wiadomości. Z mojego doświadczenia wynika, że takie niepowodzenia generują więcej zgłoszeń wsparcia niż jakiejkolwiek inne problemy związane z DKIM.
Wspomniałem wcześniej, że niepowodzenia DKIM mogą być trudne do rozwiązania, i wyjaśnię tutaj, dlaczego tak jest.
Niektóre niepowodzenia w walidacji DKIM mają oczywiste przyczyny, takie jak brak podpisania wiadomości, brak odnalezienia klucza publicznego domeny podpisującej w DNS lub brak poprawności składniowej, lub być może wiadomość została wyraźnie zmieniona podczas przesyłania. Gdy mają miejsce takie rodzaje niepowodzeń, łatwo jest zidentyfikować problem i zarekomendować rozwiązanie. Jednakże te trudne przypadki i te, które prowadzą do najbardziej frustrujących doświadczeń wsparcia, to sytuacje, w których wiadomość została podpisana, klucz publiczny istnieje w DNS, a wiadomość nie była wyraźnie zmieniona, lecz walidator zgłasza, że podpis nie przeszedł walidacji.
Powodem, dla którego są one trudne do rozstrzygnięcia, jest to, że nie ma rzeczywistego sposobu dla żadnej ze stron, aby odtworzyć warunki, w jakich wiadomość została podpisana i zweryfikowana. Wiadomość zawiera 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, a zatem nie może spróbować odtworzyć podpisu w warunkach podpisującego. Podobnie, podpisujący prawdopodobnie nie ma dostępu do infrastruktury walidatora, a więc nie ma sposobu, aby spróbować zweryfikować wiadomość w sposób, w jaki zrobił to walidator.
Niepowodzenia, które tutaj opisuję, zdarzają się rzadko, a same niepowodzenia w walidacji DKIM zazwyczaj nie mają wpływu na umiejscowienie dostarczenia. Chociaż DKIM zajmuje się uwierzytelnianiem wiadomości, wdrożenie kompleksowych technik weryfikacji emaili zapewnia wysyłanie na prawdziwe adresy, które rzeczywiście mogą odbierać i uwierzytelniać wiadomości. Z mojego doświadczenia wynika, że takie niepowodzenia generują więcej zgłoszeń wsparcia niż jakiejkolwiek inne problemy związane z DKIM.
