Najszybszy przydatny DMARC żądanie dowodu wymaga podania jednej reprezentatywnej wiadomości, trasy, która ją wygenerowała, oraz wyniku systemu odbierającego. Zrzut ekranu z informacją „SPF pomyślnie” lub „zweryfikowano domenę” zwykle pomija tożsamości potrzebne do wyjaśnienia niepowodzenia.
Poproś o najmniejszy zestaw dowodów, który może rozróżnić problem z uwierzytelnianiem, np wyrównanie problem, problem DNS i problem z dostawą. Rozszerzaj żądanie tylko wtedy, gdy pozostaje określona niepewność. Ogranicza to niepotrzebne eksponowanie treści klientów i daje nadawcy zadanie, które może faktycznie wykonać.
Najpierw poproś o bezpieczną reprodukcję
Jeśli to możliwe, właściciel aplikacji powinien wysłać niewrażliwą wiadomość testową za pośrednictwem przepływu pracy produkcyjnego, którego dotyczy problem, do autoryzowanego odbiorcy testu. Przepływ pracy ma znaczenie: przycisk testowy w konsoli dostawcy może używać innego nadawcy lub trasy niż faktury, resetowanie haseł lub zaplanowane powiadomienia.
Zapisz aplikację, konto klienta lub odniesienie do dzierżawy używane wewnętrznie, działanie wyzwalające, czas wysyłania w formacie UTC, zamierzony system odbiorcy oraz to, czy zaangażowane jest przekazywanie lub brama. Identyfikator wiadomości może pomóc w skorelowaniu dzienników, ale udostępniaj go tylko za pośrednictwem uzgodnionego kanału wsparcia. Nie żądaj haseł, prywatnych kluczy podpisu, danych uwierzytelniających API ani niepowiązanych eksportów skrzynek pocztowych.
Skupiaj się w początkowej prośbie na problemie technicznym. Jeśli awaria dotyczy wiadomości od prawdziwego klienta, przed udostępnieniem jej zawartości innej stronie zastosuj zatwierdzone procedury obsługi i kontroli dostępu.
Zachowaj dowody odróżniające tożsamości
Poproś o oryginalną wiadomość otrzymaną w docelowym miejscu docelowym lub o eksport diagnostyczny po stronie odbiorcy, który zachowuje odpowiednie nagłówki. Przydatne pola obejmują widoczną domenę Od i tożsamość koperty, jeśli jest dostępna DKIM podpisów i systemu odbierającego Authentication-Results.
Operator odbierający musi określić, który wynik jest zaufany. Sam tekst nagłówka może zostać sfałszowany lub pochodzić z niezaufanego źródła; RFC 8601 §1.2 I RFC 8601 §7.1 wyjaśnić wymóg dotyczący granicy zaufania. Jeśli istnieje kilka pól Authentication-Results , nie zakładaj, że najwyższy wpis jest automatycznie autorytatywny.
W przypadku wstępnej selekcji administrator może wyodrębnić odpowiednie pola tożsamości i wyników, zachowując bezpiecznie oryginał. Różni się to od kryptograficznej ponownej weryfikacji DKIM . Edycja podpisanych nagłówków lub treści może unieważnić podpis, dlatego zredagowana kopia niekoniecznie odzwierciedla oryginalne potwierdzenie. Jeżeli konieczna jest niezależna ponowna weryfikacja, należy zapewnić kontrolowany dostęp do niezmodyfikowanej próbki lub wygenerować nowy, bezpieczny test. Następuje obsługa uwzględniająca podpisy RFC 6376 §3.4 I RFC 6376 §3.7.
Minimalna prośba, którą możesz dostosować
Użyj poniższego jako szablonu operacyjnego, a nie prośby o ujawnienie danych uwierzytelniających:
„Proszę przesłać niewrażliwy test poprzez przepływ pracy, którego dotyczy problem, i podać:
- Aplikacja i dokładny przepływ pracy, czas wysyłania w formacie UTC oraz to, czy trasa obejmuje przekazywanie lub bramę.
- Oryginalna wiadomość otrzymana za pośrednictwem naszego zatwierdzonego kanału pomocy technicznej lub wyodrębniona z domeny przez administratora odbiorcy tożsamość i wynik oceniona przez SPF, każdy odpowiedni DKIM
d=Is=wartość i wynik oraz zaufany wynik DMARC . - Dokładna odpowiedź na odrzucenie w przypadku niepowodzenia dostarczenia, łącznie z systemem, który ją zwrócił. Jeśli nie istnieje żadna wiadomość od odbiorcy, zamiast tego podaj szczegóły śledzenia po stronie nadawcy.
- Ustawienia uwierzytelniania używane w tym konkretnym przepływie pracy oraz aktualne instrukcje dostawcy dotyczące obsługiwanej konfiguracji domeny klienta.
- Wszelkie ostatnie zmiany DNS , klucza, bramy lub adresu nadawcy i jego sygnatury czasowej.
Nie dołączaj haseł do kont, kluczy API, prywatnych kluczy DKIM ani niepowiązanych danych klientów. Zachowaj oryginalną próbkę w niezmienionej formie, jeśli może być konieczna weryfikacja podpisu.”
To żądanie tworzy wspólny punkt odniesienia. Nie zakłada się, że wspólna infrastruktura dostawcy lub znajomy źródłowy adres IP dowodzą, że Twoja organizacja autoryzowała nadawcę.
Dopasuj każdą odpowiedź do pytania diagnostycznego
Przed zaproponowaniem zmian utwórz mały arkusz dowodów.
- Dowód: z domeny; Pytanie, na które odpowiada: Którą domenę autora ocenia DMARC ?
- Dowód: wynik SPF i oceniana domena; Pytanie, na które odpowiada: Czy SPF spełnia kryteria tożsamości związanej z tą trasą?
- Dowód: wyniki DKIM ,
d=Is=; Odpowiedzi na pytania: które tożsamości podpisujące zostały zweryfikowane i jakie klucze zostały użyte? - Dowody: mające zastosowanie sposoby polityki i dostosowania; Pytanie, na które odpowiada: Czy przemijająca tożsamość jest zgodna z odpowiednią zasadą?
- Dowód: odpowiedź SMTP lub ostateczna dyspozycja; Odpowiedzi na pytania: Co właściwie stało się z dostawą?
- Dowód: zmiana znaczników czasu i bieżących obserwacji DNS ; Pytanie, na które odpowiada: czy czas konfiguracji może wyjaśnić różne obserwacje?
Następuje weryfikacja tożsamości i wyrównania RFC 9989 §5.3.3, RFC 9989 §5.3.4 I RFC 9989 §5.3.5. Arkusz ćwiczeń i format wniosku to praktyczne zalecenia.
Należy wyraźnie zająć się brakującymi dowodami
Jeśli nadawca podaje jedynie swój status konsoli, poproś o otrzymaną próbkę z rzeczywistego przepływu pracy. Jeśli odbiorca odrzucił wiadomość przed przyjęciem wiadomości, potwierdź, że ostateczna kopia skrzynki pocztowej może nie istnieć. Użyj śledzenia ruchu wychodzącego nadawcy, odpowiedzi na odrzucenie i dzienników operatora odbierającego, jeśli są dostępne.
Jeśli bieżący DNS różni się od znacznika czasu wiadomości, nie udawaj, że potwierdza to, co widział wcześniejszy odbiorca. Poproś o historię zmian lub świeżą, kontrolowaną reprodukcję. Jeśli dostawca nie może zaoferować obsługiwanej, dopasowanej tożsamości, zarejestruj lukę w możliwościach i przepływ pracy, na który ma to wpływ, zamiast wymyślać wartości DNS .
Zakończ dochodzenie porównaniem tożsamości przed i po, dokładnej zmianie i nowym zaufanym wyniku. Połącz ten dowód z inwentarz nadawcy. The przewodnik po błędach wyrównania pomaga to zinterpretować, podczas gdy przewodnik dotyczący prywatności raportowania wspiera decyzje dotyczące zatrzymanych dowodów.
Podejmij następną decyzję jasno
Jeśli istnieje tylko zrzut ekranu konsoli, oznacz ocenioną domenę SPF , dopasowaną tożsamość DKIM i granicę zaufania odbiorcy jako brakujące. Poproś o te pola, zamiast deklarować poprawkę DNS . Jeśli odrzucenie uniemożliwiło dostarczenie skrzynki pocztowej, zamiast tego użyj odpowiedzi SMTP i śledzenia nadawcy. Zapisz znacznik czasu każdej obserwacji oddzielnie od późniejszej kontroli DNS ; nie zebrano ani nie zweryfikowano tutaj żadnej oryginalnej wiadomości.