Wynik dkim=none nie jest kolejną pisownią uszkodzonego podpisu. RFC 8601 §2.7.1 definiuje DKIM brak powoduje, że wiadomość nie jest podpisana. To rozróżnienie zmienia sposób dochodzenia: niepodpisana wiadomość wymaga sprawdzenia ścieżki podpisu, natomiast podpisana wiadomość, która zakończy się niepowodzeniem, wymaga weryfikacji.
Zacznij od potwierdzenia, do czego należy wynik i kto go dostarczył. Podsumowanie narzędzia, an Authentication-Results pole, a surowy komunikat może opisywać różne obserwacje. Ufaj wynikowi tylko w granicach zweryfikowanego odbiorcy i zachowaj oryginalną wiadomość przed próbą pogodzenia pozornych sprzeczności.
Przeczytaj pełne pole wynikowe
W Authentication-Results dkim=none jest wynikiem metody DKIM . Oddzielny formularz składający się z identyfikatora usługi uwierzytelniania, po którym następuje pusty brak, oznacza, że nie przeprowadzono żadnego uwierzytelnienia wiadomości. Formy te nie są zamienne; Widzieć RFC 8601 §2.2. Brakujące Authentication-Results również nie są dowodem na to, że wiadomość nie była podpisana; nagłówek mógł nie zostać dodany lub zachowany.
Przeczytaj identyfikator authserv i dowiedz się, jaki system identyfikuje. Wiadomość może zawierać wyniki z kilku przeskoków, w tym niezaufany tekst wstawiony przed dostarczeniem. RFC 8601 §7.1 opisuje obsługę granic zaufania, ponieważ osoba atakująca może napisać przekonująco wyglądające pole wynikowe. Ciąg znaków Pass lub none ma znaczenie tylko wtedy, gdy zostanie ustalone jego pochodzenie i kontekst oceny.
Sprawdź dowód podpisu
Szukać DKIM-Signature pola w zachowanej wiadomości surowej. Jeśli nie ma żadnego, a zaufany odbiorca zgłasza dkim=none, sprawdź, czy nadawca włączył podpisywanie na tej trasie. Sprawdź aplikację SMTP , złącza przekaźnikowe i pocztę generowaną przez API niezależnie od zwykłej poczty w skrzynce pocztowej.
Jeśli podpis jest obecny, ale wynik nic nie mówi, nie oskarżaj odbiorcy od razu o błąd. Późniejszy przeskok mógł dodać podpis lub dostępna próbka może różnić się od wiadomości ocenionej przez tego odbiorcę. Ustal, gdzie każdy wynik i podpis weszły na ścieżkę. Interpretacja zależy od granicy obserwacji, a nie tylko od ostatecznej listy nagłówków.
Oddziel trzy praktyczne przypadki
Przypadek pierwszy: na granicy zaufanej oceny nie istnieje żaden podpis. Następną czynnością jest potwierdzenie obsługiwanej konfiguracji i trasy podpisywania. Opublikowanie kolejnego klucza publicznego nie powoduje znaku usługi.
Przypadek drugi: podpis istnieje, ale brakuje odpowiedniego klucza. RFC 6376 §6.1.2 traktuje to jako niepowodzenie weryfikacji bez klucza, a nie niepodpisaną wiadomość. Uzyskaj wyszukiwanie na podstawie wartości d i s podpisu i sprawdź publikację DNS lub wycofanie.
Przypadek trzeci: klucz zostaje odzyskany, ale objęta treść nie jest weryfikowana. Zbadaj reprezentację treści, podpisane nagłówki, materiał klucza, uszkodzone wartości podpisu i wady osoby podpisującej/weryfikatora; sama awaria nie pozwala ustalić, które wejście uległo zmianie. Nienaruszone pole DKIM-Signature nie oznacza, że podpis został przyjęty. Przypadki te stanowią ramy diagnostyczne, a nie zestaw wyników testów na żywo.
Trzymaj DMARC oddzielnie od etykiety
Pod obowiązującym DMARC zasad, niepodpisana wiadomość może nadal przejść przez przejście wyrównane SPF pod RFC 9989 §5.3.5. I odwrotnie, przechodzący podpis DKIM w niepowiązanej domenie może nie dostarczyć DMARC wyrównanie. Zapisz domenę From, tożsamość i wynik SPF , każdą tożsamość i wynik DKIM oraz wyrównanie jako odrębne obserwacje.
Nie wnioskuj o dostawie lub bezpieczeństwie na podstawie niczego. Odbiorcy stosują własne filtrowanie, a DKIM stanowi raczej jedno z danych wejściowych niż dowód, że wiadomość jest nieszkodliwa. Pytanie operacyjne brzmi, czy oczekiwana ścieżka autoryzowanego wysyłania ma zamierzony zakres uwierzytelnienia.
Udowodnij naprawę podpisu
Jeśli trasa powinna się podpisać, skorzystaj z obsługiwanej konfiguracji dostawcy i przetestuj nowe wiadomości po zmianie. Sprawdź, czy zamierzona domena d i selektor wygląda na to, że podpis przechodzi do zaufanego odbiorcy i że jest zgodny z wymaganiami. Uwzględnij rzeczywisty format firmy i trasę, a nie przycisk testowy innej usługi.
Zachowaj dowody przed i po za pomocą znaczników czasu i opisu trasy. Zamknij problem z powodu braku podpisu na nazwanej ścieżce, braku materiałów weryfikacyjnych lub niepowodzenia weryfikacji integralności, stosownie do przypadku. Dokładna klasyfikacja daje następnemu zdarzeniu przydatny punkt wyjścia.
Dowody potrzebne do podjęcia kolejnej decyzji
Dla ilustracji Authentication-Results: mx.example; dkim=none zgłasza niepodpisaną pocztę dla tej metody, podczas gdy Authentication-Results : mx.example ; nic mówi, że nie wykonano żadnych schematów uwierzytelniania. Żaden ciąg nie jest godny zaufania tylko dlatego, że pojawia się w nim mx.example . Jeśli surowa próbka będzie później zawierać podpis, uzyskaj próbkę lub dzienniki przeskoku raportowania przed podjęciem decyzji, czy nie było tam podpisu. To są przykłady nagłówków syntetycznych.