Podpisana wiadomość nadal może być spamem. Domena podpisująca może też różnić się od adresu wyświetlanego odbiorcy.
Co obejmuje podpis DKIM?
Podpis DKIM chroni wybrane pola nagłówków i hash treści wiadomości.
Tag h= wymienia podpisane pola nagłówków. Tag bh= zawiera hash treści. Serwer wysyłający tworzy podpis swoim kluczem prywatnym. Odbiorcy weryfikują go odpowiadającym mu kluczem publicznym.
Odbiorca ponownie oblicza hash treści. Weryfikuje też podpis na wybranych nagłówkach i nagłówku podpisu, który zawiera ten hash.
RFC 6376 wymaga podpisania nagłówka From. Inne pola nagłówków mogą pozostać niepodpisane. Dodanie niepodpisanego Reply-To może więc nie unieważnić DKIM.
Powtarzające się nagłówki wymagają osobnego potraktowania. Podpisujący może wymienić nazwę nagłówka więcej razy, niż ona występuje, aby zapobiec niezauważonemu dodaniu kolejnego wystąpienia.
Gdzie odbiorca znajduje klucz publiczny?
Odbiorca lokalizuje klucz publiczny na podstawie domeny podpisującej i selektora, czyli nazwy identyfikującej ten klucz. Tag d= podaje domenę. Tag s= podaje selektor.
Dla d=example.com i s=foo.bar nazwa wyszukiwania to foo.bar._domainkey.example.com. Selektor pozwala używać różnych kluczy w tej samej domenie podpisującej.
Podczas rotacji opublikuj nowy klucz, zanim zaczniesz nim podpisywać. Pozostaw stary klucz weryfikacyjny dostępny, dopóki wiadomości nim podpisane są jeszcze w drodze. Przedwczesne usunięcie go uniemożliwia odbiorcom weryfikację tych wiadomości.
Dlaczego zmiany formatowania mogą złamać podpis?
Kanonizacja, czyli normalizacja stosowana przed podpisywaniem i weryfikacją, określa, które zmiany formatowania DKIM toleruje.
Tag c= wybiera osobne algorytmy dla nagłówków i treści. W relaxed/relaxed oba używają normalizacji relaxed.
| Algorytm | Zachowanie nagłówków | Zachowanie treści |
|---|---|---|
simple | Zachowuje formatowanie nagłówków | Ignoruje puste wiersze na końcu |
relaxed | Normalizuje wielkość liter, zawijanie i białe znaki | Normalizuje białe znaki i końcowe puste wiersze |
Zawinięty nagłówek jest kontynuowany w kolejnym wierszu. Przetwarzanie relaxed toleruje takie zawijanie. Przetwarzanie simple może zakończyć się błędem, gdy serwer ponownie zawinie ten sam nagłówek.
Porównaj podpisaną treść przed i po przekaźniku powodującym błąd, ponieważ niewidoczna zmiana formatowania może wyjaśnić wynik.
Jakie algorytmy podpisywania obsługuje DKIM?
DKIM obsługuje algorytmy podpisywania RSA i Ed25519, oba w połączeniu z SHA-256.
Minimalny rozmiar klucza RSA to 1024 bity zgodnie z RFC 8301. Krótsze klucze nie zapewniają wystarczającej odporności na kompromitację klucza.
Zalecany rozmiar klucza RSA to co najmniej 2048 bitów, co zapewnia większą odporność na kompromitację klucza. Wybierz ten rozmiar, jeśli twój system podpisywania go obsługuje. Specyfikacja zabrania używania rsa-sha1 do podpisywania i weryfikacji.
RFC 8463 dodaje ed25519-sha256. Wiadomość może zawierać zarówno podpisy RSA, jak i Ed25519, aby zapewnić kompatybilność z odbiorcami obsługującymi różne algorytmy.
Wytyczne Yahoo również wymagają minimalnie 1024-bitowego klucza DKIM.
Co się dzieje, gdy lista mailingowa edytuje wiadomość?
Edycja może unieważnić DKIM, jeśli zmienia treść objętą podpisem.
Samo przekazywanie nie zmienia podpisanej treści. Nienaruszony podpis może je przetrwać. Dołączona stopka może zmienić hash treści. Przepisany podpisany nagłówek Subject może unieważnić podpis nagłówka.
Opcjonalny tag l= ogranicza ochronę treści do określonej liczby bajtów. Przy l=100 treść po pierwszych 100 znormalizowanych bajtach jest niechroniona. Dopisanie wprowadzającego w błąd tekstu może więc nie unieważnić podpisu.
Unikaj tego limitu, gdy potrzebujesz ochrony całej treści. ARC pozwala pośrednikom zachować podpisane dowody uwierzytelnienia sprzed ich edycji.
Jak skonfigurować DKIM z Bird?
Opublikuj rekord DKIM zwrócony podczas rejestracji domeny wysyłającej.
Pole dkim.mode w API domyślnie ma wartość txt. W tym trybie opublikuj klucz publiczny w rekordzie TXT. Schemat wymienia też delegated. Ta wartość zwraca HTTP 422 podczas rejestracji domeny wysyłającej, więc użyj txt.
Bird tworzy osobny klucz i selektor dla każdej organizacji korzystającej z domeny wysyłającej. Organizacje używające tej samej domeny nie muszą współdzielić klucza podpisującego.
Przewodnik po uwierzytelnianiu wyjaśnia zwrócony rekord.
Czy pozytywna weryfikacja podpisu dowodzi, że wiadomość jest bezpieczna?
Pozytywna weryfikacja podpisu potwierdza odpowiedzialność za podpisaną treść. Nie potwierdza, czy wiadomość jest pożądana lub godna zaufania.
Nie wymaga też, aby domena podpisująca była zgodna z widoczną domeną From. DMARC zapewnia tę regułę dopasowania przez alignment. Reputacja nadawcy, czyli ocena ruchu nadawcy przez odbiorcę, pozostaje odrębnym czynnikiem.
W skrócie
Chroniona jest tylko wybrana treść.
DKIM obejmuje wymienione pola nagłówków i hash treści. Niechroniona treść może się zmienić bez unieważnienia podpisu.
Selektory wskazują klucze weryfikacyjne.
Selektor i domena podpisująca identyfikują rekord DNS zawierający klucz publiczny.
Normalizacja wpływa na weryfikację.
Algorytmy simple i relaxed traktują zmiany formatowania w różny sposób.
Przekazywanie nie gwarantuje pozytywnej weryfikacji.
Nienaruszony podpis może przetrwać przekazywanie, ale zmiany w podpisanej treści mogą go złamać.