A DMARC raport zbiorczy grupuje obserwacje w rekordy. Odczyt tylko źródłowego adresu IP lub czerwonego statusu odrzuca kontekst zasad, tożsamości i raportowania potrzebny do zdiagnozowania wiersza. Pracuj od raportu zewnętrznego do wewnątrz i zachowaj oryginalny plik XML wraz z interpretacją.
Ustal kontekst raportu
W obszarze opinii report_metadata identyfikuje organizację raportującą, identyfikator raportu i zakres dat. policy_published opisuje konfigurację zasad zaobserwowaną przez odbiorcę. RFC 9990 wymaga jednej domeny zasad na raport, ale raport ten może zawierać wiele domen autorów korzystających z danej zasady. Nie zakładaj, że opublikowana polityka/domena jest równa nagłówkowi_nagłówka każdego rekordu.
Sprawdź zadeklarowaną przestrzeń nazw i format. Bieżący schemat RFC 9990 i starsze raporty z ery RFC 7489 różnią się, dlatego zapisz, jakiego profilu weryfikacji używasz. Jeśli dokument nie pasuje do oczekiwanego formatu, poddaj go kwarantannie lub wyraźnie zaznacz częściową interpretację, zamiast po cichu traktować zniekształcone dane jako czysty raport. Analizuj niezaufany kod XML bez rozwiązywania dowolnych jednostek zewnętrznych i wiąż skompresowane dane wejściowe i rozmiar rozszerzenia.
Śledź rekord przez trzy warstwy
Wiersz zawiera adres_źródłowy, liczbę i ocenę zasad. IP to system łączący widziany przez ten odbiornik, a nie automatycznie Twoja aplikacja inicjująca. Liczba podaje wagę tej kombinacji obserwacji; zliczanie rekordów XML nie jest zliczaniem wiadomości.
Sekcja identyfikatorów zawiera informacje o nagłówku i opcjonalnej kopercie. auth_results zawiera surowe SPF I DKIM wyniki przed interpretacją dla DMARC . policy_evaluated/dkim i policy_evaluated/spf opisują odpowiednie DMARC wyrównanie ocena, natomiast dyspozycja opisuje postępowanie zgodnie z polityką. Zachowaj powody zastąpienia, zamiast redukować cały rekord do jednej etykiety Pass/Fill.
Opisz wiersz syntetyczny
Załóżmy, że nagłówek_od to brand.example , liczba wynosi 25, POCZTA OD domena to vendor.example i surowe przepustki SPF . DKIM przechodzi z d=brand.example. Tożsamość SPF nie jest powiązana z domeną autora, więc nie zapewnia wyrównanego SPF ; domena-dokładna Podpis DKIM zapewnia wyrównany DKIM . Wynik zasad spf=fail i dkim=pass jest zgodny z tymi faktami. DMARC może przejść przez DKIM pomimo niepowodzenia polityki SPF.
Ten przykład dotyczy nauczania na poziomie pola, a nie kompletnego dokumentu XML zgodnego ze schematem lub zmierzonego wyniku klienta. To pokazuje, dlaczego dodanie łączącego adresu IP do SPF brand.example może nie mieć znaczenia: SPF został oceniony dla vendor.example , a DMARC miał już dopasowaną ścieżkę DKIM .
Zamień awanturę w własne śledztwo
Powiąż adres IP i tożsamości z danymi autoryzowanych nadawców, dowodami dostawcy i kontrolowanymi testami wiadomości. Przypisz właściciela przed zadeklarowaniem nieznanego źródła jako złośliwego lub zmianą DNS . Zachowaj luki w raportach i granice czasowe w notatce o zdarzeniu.
Przydatna adnotacja obejmuje pochodzenie, okres, domenę polityki, domenę autora, surowe wyniki, dopasowane wyniki, dyspozycję, liczbę i następne działanie. Taka struktura pozwala innemu badaczowi odtworzyć Twoje rozumowanie bez uzależnienia od koloru deski rozdzielczej.
Zachowaj mapę pola i oczekiwany wynik
Częściowa mapa raportów syntetycznych wykorzystuje reportera fikcyjnego odbiorcę A, identyfikator pola mapy-25 i przedział epoki UTC 1704067200–1704153600 (1 stycznia 2024 r. 00:00 do 2 stycznia 2024 r. 00:00 UTC). Jej domena zasad to brand.example z p=reject, aspf=r i adkim=r. Rekord ma adres source_ip= 192.0.2.10 , count=25, nagłówek_od= brand.example i koperta_od= vendor.example . Surowe przepustki SPF dla vendor.example ; surowe przepustki DKIM dla brand.example z selektor rozliczenia 1. W bieżącym przykładzie profilu raportowania RFC 9990 raportowane wyniki zasad to spf=fail, dkim=pass i disposition=pass. Dodatek A definiuje przepustkę do zaliczenia DMARC w ramach polityki egzekwowania; Ilustruje to dodatek B.
Porównanie pola opisuje 25 obserwacji z przechodzącą wyrównaną ścieżką DKIM i bez wyrównanej ścieżki SPF . Dyspozycja to dostarczone pole odbiorcy, a nie obliczone rozmieszczenie skrzynki odbiorczej. Metadane ustalają pochodzenie i okres; policy_published dostarcza konfigurację historyczną; Identyfikatory i auth_results dostarczają danych wejściowych porównania. To urządzenie jest częściową mapą pola, a nie pełnym kodem XML i nie wymaga żadnego raportu z poprawnością schematu ani testu odbiornika na żywo.
Uzupełnij adnotację wiersza
- Reporter i interwał: zachowanie oryginalnego identyfikatora raportu oraz czasu rozpoczęcia/zakończenia w formacie UTC.
- Waga: użyj liczby, a nie liczby wierszy XML.
- Kontekst: domena zasad rekordu, nagłówek_z i obowiązująca polityka.
- Uwierzytelnianie: zapisz surową domenę/wynik SPF i każdą domenę/wynik DKIM ; porównaj przechodzące domeny pod kątem wyrównania.
- Wynik: przechowuj wyniki dopasowania, dyspozycję i powody zastąpienia w oddzielnych polach.
- Następna akcja: podaj podejrzaną trasę, nadal brakuje dowodów i podaj odpowiedzialnego właściciela przed zmianą DNS .
Rozróżnij dyspozycje obecne i starsze
Dodatek A RFC 9990 definiuje przekazanie dyspozycji jako brak akcji polegającej na przekazaniu DMARC z polityką egzekwowania. Nie zachowuje żadnego, ponieważ nie podjęto żadnych działań. W starszych raportach w formacie RFC 7489 nie ma informacji o przekazaniu i nie można ich raportować w przypadku przechodzącej wiadomości. Sprawdź razem przestrzeń nazw, profil raportowania i dopasowane wyniki: żadna z nich nie jest uniwersalnie nieprawidłowa, ale nie powinna po cichu zastępować przykładu podania bieżącego profilu. Żadna wartość nie świadczy o umieszczeniu skrzynki odbiorczej.