Behandle parseroppgraderingen som en datakontraktsendring
En rapportsamler kan fortsette å vise diagrammer mens han mister distinksjonene som det oppdaterte aggregerte formatet ble designet for å bære. An RFC 9990 migrering krever derfor mer enn å godta et nytt filnavn eller ignorere valideringsfeil. Definer hvilke ledningsformater som gjenkjennes, hvordan feltene deres kartlegges inn i den interne modellen og hvordan inkompatible eller mistenkelige input håndteres før produksjonsopptak endres.
Hold kildekvittering, dekompresjon, XML-parsing, skjematolkning og aggregering som separate stadier. Hver bør produsere et begrenset resultat og bevare nok opprinnelse for diagnose. Denne artikkelen foreslår det designet og dets testbeholdning. Den gir ikke en distribuert parser, utførte inventar eller bevis på at en eksisterende samler er i samsvar med den nye spesifikasjonen.
Identifiser formatet uten å endre DNS versjonen
RFC 9990 vedlegg A definerer gjeldende XML-skjema med navneområde urn:ietf:params:xml:ns:dmarc-2.0. Det valgfrie versjonselementet har verdi 1.0 under avsnitt 3.1.1.2 . Disse identifikatorene beskriver rapportformatet; ingen av dem betyr at et domene skal publisere v=DMARC2 i DNS . De DMARC policyversjonen forblir underlagt RFC 9989 avsnitt 4.7.
Et kompatibilitetsdesign bør gjenkjenne en støttet eldre profil separat fra gjeldende profil. Ta vare på hvilken profil som ble valgt og hvorfor. Ikke gi nytt navn til et ukjent navneområde for å få en inndata til å validere, sette inn manglende obligatoriske felt stille inn eller tolke en eldre rapport som gjeldende bare fordi rotelementet heter tilbakemelding. Ukjent inndata skal få et eksplisitt ustøttet eller satt i karantene.
Behold de originale rapportbytene under en passende tilgangs- og oppbevaringspolicy, sammen med en sammendrag og normalisert tolkning. Hvis det resulterer i en senere parserkorreksjon, vil den separasjonen gjøre reprosessering gjennomgåbar. Det forhindrer også at en normalisert post forveksles med nøyaktig det reporteren sendte.
Ta vare på politikkkonteksten og meningsinnretting
Den gjeldende policy_published-strukturen inkluderer valgfri discovery_method og testinformasjon. Discovery kan rapporteres som psl eller treewalk, og testing har t-verdien. Et fraværende valgfritt felt er ikke bevis på en bestemt implementeringsversjon. RFC 9990 avsnitt 3.1.1.5 definerer disse feltene og deres omfang.
Hold policy_evaluated atskilt fra auth_resultater. De tidligere postene DMARC-relaterte justering resultater og disposisjon; sistnevnte bærer autentiseringsresultater før den DMARC tolkningen. En rå DKIM pass fra et urelatert domene må ikke oppgraderes til et justert pass under normalisering. Bevar overstyringsgrunner i stedet for å endre autentiseringsresultatet for å samsvare med den endelige disposisjonen. Avsnitt 3.1.1.9 og 3.1.1.11 beskriver denne separasjonen.
Gjeldende DKIM resultatoppføringer krever velger. En eldre post uten en bør ikke motta en oppfunnet verdi som standard for å tilfredsstille gjeldende skjema. Registrer den støttede eldre tolkningen eller valideringsfeilen. Flere signaturer, valgfri konvoluttinformasjon og policyendringer i løpet av en rapportperiode trenger også eksplisitt representasjon; å kollapse dem for tidlig kan slette forklaringen en analytiker trenger.
Håndter utvidelser uten å gi fra seg validering
Spesifikasjonen gir utvidelsespunkter med navneavstand på definerte steder. Tilstedeværelsen eller fraværet av en utvidelse er ikke i seg selv en feil, og vilkårlige ukjente elementer er ikke automatisk gyldige overalt. RFC 9990 avsnitt 3.2 og 5 gi utmerkelsen. Bevar støttet utvidelsesinnhold eller avgrensede ugjennomsiktige data uten å la det overskrive kjernefeltbetydninger.
Behandle arkiv- og XML-inndata som uklarert. Avsnitt 8.1 identifiserer ressursutmattelsesrisiko ved dekompresjon og analysering. Foreslåtte implementeringskontroller inkluderer begrensninger for komprimert og utvidet størrelse, nesting, elementantall og behandlingstid, pluss deaktivering av ekstern enhetsoppløsning og nettverkshenting. Vis rapportlevert tekst som data. Dette er defensive designanbefalinger, ikke påstander om at samleren har bestått tester med ondsinnet input.
Feilformat inndata skal ikke angi vanlige aggregater som om de var gyldige. Avsnitt 3.1.1 anbefaler å forkaste rapporter som ikke samsvarer, samtidig som det tillates et forsiktig forsøk på å bruke enkelte data. Hvis et produkt støtter delvis gjenoppretting, merk resultatet og hold det utenfor normale beslutningsverdier til gjenopprettingspolicyen er gjennomgått. Stille tvang er spesielt farlig når en graf ser fullstendig ut.
Gjør duplikathåndtering til en eksplisitt policy
Rapport-ID er ment å hjelpe til med duplikatgjenkjenning, men en enkelt identifikator bør ikke antas globalt unik på tvers av ikke-relaterte reportere. Avsnitt 3.5.4 gjenkjenner eksakte duplikater og overlappende informasjon, og overlater håndtering til forbrukeren. Bevar reporter- og policykontekst, rapporteringsperiode, identifikator og innholdssammendrag når du foreslår dedupliseringsregler.
En nøyaktig gjentakelse og en endret rapport som dekker overlappende tid er ikke nødvendigvis det samme tilfellet. Unngå å summere begge deler eller forkaste en fordi datoperiodene deres krysser hverandre. Registrer resolusjonsbeslutningen og behold en måte å undersøke policyendringer og sene rettelser uten å omskrive historien usynlig.
Fiktivt arbeidsark og utløserport
En fiktiv case i gjeldende format inneholder dmarc-2.0-navneområdet, versjon 1.0, testing=y og en eksplisitt DKIM velger. En egen oppfunnet legacy-formet sak mangler den velgeren. Det planlagte akseptarket forventer distinkt profilhåndtering, ikke innsetting av en sammensatt velger. Ytterligere foreslåtte rader dekker en utvidelse med navneavstand, eksakt duplikat, overlappende rapport og feilaktig inndata. Ingen er henrettet.
Det eksakte originale kravet gjenstår: Kjør eldre og nåværende skjemaarmaturer, utvidelsestilfeller, dupliserte rapporter og feilaktige inndata. Igangkjøringsporten er: Valider gjeldende primærspesifikasjoner og behold et utført eksempel før utkast. De beholdte papirsakene og kildegjennomgangen tilfredsstiller ikke kjøretidsaksept. Parsersikkerhet, bakoverkompatibilitet, menneskelig SMB-godkjenning, produksjonsatferd og publiseringsgodkjenning forblir åpne til de nødvendige testene og beslutningene foreligger.