Wydawniczy p=reject jest kamieniem milowym polityki, a nie końcem DMARC operacje. Zmieniają się usługi wysyłające, pojawiają się nowe aplikacje, a odbiorcy zachowują własne decyzje obsługowe. Zbiorcze raportowanie w dalszym ciągu pomaga zidentyfikować regresje w zakresie uwierzytelniania, nowo zaobserwowane źródła i różnice między żądaną polityką a zgłoszonym sposobem leczenia.
Kontynuuj konfigurowanie i monitorowanie raportowania po zmianie zasad. Przydatność nadal zależy od użycia domeny: RFC 9989 §7.4 ostrzega przed odrzucaniem domen, których użytkownicy mogą wysyłać posty na internetowe listy mailingowe i wymaga odrzucenia domen, aby były prawidłowe DKIM zamiast polegać wyłącznie na SPF. Dowody pozostają ograniczone przez uczestniczących odbiorców i ich obserwacje. Polityka odrzucania nie stanowi dowodu na to, że każda próba podszywania się pod inną osobę została zablokowana lub że każda wiarygodna wiadomość została dostarczona.
Przeczytaj oddzielnie zasady, ocenę i dyspozycję
Referencje: RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
Opublikowana polityka określa wymagane przez właściciela domeny traktowanie poczty, która nie spełnia wymagań DMARC . Podczas oceny sprawdzane jest, czy uwierzytelniony identyfikator SPF lub DKIM jest zgodny z domeną autora. Zgłoszona dyspozycja opisuje zgłoszone przez odbiorcę leczenie związane z DMARC, z informacjami o zastąpieniu, jeśli zostały dostarczone.
Pola te nie powinny być zwijane w jeden status. Rekord pokazanie p=reject obok dyspozycji none nie jest automatycznie zniekształcone: wiadomość mogła zostać przekazana lub obsługa odbiorcy mogła różnić się od żądanej akcji. Zamiast zgadywać na podstawie samych zasad, sprawdź dopasowane wyniki i dostępny powód. RFC 9989 zachowuje dyskrecję odbiorcy oraz RFC 9990 definiuje pola agregujące.
Uważaj na regresje legalnej trasy
Referencje: RFC 9989 §5.3.5.
Utrzymuj utrzymywany spis aplikacji i właścicieli. Porównaj bieżące obserwacje z ich oczekiwaną tożsamością i zbadaj zmianę selektor, ścieżka powrotna lub domeny autora, zanim użytkownicy zgłoszą brakującą pocztę. Uwzględnij trasy o niskim natężeniu ruchu i trasy sezonowe, które mogą pozostać niewidoczne przez długi czas.
Przykładowy przypadek: zweryfikowana wcześniej aplikacja rozliczeniowa zostaje przeniesiona na nową platformę i traci swoje wyrównanie Podpis DKIM. SPF nadal przechodzi pod niepowiązaną domenę usług. Załóżmy, że obowiązują obowiązujące zasady i zakończone kontrole. Bez innej wyrównanej ścieżki przekazywania wiadomość w tym syntetycznym przykładzie nie powiedzie się DMARC . Przydatną reakcją jest naprawa obsługiwanej tożsamości nadawcy, a nie zakładanie, że egzekwowanie prawa sprawiło, że przyszłe wdrażanie stało się niepotrzebne.
Interpretacja ciągłych nieautoryzowanych awarii
Nieautoryzowani nadawcy mogą nadal korzystać z domeny w obszarze Od nawet po wymuszeniu egzekwowania prawa. Raporty mogą pokazywać zaobserwowane nieudane uwierzytelnienie i sposób postępowania z odbiorcą dla tego ruchu. Liczba utrzymujących się błędów nie jest sama w sobie dowodem nieskuteczności egzekwowania prawa; kontrola może odrzucać ruch, który w dalszym ciągu napływa.
I odwrotnie, nie licz każdej awarii jako potwierdzonego ataku, któremu udało się zapobiec. Uznanie autorstwa, zamiar, zasięg odbiorcy i faktyczna obsługa wymagają dowodów. Liczba raportów jest liczbą obserwacji, a zgłoszona dyspozycja nie jest pełnym audytem dostawy na dalszym etapie.
Pogodź wyjątki i brakujące pokrycie
Referencje: RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
Przejrzyj zapisy, w których nieudana poczta została potraktowana inaczej niż zgodnie z żądanymi zasadami. Zbadaj podane powody zastąpienia i odpowiednie zachowanie w zakresie przekazywania lub pośrednictwa. Nie zakładaj, że każdy odbiorca stosuje tę samą lokalną politykę lub że każdy wyjątek ma wystarczające wyjaśnienie w pliku raport zbiorczy.
Sprawdź sam proces raportowania: własność miejsca docelowego, autoryzacja zewnętrzna, jeśli jest to wymagane, błędy przetwarzania i zmiany u odbiorców przekazujących dane. Cichy pulpit nawigacyjny po wymuszeniu może odzwierciedlać problem z windykacją. Przeprowadź kontrolowany test tras krytycznych i porównaj dowody odbiorcy z dziennikami aplikacji podczas sprawdzania dostawy.
Utrzymuj rytm działania po egzekwowaniu prawa
Przypisz odpowiedzialność za wdrażanie nowego nadawcy, okresowy przegląd zapasów, zmiany DNS i selekcję raportów. Skorzystaj z procesu zatwierdzania i wygaśnięcia w przypadku tymczasowego złagodzenia zasad. Sprawdź, czy proponowana zmiana dotyczy obsługiwanej przyczyny i nie wpływa niepotrzebnie na niepowiązanych nadawców.
Zamykaj każdy przegląd, sprawdzając legalne trasy, badając nieznane źródła, sprawdzając odchylenia od odbiorców i nadal występując luki w raportach. Cel po p=reject zostaje zachowany, dający się wytłumaczyć zakres uwierzytelnienia. Sam ciąg zasad nie może zapewnić takiej pewności.
Związane zakończenie i następna akcja
W przypadku przeniesienia platformy fikcyjnej zachowaj nieprzetworzony przebieg SPF pod niepowiązaną tożsamością usługi oddzielnie od brakującego dopasowanego DKIM . Późniejszą obsługiwaną naprawę podpisywania należy przetestować na trasie, której dotyczy problem. Zgłoszona brak dyspozycji pozostaje dowodem, a nie dowodem odzyskania uwierzytelnienia lub odebrania wiadomości w skrzynce odbiorczej.