Beschouw de parser-upgrade als een wijziging van het datacontract
Een rapportverzamelaar kan diagrammen blijven weergeven, maar verliest de verschillen waarvoor het bijgewerkte aggregatieformaat bedoeld was. Een RFC 9990 Migratie vereist daarom meer dan het accepteren van een nieuwe bestandsnaam of het negeren van validatiefouten. Definieer welke draadformaten worden herkend, hoe hun velden in het interne model worden opgenomen en hoe incompatibele of verdachte invoer wordt afgehandeld voordat de productie-opname wordt gewijzigd.
Houd bronontvangst, decompressie, XML-parsing, schema-interpretatie en aggregatie als afzonderlijke fasen. Elk ervan moet een begrensd resultaat opleveren en voldoende herkomst behouden voor diagnose. Dit artikel stelt dat ontwerp en de bijbehorende testinventarisatie voor. Het biedt geen ingezette parser, uitgevoerde armaturen of bewijs dat een bestaande verzamelaar aan de nieuwe specificatie voldoet.
Identificeer het formaat zonder de DNS versie te wijzigen
RFC 9990 Bijlage A definieert het huidige XML-schema met naamruimte urn:ietf:params:xml:ns:dmarc-2.0. Het optionele versie-element heeft de waarde 1.0 onder sectie 3.1.1.2 . Deze identificatiegegevens beschrijven het rapportformaat; geen van beide betekent dat een domein v=DMARC2 in DNS moet publiceren. De DMARC beleidsversie blijft beheerst door RFC 9989 sectie 4.7.
Een compatibiliteitsontwerp moet een ondersteund verouderd profiel afzonderlijk van het huidige profiel herkennen. Behoud welk profiel is geselecteerd en waarom. Hernoem een onbekende naamruimte niet om een invoer te valideren, voeg niet stilletjes ontbrekende verplichte velden in en herinterpreteer een oud rapport niet als actueel, alleen maar omdat het hoofdelement feedback heet. Onbekende invoer moet een expliciete, niet-ondersteunde of in quarantaine geplaatste uitkomst krijgen.
Bewaar de originele rapportbytes onder een passend toegangs- en bewaarbeleid, naast een samenvatting en genormaliseerde interpretatie. Als een latere parsercorrectie de resultaten verandert, maakt die scheiding herverwerking mogelijk. Het voorkomt ook dat een genormaliseerd record wordt aangezien voor precies wat de verslaggever heeft verzonden.
Behoud de beleidscontext en de betekenis van de afstemming
De huidige policy_published-structuur bevat optionele detectie_methode en testinformatie. Ontdekking kan worden gerapporteerd als psl of treewalk, en testen heeft de t-waarde. Een ontbrekend optioneel veld is geen bewijs van een bepaalde implementatieversie. RFC 9990 sectie 3.1.1.5 definieert deze velden en hun reikwijdte.
Houd policy_evaluated gescheiden van auth_results. De voormalige records DMARC-gerelateerd uitlijning resultaten en instelling; de laatste bevat authenticatieresultaten vóór die DMARC interpretatie. Een rauw DKIM pas van een niet-gerelateerd domein mag tijdens normalisatie niet worden gepromoveerd tot een uitgelijnde pas. Behoud de overschrijvingsredenen in plaats van het authenticatieresultaat te wijzigen zodat het overeenkomt met de uiteindelijke beschikking. Paragrafen 3.1.1.9 en 3.1.1.11 beschrijven die scheiding.
Huidige DKIM resultaatinvoer vereist de keuzeschakelaar. Een verouderd record zonder een record mag geen verzonnen waarde krijgen, zoals standaard, om aan het huidige schema te voldoen. Leg de ondersteunde oudere interpretatie of de validatiefout vast. Meerdere handtekeningen, optionele envelopinformatie en beleidswijzigingen tijdens een rapportperiode vereisen ook expliciete weergave; Als je ze voortijdig laat instorten, kan de uitleg die een analist nodig heeft, worden uitgewist.
Verwerk extensies zonder de validatie op te geven
De specificatie biedt uitbreidingspunten met naamruimte op gedefinieerde locaties. De aan- of afwezigheid van een extensie is op zichzelf geen fout, en willekeurige, onbekende elementen zijn niet automatisch overal geldig. RFC 9990 secties 3.2 en 5 het onderscheid leveren. Behoud de ondersteunde extensie-inhoud of begrensde, ondoorzichtige gegevens zonder dat deze de kernveldbetekenissen kan overschrijven.
Behandel archief- en XML-invoer als niet-vertrouwd. Paragraaf 8.1 identificeert de risico's van uitputting van hulpbronnen bij decompressie en parsering. Voorgestelde implementatiecontroles omvatten limieten op gecomprimeerde en uitgebreide grootte, nesting, aantal elementen en verwerkingstijd, plus het uitschakelen van externe entiteitsresolutie en netwerkherstel. Geef door het rapport geleverde tekst weer als gegevens. Dit zijn defensieve ontwerpaanbevelingen, geen beweringen dat de verzamelaar tests voor kwaadaardige invoer heeft doorstaan.
Verkeerd opgemaakte invoer mag niet in gewone aggregaten terechtkomen alsof deze geldig is. Paragraaf 3.1.1 beveelt aan om niet-conforme rapporten te negeren en tegelijkertijd een voorzichtige poging toe te staan om bepaalde gegevens te gebruiken. Als een product gedeeltelijk herstel ondersteunt, label het resultaat dan en houd het buiten de normale beslissingstotalen totdat het herstelbeleid is beoordeeld. Stille dwang is vooral gevaarlijk als een grafiek compleet lijkt.
Maak van dubbele afhandeling een expliciet beleid
Report-ID is bedoeld om dubbele herkenning te bevorderen, maar een enkele identificatie mag niet worden aangenomen dat deze globaal uniek is voor niet-verwante reporters. Paragraaf 3.5.4 herkent exacte duplicaten en overlappende informatie en laat de afhandeling over aan de consument. Behoud de verslaggever- en beleidscontext, rapportageperiode, identificatie en inhoudsoverzicht bij het voorstellen van deduplicatieregels.
Een exacte herhaling en een gewijzigd rapport over overlappende tijd zijn niet noodzakelijk hetzelfde geval. Vermijd het eenvoudigweg optellen van beide of het weggooien van één omdat hun datumbereiken elkaar kruisen. Leg het resolutiebesluit vast en behoud een manier om beleidswijzigingen en late correcties te onderzoeken zonder de geschiedenis onzichtbaar te herschrijven.
Fictief armatuurwerkblad en ontgrendelingspoort
Een fictieve case in het huidige formaat bevat de dmarc-2.0 naamruimte, versie 1.0, testen=y en een expliciete DKIM selector. Een afzonderlijk uitgevonden, legacy-vormige behuizing mist die selector. Het geplande acceptatiewerkblad verwacht een duidelijke profielafhandeling, en geen invoeging van een verzonnen selector. Extra voorgestelde rijen hebben betrekking op een extensie met een naamruimte, een exact duplicaat, een overlappend rapport en verkeerd opgemaakte invoer. Geen enkele is geëxecuteerd.
De exacte oorspronkelijke vereiste blijft: voer verouderde en huidige schema-fixtures, uitbreidingsgevallen, dubbele rapporten en verkeerd opgemaakte invoer uit. De inbedrijfstellingspoort is: Valideer de huidige primaire specificaties en bewaar een uitgewerkt voorbeeld voordat u het opstelt. De bewaarde papieren cases en de bronbeoordeling voldoen niet aan de runtime-acceptatie. Parserbeveiliging, achterwaartse compatibiliteit, menselijke MKB-goedkeuring, productiegedrag en publicatieautorisatie blijven open totdat de vereiste tests en beslissingen bestaan.