Walidacja DKIM: Najlepsza praktyka uwierzytelniania e-maili
·
8 kwi 2017
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:
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.
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.
„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.
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.
Nagłówek DKIM-Signature
Weryfikacja DKIM
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.
