Zacznij od zachowania, a nie od zapisu zastępczego
Migracja standardów staje się wykonalna, gdy każda decyzja wdrożeniowa ma nazwaną specyfikację i odpowiedzialnego właściciela. Edytor DNS , an wyrównanie silnik i analizator raportów zbiorczych nie wykonują tego samego zadania. Wzywam całą trójkę”DMARC support” ukrywa zależności, które mają znaczenie, gdy jeden komponent się zmienia, a drugi pozostaje w starszej implementacji. Praktycznym produktem jest mapa komponentu do wymagań z wersjami, interfejsami i zachowanymi dowodami akceptacji, a nie deklaracja, że cała nieruchomość została zmodernizowana.
Aktualny zestaw dokumentów został opublikowany w maju 2026 r. RFC 9989 definiuje podstawowy mechanizm i jest przestarzały RFC 7489 i RFC 9091 . RFC 9990 obejmuje raportowanie zbiorcze; RFC 9991 obejmuje raportowanie błędów, a także aktualizuje RFC 6591 . Identyfikują świeże rekordy edytora RFC RFC 9989 I RFC 9990 jako Proponowane Standardy. Opublikowany tekst RFC 9991 określa kategorię ścieżki standardów. Są to opublikowane specyfikacje, a nie niedokończone projekty, przy czym publikacja nie ustala realizacji konkretnego odbiorcy.
Daj silnikowi rdzeniowemu dokładny kontrakt
Przypisz analizę rekordów, wykrywanie zasad, wykrywanie domeny organizacyjnej i wyrównanie identyfikatorów do RFC 9989 sekcje 4.7–4.10. Domena autora pochodzi z wiadomości RFC5322 pole. Odkryta domena zasad może różnić się od domeny autora, a domena organizacyjna używane do swobodnego wyrównania to kolejny wyraźny wynik. Utrata tych rozróżnień w interfejsie może sprawić, że prawidłowy parser będzie zasilał nieprawidłowy silnik decyzyjny.
Rekord DNS nadal zaczyna się od v=DMARC1. „DMARCbis" to nazwa pracy nad standardami, a nie pozwolenie na wynalezienie DMARC2. Obecne odkrycie wykorzystuje ograniczone przechodzenie po drzewie DNS , a nie traktowanie historycznej listy kontrolnej z publiczną listą sufiksów jako całego algorytmu. Tagi psd, np i t wymagają osobnego pokrycia decyzji. The Rejestr IANA oznacza pct, rf i ri historyczne; nie poświadcza, czy wdrożony produkt je ignoruje, interpretuje lub ujawnia.
Zachowaj rozróżnienie pomiędzy normalną awarią DMARC , niedostępnymi informacjami DNS , nieprawidłową polityką i ostateczną dyspozycją wiadomości od odbiorcy. Sekcja 4.10.1 RFC 9989 zawiera specjalną obsługę nieprawidłowych znaczników zasad, gdy pozostaje syntaktycznie poprawny identyfikator URI raportu zbiorczego. Uproszczona zasada „każda źle sformułowana polityka staje się niczym” wymazałaby jej warunki. Zapisz dokładną sekcję obok przypadku parsera, który ją wykonuje.
Traktuj zbiorczą informację zwrotną jako własną implementację
Mapuj producenta agregatu, walidator XML, konsumenta raportów, integrację z obsługą duplikatów i dostawą RFC 9990 sekcje 3–4 i dodatek A. Interfejs raportowania wymaga faktycznie ocenionej polityki, wyników uwierzytelniania, liczby wiadomości i kontekstu okresu raportowania. Pulpit nawigacyjny wyświetlający kod XML nie jest dowodem na to, że odbiorca nadrzędny wybrał właściwą politykę lub że w danych pojawił się każdy odpowiedni nadawca.
Zewnętrzne miejsca docelowe raportów zasługują na własny wiersz komponentów. Autoryzacja miejsca docelowego to techniczna kontrola przed nadużyciami, a nie zgoda na przesyłanie dowolnych danych organizacyjnych. Umieść generowanie raportów, weryfikację miejsca docelowego i decyzje dotyczące dostępu/utrzymania w ramach odrębnych kryteriów akceptacji. Sekcja 7 RFC 9990 dotyczy prywatności, natomiast sekcja 8 zawiera ostrzeżenie przed złośliwymi lub fałszywymi treściami raportów. Dlatego też wzmacnianie parsera i zaufanie do źródła należą do tej mapy obok ważności schematu.
Nie używaj ponownie analizatora zbiorczego do raportów o błędach
Informacja zwrotna o niepowodzeniu to inny kanał, z którym wiąże się różne ryzyko ujawnienia informacji. RFC 9991 reguluje jego generowanie i format, współpracując z przywołanymi specyfikacjami raportowania błędów uwierzytelniania. Żądanie ruf i warunki fo nie są równoważne agregacji rua. Odbiorca może odmówić zgłoszenia awarii, a w przypadku braku a raport o awarii nie jest dowodem na to, że wszystkie wiadomości zostały przekazane.
Może wystąpić integracja raportu o błędach nagłówki wiadomości lub treści, których zagregowany potok nie ma przenosić. Określ, kto może o to poprosić, gdzie można to wysłać, w jaki sposób materiały przychodzące są zawarte i jaka kontrola prywatności ma zastosowanie. Nigdy nie włączaj tej funkcji jedynie po to, aby matryca funkcji wyglądała na kompletną. Podstawowe wymagania dotyczące udziału, opcjonalne zgłaszanie awarii i możliwości reklamowanego produktu komercyjnego to różne twierdzenia wymagające różnych dowodów.
Przejrzyj fikcyjny inwentarz komponentów
Rozważmy fikcyjną usługę składającą się z sześciu modułów: dekodera zasad, narzędzia do rozpoznawania nazw, narzędzia do oceny dopasowania, narzędzia do tworzenia agregatów, konsumenta XML i modułu zbierającego błędy. Pierwsze trzy mapują do RFC 9989 . Następne dwa dotyczą głównie RFC 9990 . Kolektor jest mapowany głównie na RFC 9991 . Współdzielona pamięć masowa i mechanizmy kontroli bezpieczeństwa dziedziczą wymagania z każdej obsługiwanej ścieżki raportowania. Ten spis jest oryginalnym przykładem dokumentalnym, a nie stwierdzeniem na temat architektury EmailAuth .
Dla każdego modułu zachowaj jego rzeczywisty identyfikator kompilacji, odpowiednie sekcje, umowę wejścia/wyjścia, właściciela i urządzenie akceptacyjne. Fikcyjne urządzenie do wykrywania może przekazać wybraną politykę i jej domenę źródłową do fikcyjnego urządzenia zbiorczego; wiersz raportowania powinien zachować to rozróżnienie, a nie po cichu zastępować widoczną domenę Od. Następnie złóż żądanie raportu o błędach i potwierdź, że projekt kieruje je do oddzielnie autoryzowanej ścieżki przetwarzania. Są to proponowane kontrole, a nie zakończone egzekucje.
Zachowaj status, erratę i wdrożenie oddzielnie
Dokładna prowizja wynosi: Zamapuj każdy komponent implementacyjny na RFC 9989 , 9990 lub 9991 i sprawdź erratę. Nie podano rzeczywistego zakresu wdrożenia. Pobieranie bieżących errat nie powiodło się i zostało zatrzymane, zatem w tej wersji roboczej nie można stwierdzić, że dokumenty nie zawierają errat. Dyskusja w dokumencie RFC 9989 na temat rozwiązanej erraty RFC 7489 ma kontekst historyczny, a nie nowe sprawdzenie erraty dla trzech nowych dokumentów.
Przed wydaniem właściciel implementacji musi uzgodnić rzeczywisty inwentarz, właściciel standardów musi rozwiązać bieżące erraty, a właściciel testujący odbiornik musi zachować dowody interoperacyjności w zakresie wersji. Przegląd specjalistyczny, kontrola przebiegu produkcji, akceptacja wizualna i zatwierdzenie publikacji również pozostają otwarte. Przydatnym dzisiaj rezultatem jest możliwa do przeglądu mapa, która ujawnia brakujące dowody, nie przekształcając zaktualizowanego standardu w nieuzasadnione twierdzenie o uniwersalnym wdrożeniu.