Unngå alt-eller-ingenting-anmeldelsen
En leverandørhjelpeside kan fortsatt sitere RFC 7489 mens den nøyaktig beskriver en gjeldende kontoskjerm eller støttet senderute. Omvendt kan en nylig datert side gjenta historiske protokollråd. Den nyttige gjennomgangsenheten er den individuelle instruksen eller påstanden, ikke alderen på sitatet alene. En revisor bør identifisere hva som forblir gyldig, hva gjeldende standarder endret og hva som avhenger av leverandørens faktiske implementering.
RFC 9989 gir den nåværende kjernen DMARC spesifikasjon og beskriver endringer fra RFC 7489 . Aggregert og feilrapportering er nå spesifisert separat i RFC 9990 og RFC 9991. Bruk disse kildene til å vurdere protokollerklæringer, men ikke behandle dem som bevis på at en leverandør allerede har endret hvert brukergrensesnittfelt eller utplassert evaluator. RFC 9989 , vedlegg C; RFC 9990 , del 1; RFC 9991 , del 1
Bevar den eksakte produktkonteksten
Før du merker en guide, må du registrere dens URL, beholdt dato, produkt, plan eller kontoomfang der det er angitt, region, rute og relevante forutsetninger. Et leverandørmerke kan inneholde flere e-postprodukter med forskjellige konfigurasjonsbaner. En veiledning for en tilpasset SMTP rute gjelder kanskje ikke for en standard API-rute, og instruksjoner for ett vertsbasert e-postprodukt dekker kanskje ikke et annet produkt fra samme selskap.
Hold kontogenererte verdier adskilt fra forklarende eksempler. En guides prøve velger eller DNS mål skal ikke kopieres som en universell produksjonsverdi. På samme måte kan en brukergrensesnitt-instruksjon forbli nyttig selv når den omkringliggende standardforklaringen trenger oppdatering. Bevar denne distinksjonen slik at leseren ikke forkaster en gyldig ombordstigningsforutsetning bare fordi en historisk RFC vises i introduksjonen.
Dette manuskriptet reviderer ikke en navngitt leverandørs nåværende konto eller hevder at en bestemt tjeneste ikke er i samsvar. Den gir en metode for en fremtidig kildebasert gjennomgang. Enhver faktisk produktinstruksjon må kontrolleres mot en lesbar primærveiledning og den autoriserte kontokonteksten før den presenteres som aktuelt.
Klassifiser hver instruksjon etter autoritet
Bruk minst fire merknadskategorier: produktarbeidsflyt, protokollkrav, leverandørspesifikk kvalifikasjon eller policy og forklarende anbefaling. Produktarbeidsflyter trenger gjeldende leverandørbevis. Protokollkrav trenger den aktuelle spesifikasjonsdelen. Leverandørkvalifisering kan være strengere eller ha et annet omfang enn minimumsprotokollen og må ikke generaliseres til alle mottakere. Anbefalinger bør avsløre deres begrunnelse og grenser.
For hver linje, skriv skuespilleren og tilstanden. En mottakers policy-oppdagingsadferd er forskjellig fra en domeneeiers DNS publiseringsoppgave. Et krav om å konfigurere et bestemt kontofelt kan være nødvendig for den tjenesten uten å endre standardens postsyntaks. En rapportdestinasjons mottakstillatelse er forskjellig fra avsenderens forespørsel om å sende rapporter dit.
Når en setning kombinerer kategorier, deler du den opp. For eksempel kan en instruksjon om å angi en rapporteringsadresse være et gyldig UI-trinn mens en påstand om at enhver ekstern adresse automatisk mottar rapporter er ufullstendig. Gjennomgangen bør bevare det nyttige trinnet og legge ved den manglende autorisasjonsbetingelsen i stedet for å erstatte hele veiledningen med generiske råd.
Sammenlign spesifikke endrede konsepter
Den gjeldende kjerneverdien DMARC -versjon forblir DMARC1 . En anmeldelse må ikke finne opp en DMARC2-post eller antyde at oppdatering av en RFC-sitering krever en DNS versjonssvitsj. Den nåværende spesifikasjonen dokumenterer også fjerning av pct, mens det beholdte IANA registeret markerer koden som historisk. Disse fakta støtter å korrigere en påstand om at pct er en gjeldende kjernestandard prøvetakingskontroll uten å bevise hvordan hver distribuert leverandør håndterer det.
Oppdagelse av retningslinjer og bestemmelse av organisasjonsdomene trenger også sammenligning mot gjeldende spesifikasjon i stedet for en gammel forenklet algoritme. Rapporteringserklæringer bør kontrolleres mot RFC 9990 eller RFC 9991 etter behov. Registrer den nøyaktige forskjellen og dens operasjonelle betydning; ikke bruk "DMARCbis endret alt» som erstatning for en vurdering på seksjonsnivå. RFC 9989 , avsnitt 4.7, 4.10 og vedlegg A.6; IANA DMARC Tags-register
Merknadsark og akseptkriterier
Lag et regneark som inneholder veiledningsutdraget, kildeøyeblikksbilde, produktomfang, instruksjonskategori, gjeldende autoritet, foreslått merknad og implementeringsbevis som fortsatt kreves. Tilordne ett av fire utfall: beholdt som aktuelt, beholdt med et omfangsnotat, oppdatert fordi standardkravene er endret, eller uavklart ventende leverandørbevis. Dette er redaksjonelle resultater, ikke påstander om at noe produksjonssystem har bestått en test.
Regnearket skal også identifisere eieren som kan bekrefte kontospesifikke verdier og eventuelle separat autoriserte tester som er nødvendige for å etablere atferd. Hvis leverandørveiledningen er utilgjengelig, merk kildegapet i stedet for å erstatte en generisk oppsettsekvens og kalle den verifisert.
Aksept krever at hver merknad står på sine egne bevis. En anmelder skal kunne se hvorfor et skjermnavigeringstrinn ble beholdt mens en protokollforklaring ble revidert. Hold det originale utdraget og den foreslåtte ordlyden sammen slik at endringen ikke ved et uhell introduserer en ny forpliktelse, funksjon som ikke støttes eller universelt løfte om levering.
Fiktiv gjennomgang av en tidligere sitert oppsettside
Se for deg en fiktiv leverandørside med tre instruksjoner: skriv inn den kontogenererte DKIM poster, legg til en rapporteringsadresse gjennom innstillingsskjermen, og bruk pct som gjeldende standards utrullingskontroll. Siden siterer RFC 7489 . Ingen slik navngitt side ble revidert her; disse oppfunne instruksjonene illustrerer klassifiseringsmetoden.
DKIM trinnet kan forbli gyldig hvis gjeldende produktdokumentasjon og kontoverdier støtter det. Rapporteringsadressetrinnet kan forbli gyldig som en brukergrensesnitthandling mens det kreves en ekstra ekstern autorisasjonsforklaring. PCt-erklæringen vil trenge en merknad med gjeldende standarder, mens leverandørens faktiske håndtering av dette feltet vil forbli et implementeringsspørsmål. En sitering fører derfor til tre forskjellige vurderingsresultater.
Den foreslåtte neste handlingen er å beholde støttede produktinstruksjoner, korrekt standardspråk og skaffe leverandørspesifikke bevis for uløst oppførsel. Det er ikke for å slette alle eksisterende poster, omgå oppsettskrav eller erklære leverandøren usikker. Det fiktive eksemplet viser hvordan en nøye gjennomgang kan være nyttig uten å overheve tilgang eller testresultater.
Hold operasjonell og redaksjonell utgivelse atskilt
En redaksjonell oppdatering kan forbedre en veiledning før produksjonsverifiseringen er fullført, forutsatt at grensene er synlige. Ikke beskriv et kommentert dokument som bevis på at en live-konto er riktig konfigurert. Motsatt bør en vellykket kontotest ikke generaliseres til enhver kundeplan, region eller mottakerimplementering.
Katalogen krever merknader som identifiserer hvilke trinn som forblir gyldige, hvilke endret og hvilke som avhenger av leverandørimplementering. En ekte kildespesifikk annotert veiledning forblir åpen for dette utkastet. Ingen gjeldende utrulling av navngitt leverandør, kontonavigasjon, DNS redigering eller meldingstest er gjort krav på. Porten med originalbevis og de fem andre utløsningsportene forblir åpne.
Før operasjonell publisering, skaff deg den faktiske lesbare leverandørkilden og ta vare på de nøyaktige utdragene, kildedatoer og gjeldende standardreferanser. En kvalifisert anmelder bør sjekke at hver beholdt instruksjon samsvarer med produktomfanget og at uløst implementeringsadferd forblir uløst. Denne tilnærmingen produserer en brukbar guide uten å late som om et gammelt sitat alene beviser enten riktighet eller feil.