Behandla parseruppgraderingen som en datakontraktsändring
En rapportsamlare kan fortsätta att visa diagram samtidigt som den förlorar de distinktioner som det uppdaterade sammanlagda formatet är designat för att bära. En RFC 9990 migrering kräver därför mer än att acceptera ett nytt filnamn eller ignorera valideringsfel. Definiera vilka trådformat som känns igen, hur deras fält mappas in i den interna modellen och hur inkompatibel eller misstänkt indata hanteras innan produktionsintag ändras.
Håll källmottagning, dekomprimering, XML-parsning, schematolkning och aggregering som separata steg. Var och en bör ge ett begränsat resultat och bevara tillräckligt med ursprung för diagnos. Den här artikeln föreslår den designen och dess testinventering. Den tillhandahåller inte en utplacerad parser, exekverade fixturer eller bevis på att någon befintlig samlare överensstämmer med den nya specifikationen.
Identifiera formatet utan att ändra DNS versionen
RFC 9990 Bilaga A definierar det aktuella XML-schemat med namnutrymmet urn:ietf:params:xml:ns:dmarc-2.0. Det valfria versionselementet har värdet 1.0 under avsnitt 3.1.1.2 . Dessa identifierare beskriver rapportformatet; varken betyder att en domän ska publicera v=DMARC2 i DNS . De DMARC policyversionen förblir styrd av RFC 9989 avsnitt 4.7.
En kompatibilitetsdesign bör känna igen en äldre profil som stöds separat från den aktuella profilen. Bevara vilken profil som valdes och varför. Byt inte namn på ett obekant namnområde för att få en indata att validera, infoga inte obligatoriska fält som saknas eller omtolka en äldre rapport som aktuell bara för att rotelementet heter feedback. Okänd inmatning bör få ett uttryckligt resultat som inte stöds eller i karantän.
Behåll de ursprungliga rapportbytena under en lämplig åtkomst- och lagringspolicy, tillsammans med en sammanfattning och normaliserad tolkning. Om en senare parserkorrigering blir resultatet, gör den separationen att ombearbetningen kan granskas. Det förhindrar också att en normaliserad post misstas för exakt vad reportern skickade.
Bevara policykontext och anpassningsinnebörd
Den nuvarande policy_published-strukturen inkluderar valfri discovery_method och testinformation. Discovery kan rapporteras som psl eller treewalk, och testning bär t-värdet. Ett frånvarande valfritt fält är inte bevis på en viss implementeringsversion. RFC 9990 avsnitt 3.1.1.5 definierar dessa fält och deras omfattning.
Håll policy_evaluated åtskilda från auth_results. De tidigare rekorden DMARC-relaterade inriktning resultat och disposition; den senare bär autentiseringsresultat före den DMARC tolkningen. En rå DKIM pass från en icke-relaterad domän får inte befordras till ett anpassat pass under normalisering. Bevara åsidosättande skäl snarare än att ändra autentiseringsresultatet så att det matchar den slutliga dispositionen. Avsnitt 3.1.1.9 och 3.1.1.11 beskriver denna separation.
Aktuella DKIM resultatposter kräver väljare. En äldre post utan en sådan bör inte få ett uppfunnet värde som standard för att uppfylla det aktuella schemat. Registrera den äldre tolkningen som stöds eller valideringsfelet. Flera signaturer, valfri kuvertinformation och policyändringar under en rapportperiod behöver också explicit representation; att kollapsa dem i förtid kan radera förklaringen som en analytiker behöver.
Hantera tillägg utan att ge upp validering
Specifikationen tillhandahåller namnavgränsade förlängningspunkter på definierade platser. Närvaron eller frånvaron av en tillägg är inte i sig ett fel, och godtyckliga okända element är inte automatiskt giltiga överallt. RFC 9990 avsnitt 3.2 och 5 ge distinktionen. Bevara tilläggsinnehåll som stöds eller begränsad ogenomskinlig data utan att tillåta den att skriva över kärnfältets betydelser.
Behandla arkiv och XML-indata som opålitliga. Avsnitt 8.1 identifierar resursutmattningsrisker vid dekompression och analys. Föreslagna implementeringskontroller inkluderar begränsningar för komprimerad och utökad storlek, kapsling, antal element och bearbetningstid, plus inaktivering av extern enhetsupplösning och nätverkshämtning. Visa rapporttillförd text som data. Dessa är defensiva designrekommendationer, inte påståenden om att samlaren har klarat tester med skadlig inmatning.
Felaktig inmatning ska inte ange vanliga aggregat som om den vore giltig. Avsnitt 3.1.1 rekommenderar att man kasserar rapporter som inte överensstämmer med samtidigt som man tillåter ett försiktigt försök att använda vissa data. Om en produkt stöder partiell återhämtning, märk resultatet och håll det utanför normala beslutssummor tills återställningspolicyn har granskats. Tyst tvång är särskilt farligt när en graf verkar komplett.
Gör dubbelhantering till en explicit policy
Rapport-ID är avsett att underlätta dubblettigenkänning, men en enda identifierare bör inte antas vara globalt unik för icke-relaterade reportrar. Avsnitt 3.5.4 känner igen exakta dubbletter och överlappande information, vilket överlåter hanteringen till konsumenten. Bevara reporter- och policykontext, rapporteringsperiod, identifierare och innehållssammanfattning när du föreslår dedupliceringsregler.
En exakt upprepning och en ändrad rapport som täcker överlappande tid är inte nödvändigtvis samma fall. Undvik att bara summera båda eller släng en eftersom deras datumintervall skär varandra. Registrera resolutionsbeslutet och behåll ett sätt att undersöka policyändringar och sena korrigeringar utan att osynligt skriva om historien.
Fiktivt fixturarbetsblad och frigöringsgrind
Ett fiktivt fall i nuvarande format innehåller namnutrymmet dmarc-2.0, version 1.0, testing=y och en explicit DKIM väljare. En separat uppfunnen legacy-formad väska saknar den väljaren. Det planerade acceptansarbetsbladet förväntar sig distinkt profilhantering, inte införande av en påhittad väljare. Ytterligare föreslagna rader täcker ett namnavgränsat tillägg, exakt dubblett, överlappande rapport och felaktig inmatning. Ingen har avrättats.
Det exakta ursprungliga kravet kvarstår: Kör äldre och aktuella schemafixturer, förlängningsfall, dubbletter av rapporter och felaktiga indata. Idrifttagningsgrinden är: Validera aktuella primära specifikationer och behåll ett fungerande exempel innan ritning. De bevarade pappersfallen och källgranskningen uppfyller inte acceptansen vid körning. Parsersäkerhet, bakåtkompatibilitet, mänskligt SME-godkännande, produktionsbeteende och publiceringstillstånd förblir öppna tills de nödvändiga testerna och besluten finns.