Wiadomość z kilkoma DKIM podpisów wymaga oceny dla każdego podpisu. Liczenie podpisów lub wybranie pierwszego pozytywnego wyniku może spowodować błędną identyfikację domeny, która uwierzytelniła widocznego autora. Pod RFC 9989 §4.4.1, każdy przechodzący identyfikator uwierzytelniony DKIM, który jest zgodny z domeną autora, może dostarczyć ścieżkę DKIM do DMARC przechodzić.
Zachowaj tożsamość każdego wyniku
Eksportuj surową wiadomość w zatwierdzonym procesie. Zapisz widoczną domenę From i dla każdego podpisu jej nazwę d= podpisywanie domeny, s= selektor, a= algorytm i istotne kanonizacja ustawienia. Powiąż wynik zaufanego systemu odbierającego z tym podpisem. Dwa podpisy mogą korzystać z tej samej domeny, ale różnych selektorów lub algorytmów, więc sama domena może ich nie rozróżnić.
Nie ufaj arbitralnie Authentication-Results pole tylko dlatego, że pojawia się w wiadomości. RFC 8601 §1.2 wyjaśnia granicę zaufania dla tych pól. Wykorzystaj wyniki, które można przypisać systemowi otrzymującemu, którego ocenę badasz, i zachowaj to źródło podczas eksportowania dowodów. Nadawca może wstawić wprowadzający w błąd tekst nagłówka; skopiowana etykieta statusu nie stanowi niezależnej weryfikacji.
Zachowaj weryfikację i dostosowanie jako osobne decyzje
Weryfikacja sprawdza, czy podpis sprawdza poprawność domeny podpisującej. Wyrównanie porównuje tę uwierzytelnioną domenę z domeną autora zgodnie z obowiązującą regułą DMARC . Podpis niepowiązanego dostawcy może być całkowicie ważny bez uwierzytelniania widocznej domeny autora dla DMARC .
Aby zapewnić ścisłe dopasowanie DKIM , domeny muszą być dokładnie zgodne, a następnie porównaj wielkość liter w nazwach domen RFC 1035 §2.3.3. Zrelaksowane dostosowanie wykorzystuje relację organizacja-domena zgodnie z odpowiednim procesem DMARC . RFC 9989 §4.10.2 definiuje spacery po drzewie DNS dla tego ustalenia. Nie decyduj o dopasowaniu na podstawie wspólnego słowa w dwóch nazwach domen i nie zakładaj po cichu, że każdy odbiorca przyjął najnowszą implementację wykrywania.
Pracuj nad syntetycznym przekazem
Załóżmy, że obowiązuje ważna polityka DMARC , domena autora example.com i nie jest wyrównany SPF przechodzić. Podpis A używa d=example.net, weryfikuje się pomyślnie i nie wyrównuje. Podpis B wykorzystuje d=example.com ale nie przechodzi weryfikacji po zmianie treści na dalszym etapie. Żadne z nich nie zapewnia wyrównanej przechodzącej tożsamości DKIM , więc ta kombinacja nie tworzy przepustki DMARC .
Teraz dodaj podpis C za pomocą d=example.com co weryfikuje pomyślnie. Wyrównuje się dokładnie, więc dostarcza ścieżkę DKIM do przepustki DMARC . Niepowiązane podanie i nieudany podpis nie anulują automatycznie C. Jest to ocena ilustracyjna, a nie twierdzenie dotyczące przechwyconej wiadomości klienta lub gwarantowanego umieszczenia w skrzynce pocztowej.
Zapisz przykład w oddzielnych kolumnach w swoim zapisie dochodzenia: identyfikator podpisu, wynik weryfikacji, wynik dostosowania i wkład do DMARC . Nigdy nie łącz przepustki podpisu A z dopasowaną domeną podpisu B, aby uzyskać wynik, w którym nie można uzyskać indywidualnego podpisu.
Wyjaśnij, dlaczego istnieje wiele podpisów
Algorytmy równoległe, podpis operacyjny dostawcy i późniejszy podpis pośrednika mogą dawać wiele wyników. Są to hipotezy, dopóki trasa i konfiguracja podpisującego nie ustalą przyczyny. RFC 8463 §6 opisuje różne selektory dla RSA i Ed25519 podpisy przejściowe; ich wyniki należy śledzić indywidualnie.
Jeśli brama ponownie podpisuje zmodyfikowaną pocztę, sprawdź jej nową domenę. Przechodzący podpis bramy nie naprawia automatycznie uwierzytelnienia oryginalnego autora. Jeżeli organizacja kontroluje końcowy etap podpisywania, sprawdź, czy podpisuje treść zamierzoną po przetworzeniu pod zatwierdzoną tożsamością. Nie usuwaj pozornie zbędnego podpisu bez sprawdzenia jego przeznaczenia operacyjnego.
Zakończ wnioskiem na poziomie komunikatu
Po ocenie wszystkich odpowiednich podpisów DKIM należy osobno ocenić uwierzytelniony identyfikator i dopasowanie SPF . Jeśli nie zostaną wykryte żadne obowiązujące zasady DMARC , nie oznaczaj ponownie sytuacji jako normalnej awarii DMARC . Odróżnij wyniki uwierzytelniania od ostatecznej dyspozycji odbiorcy, która może odzwierciedlać dodatkowe zasady lub filtrowanie.
Zachowaj oryginalną wiadomość, zaufane źródło wyników, analizę poszczególnych podpisów i powód ostatecznego wniosku. Jeśli narzędzia do raportowania agregują podpisy w różny sposób, porównaj ich surowe dowody, zanim potraktujesz różne podsumowania jako sprzeczność protokołu. Przydatnym rezultatem jest możliwa do wyjaśnienia ścieżka tożsamości, a nie tylko większa liczba zielonych wskaźników.
Zapisz przykład bez mieszania tożsamości
W przypadku powyższej wiadomości syntetycznej zachowaj po jednym wierszu na podpis:
- O: example.net ; przepustka weryfikacyjna; ustawienie nr; Wpłata DKIM do DMARC nr.
- B: example.com ; weryfikacja nie powiodła się; domena byłaby zgodna, ale nie została uwierzytelniona; wkład DKIM nr.
- C: example.com ; przepustka weryfikacyjna; wyrównanie tak; Wkład DKIM tak.
Przed obecnością C stwierdzony brak wyrównanego SPF nie pozostawia żadnej ścieżki przejścia. Przy obecności C DMARC przechodzi zgodnie z założoną obowiązującą polityką. Nie zgłasza się żadnych rzeczywistych wyników odbiorców ani wyników umieszczania w skrzynce odbiorczej.
Powiązane lektury
Dopasowanie DKIM : porównaj d= z widoczną domeną From · Podpisy RSA i Ed25519 DKIM : pytania dotyczące wdrażania i interoperacyjność.