Spør hva den foreslåtte oppgraderingen faktisk endrer
En påstand om at en plattform tilbyr en DMARCbis oppgraderingen bør identifisere gjeldende standard, implementeringsatferden som endres og beviset på at endringen fungerer. Det bør ikke aksepteres som en forespørsel om å bytte en DNS post til en oppfunnet DMARC versjon. Den beholdte strømmen RFC 9989 spesifiserer fortsatt den store og små bokstavssensitive versjonsverdien DMARC1 . Et nytt standarddokument og en ny implementeringsutgivelse er ikke det samme som et nytt versjonstoken i den publiserte policyen.
Denne artikkelen foreslår en standardrelatert beredskapsgjennomgang. Den hevder ikke at EmailAuth implementerer RFC 9989 fullstendig, at hver mottaker har tatt det i bruk eller at en oppgradering ble utført. Ingen DNS post, parser, mottaker eller produksjonskonfigurasjon ble endret. Gjennomgangen bør skille normative endringer, leverandørimplementeringskrav og observert interoperabilitet før noen godkjenner en utrulling.
Avvis snarveien for versjonsbytte
RFC 9989 sin policy-record-definisjon sier at versjonskodens eneste mulige verdi er DMARC1 og at en ellers annen versjonsverdi fører til at posten ignoreres under den angitte behandlingen. Et forslag om å publisere v=DMARC2 er derfor ikke en standardbasert migreringsinstruksjon fra denne RFC. Be forslagsstilleren om å identifisere den eksakte delen som støtter enhver anbefalt postendring i stedet for å stole på en produktetikett.
Den samme forsiktigheten gjelder for å gi nytt navn til en dashbordinnstilling. En innstilling kalt DMARCbis kan aktivere en parserfunksjon, en policy-oppdagelsesalgoritme eller rapporteringsfortolkning, men dens betydning er produktspesifikk inntil den er dokumentert. Registrer den faktiske støttede oppførselen, utgivelsesversjonen og begrensninger. Ikke anta at veksling av en innstilling oppdaterer eksterne mottakere, omskriver hver post riktig eller verifiserer alle legitime sendearbeidsflyter.
Inventar de relevante standardene endres
Bruk RFC 9989 endringsdiskusjon og normative seksjoner for å bygge en fokusert sjekkliste. Et viktig område er DNS-basert policy og oppdagelse av organisasjonsdomene, inkludert DNS Tree Walk. Det er en implementeringsatferd, ikke bare en ny streng som skal settes inn i en eksisterende post. En leverandør som krever støtte bør forklare hvilken oppdagelse og justering saker den håndterer og gir omfattende bevis for den faktiske produktversjonen.
En annen eksplisitt endring er fjerning av pct-taggen fra gjeldende spesifikasjon. Vedlegg A.6 forklarer historien og introduserer testkoden t med verdiene y og n, beskrevet som analoge i anvendelse med de tidligere pct-verdiene 0 og 100. Det rettferdiggjør ikke en generell mekanisk erstatning av hver historisk prosentverdi eller et løfte om at hver mottaker implementerer den nye oppførselen. Gjennomgå den eksakte gjeldende semantikken og den relevante distribusjonspopulasjonen før du foreslår en policyforskjell.
Hold protokollkrav atskilt fra reglene for leverandørkvalifisering
En leverandør kan publisere produktkvalifikasjonskrav som refererer til eksisterende distribusjonskonvensjoner. Disse kravene trenger sin egen nåværende kildegjennomgang og bør ikke skrives om i det stille fordi et protokolldokument er endret. Omvendt omdefinerer ikke en historisk leverandørinstruksjon det normative innholdet i RFC 9989 . Registrer den tilsynelatende forskjellen, kildedatoene og implementeringsspørsmålet som trenger løsning i stedet for å late som om de to lagene er identiske.
Dette manuskriptet krever ikke universell mottakerstøtte for testetiketten, trevandringsadferd eller noen annen revidert funksjon. Beredskapsvurderingen skal identifisere hvilke komponenter organisasjonen kontrollerer og hvilke som er eksterne. En avsender kan bare oppdatere sin egen implementering eller policy innenfor det støttede omfanget; den kan ikke tvinge alle mottakende systemer til å oppgradere. Kompatibilitetskonklusjoner trenger derfor påviste, avgrensede bevis snarere enn en global adopsjonsantagelse.
Separate rapporteringsstandarder og parserberedskap
RFC 9990 definerer DMARC aggregert rapportering som en egen spesifikasjon. En plattforms policyevaluator og rapportinntaksparser kan ha forskjellige oppgraderingskrav. Spør hvilke rapporteringsformater, felt og valideringsatferd som støttes, og hvordan eldre beholdte rapporter fortsatt kan tolkes. Ikke anta at endring av en implementering av policyoppdagelse automatisk oppdaterer hver rapporteringsarbeidsflyt eller historisk analyse.
Fest produktutgivelsen og beholdte standardreferanser som brukes for vurderingen. Hvis en parser støter på et felt eller en rapportvariant som ikke støttes, bør oppførselen dokumenteres og testes i stedet for å tolkes som null aktivitet. Ta vare på den opprinnelige rapportens opprinnelse og skille manglende observasjoner fra autentiseringsresultater. Ingen rapportparser ble utøvd for denne artikkelen, og ingen testarmatur er representert som en faktisk mottakerrapport.
Bygg en standard-til-implementering-matrise
Opprett én rad per relevant krav med RFC-seksjon, normativ atferd, gjeldende produktadferd, foreslått endring, berørt komponent, bevisreferanse og uløst begrensning. Separat publisering av avsenderpolicy, mottakerevaluering, oppdagelse av organisasjonsdomene, rapportgenerering og rapportinntak. En plattform kan utføre bare noen av disse rollene, så ikke-støttede roller bør merkes utenfor omfanget i stedet for å regnes som implikert implementert.
Legg til representative tilfeller for eksisterende gyldige retningslinjer, ugyldige versjonsverdier, oppdagelsesgrenser, justeringsforhold og rapporteringskompatibilitet der det er aktuelt. De nøyaktige armaturene bør utformes av en kvalifisert anmelder i forhold til den normative teksten og produktets støttede rolle. Dette utkastet gir ikke en pakke for implementeringssamsvar eller påstander om at et lite sett med eksempler beviser fullstendig samsvar. Hvert observert resultat trenger at input, produktversjon og forventet oppførsel beholdes.
Knytt enhver postendring til avsenderens beredskap
Hvis vurderingen foreslår en endring DNS policy, utarbeide en eksakt diff, eierskapsregister, forretningsgodkjenning, verifiseringsplan og tilbakestillingskriterier. Hold legitime sendingsarbeidsflyter synlige gjennom en avsender-for-sender-beredskapsmatrise. En standardoppgradering beviser ikke at hver leverandør har justert autentisering eller at enhver kritisk arbeidsflyt vil fortsette upåvirket. Ikke bruk en ny implementeringsetikett som grunn til å hoppe over operativ beredskap.
Registrer hva endringen kan og ikke kan demonstrere. Autoritative DNS bevis kan vise publisering på et bestemt tidspunkt; pålitelig mottatt meldingsbevis kan vise et scoped autentiseringsresultat; samlede rapporter kan vise mønstre innenfor deres beholdte dekning. Ingen alene etablerer universell interoperabilitet. Tilbakeføringsplanlegging må ta hensyn til bufret tilstand og eksterne implementeringsforskjeller, ikke bare muligheten til å gjenopprette en gammel konfigurasjonsfil.
Fiktiv diagnose: en forespurt DMARC2-post
En fiktiv leverandør foreslår en oppgradering og ber en kjøper endre policyens versjonsverdi til DMARC2. Kjøperen ber om standardreferansen og finner at RFC 9989 fortsatt spesifiserer DMARC1 . Den foreslåtte versjonsbytteren avvises som ikke støttet, mens den bredere implementeringsgjennomgangen fortsetter: Leverandøren kan ha legitime endringer i oppdagelses- eller rapporteringsatferd som trenger separat bevis.
Teamet ville be om en scoped beredskapsmatrise og demonstrerte resultater for selve produktutgivelsen i stedet for å godta eller avvise hele oppgraderingen basert på markedsføringsnavnet. Dette er en fiktiv gjennomgangsøvelse, ikke en reell leverandørinstruks eller en observert produksjonsfeil. Ingen post ble publisert og ingen mottaker ble testet. Eksemplet viser hvordan et presist standardspørsmål kan skille en falsk snarvei fra potensielt nyttig implementeringsarbeid.
Krev demonstrert omfang før du kaller oppgraderingen fullført
En nyttig konklusjon identifiserer de standardtilknyttede endringene som er implementert, rollene som dekkes, bevisene som er beholdt og den eksterne kompatibiliteten som fortsatt er ukjent. Det skal ikke stå at organisasjonen nå bruker versjon to eller at alle mottakere oppfører seg enhetlig. Oppgraderingen er en implementering og beredskapsvurdering, ikke en universell bryter.
Katalogen krever en standardrelatert beredskapsvurdering og demonstrerte implementeringsresultater med omfang. De opprinnelige resultatene forblir åpne. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet gir en gjennomgangsmetode og et fiktivt eksempel, ikke samsvarsbevis, en distribuert migrering eller et krav om fullstendig EmailAuth støtte.