Sprawozdania zbiorcze stanowią dowód retrospektywny. Panel kontrolny może być aktualny jako system windykacji, a jego najnowsze obserwacje nadal opisują wczorajszą pocztę. Śledź zegary osobno, aby opóźniony raport nie został pomylony z bieżącym niepowodzeniem wysyłania, a bieżąca awaria nie została ukryta za starymi, zdrowymi danymi.
Zachowaj trzy znaczniki czasu
Referencje: RFC 9990 §3.1.1.4, RFC 9990 §3.1.
Zachowaj znaczniki czasu rozpoczęcia i zakończenia raportu, znacznik czasu przybycia systemu odbierającego oraz znacznik czasu przetwarzania modułu zbierającego. Zinterpretuj interwał raportu w formacie UTC i wyraźnie pokaż konwersję wyświetlanej strefy czasowej. Czas modyfikacji pliku nie zastępuje okna obserwacyjnego.
RFC 9990 opisuje okresowe zbiorcze opinie i uwzględnia objęty zakres dat w metadanych raportu. Nie tworzy uniwersalnej usługi monitorowania w czasie rzeczywistym. Raport, który dotrze z opóźnieniem, może w dalszym ciągu stanowić użyteczny dowód dotyczący pierwotnego interwału.
Zmierz opóźnienie przez reportera
W celu monitorowania operacyjnego należy obliczyć opóźnienie odbioru od zakończenia raportu do przybycia oraz opóźnienie przetwarzania od przybycia do pomyślnego importu. Zachowaj oddzielne dystrybucje według reportera i ścieżki zbierania. Są to lokalne wskaźniki operacyjne, a nie gwarancje protokołu. Zdefiniuj progi alertów na podstawie zaobserwowanego zachowania i decyzji biznesowej, która wymaga aktualnych danych.
Monitoruj także błędy przetwarzania i najnowszy interwał. Stały napływ zduplikowanych lub starych plików nie powinien powodować zielonego wyświetlania świeżości. Zaznacz tymczasowe okna raportowania do czasu ich zamknięcia przez udokumentowany proces późnego przyjazdu.
Rozróżnij awarię na podstawie aktualnych dowodów
Gdy użytkownicy zgłoszą brak resetowania hasła, sprawdź bieżące kolejki wysyłania, odpowiedzi SMTP i kontrolowane otrzymane wiadomości. Nie czekaj na jutrzejszy raport, aby rozpocząć rozwiązywanie problemów. I odwrotnie, jeśli bieżące testy powiodą się, ale zagregowane dane są stare, sprawdź ścieżkę raportowania bez deklarowania wyłączenia usługi wysyłającej.
Przykładowy harmonogram: raport obejmuje poniedziałek w godzinach 00:00–24:00 UTC, dociera we wtorek o 05:00 i jest importowany o 08:00. Opóźnienie odbioru wynosi pięć godzin; opóźnienie przetwarzania wynosi trzy godziny. Żadna z tych liczb nie mierzy, ile czasu zajęło dotarcie pojedynczej poniedziałkowej wiadomości. Te syntetyczne wartości ilustrują metodę księgowania, a nie zalecany cel usługi.
Obsługuj spóźnienia bez cichego przepisywania historii
Referencje: RFC 9990 §3.5.4.
Zachowaj aktualną sygnaturę czasową wyeksportowanych metryk i weryfikuj wszelkie skorygowane sumy. Ponowne przetwarzanie powinno być idempotentne, aby ponowna próba nie liczyła ponownie tych samych obserwacji. Zachowaj oryginalne odstępy czasu, zamiast umieszczać wszystkie spóźnione pliki w dniu przybycia.
Eskaluj brak oczekiwanego reportera, rosnącą kolejkę przetwarzania i awarię nadawcy na żywo jako różne zdarzenia. Zamknij każde z odpowiednimi dowodami. Aktualność raportu ma znaczenie tylko wtedy, gdy określa, która populacja i przedział są faktycznie dostępne.
Opublikuj praktyczny panel świeżości
Pokaż ostatni objęty interwał, czas przybycia i czas importu dla każdego ważnego reportera, a także rozmiar i najstarszy wiek zaległości w przetwarzaniu. Uwzględnij ostatnie odświeżenie samego systemu monitorowania. Zamrożony pulpit nawigacyjny nie powinien wyglądać na zdrowy, ponieważ jego ostatni zapisany stan miał kolor zielony. Przypisz osobnych właścicieli do niepowodzeń odbioru i błędów przetwarzania. Przed użyciem progu ostrzegawczego należy udokumentować okres obserwacji, z którego wyprowadzono jego wartość bazową, oraz jakie działanie powinien wywołać alert. Odwiedź go ponownie po migracji kolekcjonerów.
Kontynuuj śledztwo
Skorzystaj z przewodnik dotyczący raportu zbiorczego interpretować podstawowe pola i poradnik diagnostyki zbieżności gdy surowe uwierzytelnienie nie spełnia wymagań DMARC.
Wykonano syntetyczny dowód
Poniżej znajduje się lokalnie odtwarzane syntetyczne urządzenie offline, a nie działający DNS , SMTP lub obserwacja klienta. Dane wejściowe XML zostały przeanalizowane przy użyciu standardowej biblioteki Pythona, a asercje sprawdziły powstałe pola i obliczenia. Symulowane etapy DNS i poczty stanowią dane wejściowe testowe, a nie dowód, że rzeczywisty odbiorca wykonał te operacje. Pełna weryfikacja schematu i uwierzytelnianie źródła produkcyjnego nie mieszczą się w tym małym urządzeniu; dowody na żywo pozostają w toku.
Dostarczone żądanie to _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Zakłada się, że te zarezerwowane domeny przykładowe są oddzielnymi domenami organizacyjnymi w urządzeniu. Dwie syntetyczne odpowiedzi dotyczące autoryzacji to: brand.example._report._dmarc.collector.example TXT "v=DMARC1" I brand.example._report._dmarc.archive.example TXT "v=DMARC1". Model lokalny odpowiada zarówno podanym nazwom właścicieli autoryzacji, jak i wartościom ich wersji poniżej RFC 9990 §4. Nie wykonuje zapytań DNS ani pełnego algorytmu autoryzacji. Implementacja produkcyjna musi przeprowadzić pełną procedurę wykrywania i autoryzacji, a nie zakładać granice domeny.
Zachowany raport ma identyfikator R1, domenę zasad brand.example , zakres_dat zaczyna się 1772409600 i kończy 1772496000, źródłowy adres IP 192.0.2.10 i liczba 100. Jego ocena jest zgodna DKIM wynik jest pozytywny i wyrównany SPF to porażka. Surowy wynik SPF jest pozytywny dla vendor.example , co ilustruje, dlaczego surowy sukces nie jest sukcesem wyrównanym. Pola te są analizowane na podstawie kodu XML, a nie wyciągane z pulpitu nawigacyjnego.
Urządzenie ustawia przybycie na koniec raportu plus 18 000 sekund i zakończenie importu na koniec raportu plus 28 800 sekund. Wykonane odejmowanie daje pięć godzin opóźnienia w odbiorze i trzy godziny opóźnienia w przetwarzaniu. Zarówno miejsca docelowe, jak i dane wejściowe uprawnień pozostają takie same, więc obliczenia można śledzić na podstawie opublikowanego żądania poprzez przeanalizowany interwał i znaczniki czasu modułu zbierającego. Te wartości to dane wejściowe testowe, a nie zmierzone opóźnienie lub umowa SLA. RFC 9990 §3.1.1.4 dostarcza semantykę zakresu dat UTC; formuły opóźnienia są definicjami operacyjnymi tego przepływu pracy.
Utrzymuj wynik w testowanym zakresie
Dostarczona lokalna demonstracja weryfikuje jedynie mały syntetyczny parser, dostarczone wejścia etapowe i obliczenia. Nie testowano żadnej rzeczywistej autoryzacji DNS , dostarczania SMTP , migracji kolektorów, udziału dostawców ani zachowania produkcyjnej bazy danych. Oryginalne dane wejściowe pozostają archiwizowane, a wszelkie porównania na żywo wymagają własnych, chronionych dowodów i odpowiedzialnej zgody.