En generert post er en beslutningsartefakt
A DMARC rekord generator kan formatere en foreslått policy, men den kan ikke bestemme hvilke legitime avsendere organisasjonen har, hvilken forretningsrisiko den aksepterer eller om en rapporteringsdestinasjon er autorisert. Resultatet bør forklare hvert politikkvalg og forutsetningene bak det. En kopierbar streng uten disse avgjørelsene kan oppmuntre til publisering av en syntaktisk plausibel policy som ikke passer til organisasjonens faktiske e-poststrømmer.
RFC 9989 definerer gjeldende policyformat og mekanisme. Denne artikkelen foreslår krav til en generator og en annotert utgangsgjennomgang. Den hevder ikke at EmailAuth implementerer en generator, produserer en produksjonsklar post eller endrer DNS . De nødvendige originale testsakene og operasjonelle bevis forblir atskilt fra det forklarende rammeverket.
Etabler policydomene og eierskap
Registrer domenet som policyen blir utarbeidet for, bedriftseieren, DNS publikasjonseieren og de legitime sendingsarbeidsflytene i omfang. Skille det eksakte eiernavnet der en policy vil bli publisert fra domeneidentitetene som brukes av avsendere. En generator bør ikke stille velge et overordnet eller underordnet domene basert på en visningsetikett eller en antatt organisasjonsgrense.
Gjeldende policyfunn inkluderer DNS Tree Walk beskrevet av RFC 9989. Generatorens merknad bør forklare det tiltenkte omfanget og eventuelle arverelaterte forutsetninger som trenger gjennomgang, i stedet for å love at en rekord påvirker kun adressen brukeren skrev inn. Den faktiske aktuelle oppførselen avhenger av standarden og mottakerens implementering. Ingen domenehierarki eller eksisterende policy ble spurt under dette arbeidet.
Forklar den forespurte policyen og beredskapen
Den forespurte policyen uttrykker domeneeierens vurderingspreferanse under protokollen; det er ikke en garanti for en mottakers endelige disposisjon eller en erklæring om at enhver legitim avsender er klar. Før du anbefaler håndheving, kreve en avsender-for-sender-beredskapsgjennomgang og en autorisert avgjørelse om gjenværende feil. En generator kan presentere valg og konsekvenser, men den bør ikke finne opp forretningsgodkjenningen bak dem.
Forklare justering valg atskilt fra politikkens alvorlighetsgrad. Det synlige Fra-domenet, autentisert SPF identitet og DKIM signerende domene har definerte relasjoner under DMARC. Strengt og avslappet justering er ikke bare etiketter for sterkere og svakere generell sikkerhet; deres operasjonelle implikasjoner avhenger av organisasjonens domenestruktur og sendetjenester. Behold den valgte begrunnelsen og uløste avhengighetene i den kommenterte utgangen.
Behold gjeldende versjon og tag semantikk
RFC 9989 spesifiserer fortsatt versjonsverdien DMARC1 som skiller mellom store og små bokstaver. En generator bør ikke annonsere et nytt standarddokument som en overgang til DMARC2. Versjonskodens påkrevde plassering og verdi skal valideres i henhold til gjeldende format. Ukjente tagger må ignoreres av protokollbehandling under den formelle definisjonen, så verktøyet bør skille en advarsel om ikke-støttet tag fra en oppfunnet regel om at hver ukjent tag ugyldiggjør hele policyen.
Vedlegg A.6 forklarer fjerning av pct og innføring av t med y- og n-verdier. En strømgenerator bør ikke føre frem en foreldet prosentglidebryter som om den var en gjeldende normativ kontroll, og heller ikke anta at å erstatte hver historisk prosentandel med t er en sikker universell migrasjon. Den skal dokumentere standarden den retter seg mot, eksakt testing semantikk og kompatibilitetsspørsmål som gjenstår for det tiltenkte miljøet.
Behandle rapporteringsdestinasjoner som godkjente mottakere
RFC 9990 definerer samlet rapportering og verifisering av eksterne destinasjoner. En generator bør forklare at publisering av en rapportforespørsel og mottak av rapporter er forskjellige trinn. Den bør identifisere den foreslåtte mottakeren, dataformålet og om den gjeldende autorisasjonen for ekstern destinasjon er på plass. Ikke utlede autorisasjon bare fordi en bruker limte inn en adresse i et skjema.
Denne artikkelen oppgir ikke en rapporteringsadresse, publiserer ikke en autorisasjonspost eller sender data til en tredjepart. Et foreslått utdata bør bruke tydelige ikke-operative plassholdere inntil en destinasjon er godkjent. Merknaden bør også angi at rapportens tilgjengelighet avhenger av mottakere og levering, så å inkludere en URI er ikke en garanti for fullstendige observasjoner. Valg av feilrapportering, hvis de tilbys, krever sin egen støttede spesifikasjon og personverngjennomgang i stedet for å være buntet tilfeldig inn i en samlet rapportinnstilling.
Forklar eksisterende journal og duplikathåndtering
En generator bør spørre hvordan den foreslåtte policyen forholder seg til den eksisterende publiserte tilstanden. Å produsere en annen policykandidat hos samme eier kan skape et annet resultat enn å erstatte en godkjent eksisterende post. Utdataene bør derfor beskrive den tiltenkte nøyaktige diff og bevare gjenopprettingsmateriale, ikke bare si å legge til dette TXT post. Eksisterende urelaterte TXT data bør ikke slettes som en bivirkning av policygenerering.
RFC 1035 definerer TXT poststruktur. Flere strenger i én TXT post er ikke det samme som flere policy-poster. Merknaden og testene bør bevare denne forskjellen slik at en redaktørs visning ikke villeder operatøren. Ingen eksisterende DNS tilstand ble inspisert her; duplikathåndtering forblir et foreslått testkrav i stedet for et verifisert resultat.
Et regneark med kommentert utgang
Lag et regneark med policydomene, publikasjonseier, foreslått post, hver tags betydning, valgt begrunnelse, forutsetningsbevis og godkjenningseier. Legg til referanse for eksisterende tilstand, nøyaktig tiltenkt diff, godkjenning for rapportering-mottaker, kompatibilitetsbegrensninger, verifiseringsplan og tilbakestillingskriterier. Hold generert syntaks atskilt fra godkjennings- og publiseringsstatus. Et utfylt skjema skal ikke automatisk innebære tillatelse til å gjøre en live-endring.
Det påkrevde fixtursettet bør inneholde en positiv gyldig sak, ugyldig versjon eller saker i obligatorisk format, dupliserte policykandidater og tag-atferd som ikke støttes. Angi forventede resultater fra gjeldende standard og produktets presentasjonsregler separat. Behold generatorversjonen, testinngang og observert utgang når autoriserte tester senere kjøres. Dette utkastet har ikke generert eller evaluert disse inventarene og fremsetter ingen krav om implementeringssamsvar.
Fiktiv diagnose: en prosentvis skyveknapp skjuler avgjørelsen
Et fiktivt team bruker et gammelt policyskjema med en prosentvis glidebryter og antar å velge et mindre antall gjør enhver håndhevingsendring trygg. Granskeren spør hvilken standard skjemaet implementerer, hva organisasjonens legitime senderberedskap er og hvordan den foreslåtte utgangen vil oppføre seg hos relevante mottakere. Kontrollens utseende svarer ikke på disse spørsmålene.
Det foreslåtte svaret er å innhente gjeldende standardrelatert atferd, dokumentere policybeslutningen og bekrefte en eksakt endringsplan i stedet for å mekanisk oversette glidebryteren til en annen kode. Ingen reell generator eller leverandør er anklaget for denne oppførselen. Øvelsen er fiktiv, uten registrering generert, DNS modifikasjon eller mottakertest utført. Det illustrerer hvorfor politiske begrunnelser må forbli synlige sammen med syntaks.
Krev bevis før du kaller utgangen klar
Et nyttig generatorresultat angir hvilke innganger som ble levert, hvilke forutsetninger som gjenstår og hva som må skje før publisering. Det kan hjelpe en kvalifisert eier til å ta en konsekvent avgjørelse uten å hevde at formatert tekst etablerer sikker håndhevelse. Den endelige myndigheten forblir hos den godkjente forretningsmessige og tekniske endringsprosessen.
Katalogen krever en kommentert post og positive, ugyldige, dupliserte og ikke-støttede tag-testtilfeller. De originale gjenstandene forblir åpne. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet inneholder et foreslått regneark og en fiktiv diagnose, ikke en klar-til-publiseringspolicy, fullførte tester eller verifiserte funksjoner EmailAuth verktøyet.