To parter gjør rapporteringsforholdet
Publisering av en rapporteringsdestinasjon i et domene DMARC policy uttrykker domeneeierens forespørsel. Det krever ikke ensidig at en ikke-relatert destinasjon godtar de resulterende rapportene. Ekstern destinasjonsverifisering beskytter mottakere fra å bli valgt som uvillige rapportmål. Mottakersiden publiserer tillatelse gjennom DNS , mens rapporteringssiden sjekker denne tillatelsen før bruk av den eksterne destinasjonen.
RFC 9990 bruker sin verifiseringsprosedyre når det er relevant Organisasjonsdomene sammenligning viser en ekstern destinasjon for aggregert rapportering. Ikke erstatt den regelen med en forenklet test om at strengene i Fra-adressen og rapportadressen er forskjellige. Det oppdagede policydomenet, destinasjonsverten og organisasjonsdomenekonteksten må beholdes slik at beslutningen om å utføre verifisering er reproduserbar. RFC 9990 , del 4
Konstruer eiernavnet i riktig rekkefølge
Trekk ut destinasjonsverten fra rapporterings-URIen. Legg til _rapport. _dmarc , legg deretter inn domenenavnet som policyen ble hentet fra, og konverter det domenet til en A-etikett om nødvendig. Den resulterende DNS eieren har skjemaet policy-domain._report. _dmarc.destination-host. Det etterspørres TXT poster. Hvis det konstruerte navnet overskrider DNS grensene, kan det ikke foretas en positiv autorisasjonsavgjørelse.
Denne konstruksjonen bruker det faktiske domenet som policyen ble hentet fra. Ikke forkort det til en kjent forelder bare fordi den forelderen ser ut som organisasjonens merkevare. På samme måte er den lokale delen av en mailto-adresse ikke satt inn i DNS eierens navn. Bevar den opprinnelige URIen og den analyserte destinasjonsverten slik at anmeldere kan se hvordan det konstruerte navnet følger av inndataene. RFC 9990 , del 4
Valider svaret i stedet for å gjenkjenne en kjent streng
De returnerte postene analyseres som tag-verdilister. Den obligatoriske v=DMARC1 koden må vises først, og et etterfølgende semikolon er valgfritt. Poster som mislykkes i den angitte parsetesten, forkastes. Minst én gjenværende kvalifiserende post etablerer den eksterne rapporteringsordningen under prosedyren. Et tomt svar, en urelatert TXT verdi eller en rekord med feil versjon gir ikke plassering tillatelse.
DMARC -versjonsverdien skiller mellom store og små bokstaver: DMARC1 er den nødvendige verdien, ikke en tilnærming med små bokstaver eller en nylig oppfunnet protokollversjon. Regler for sammenligning av DNS -navn skal ikke forveksles med versjonsverdiens krav til store og små bokstaver. En gjennomgang bør bevare de eksakte svarbytene og postgrensene i stedet for å normalisere bort detaljer før validering. RFC 9990 , del 4; RFC 9989 , avsnitt 4.7 og 4.8
Respekter overstyring og feilatferd
En autorisasjonspost kan gi en rapporterende destinasjonsoverstyring under prosedyren. Den overordnede URIen må bruke den samme destinasjonsverten som ble trukket ut i begynnelsen. Denne begrensningen forhindrer et autorisasjonssvar fra å omdirigere prosessen til en kjede av ikke-relaterte mottakere. Hvis bekreftelsen inneholder en overstyring med en annen vert, må ikke rapportgeneratoren generere en rapport til verken den opprinnelige eller overstyrte URIen.
Hvis verifiseringen ikke bekrefter autorisasjon, må den eksterne URI-en ignoreres. En midlertidig DNS feil har sin egen behandling: mottakeren kan velge å midlertidig mislykkes med levering slik at verifiseringstesten kan gjentas senere. Behold tillatelsen som MAI, ikke en universell garanti for gjentatt forsøk eller en beskrivelse av en testet implementering. En vellykket DNS sjekk beviser fortsatt ikke at destinasjonspostboksen eksisterer, aksepterer rapportstørrelsen eller mater det tiltenkte kundedashbordet. RFC 9990 , del 4
Skill mellom forespørsler om aggregerte og feilrapporter
Til samlede rapporter, prosedyren er knyttet til rua. Feilrapportering spesifiseres separat i RFC 9991. For eksterne feilrapportdestinasjoner krever det dokumentet den samme eksterne verifiseringsprosedyren med ruf erstattet der rua vises. Ikke behandle feilrapportering som automatisk aktivert bare fordi samlede rapporter flyter, eller kopier samlet destinasjonshåndtering uten å bekrefte den separate rapporttypen.
Feilrapporter skape ytterligere bekymringer om dataeksponering fordi innholdet kan være mer detaljert enn samlede sammendrag. En korrekt DNS autorisasjonspost er ikke en erstatning for en organisasjons beslutning om hvilke data som kan deles, med hvem og til hvilket formål. Dette manuskriptet gir ingen tillatelse til å be om, overføre eller laste opp faktiske rapporter. Ethvert reelt oppsett må tilfredsstille gjeldende personvern-, mottaker- og driftsgodkjenninger. RFC 9991 , seksjon 5 og 7
Fiktivt arbeidsark for konstruksjon og aksept
Anta at en fiktiv policy ble hentet fra blue.example.com og ber om samlede rapporter på mailto:reports@red.example.net. Den konstruerte autorisasjonseieren er blue.example.com._report._dmarc.red.example.net . Et hypotetisk TXT -svar hvis fullstendige verdi er v=DMARC1; tilfredsstiller det illustrerte versjon-første-kravet. Ingen DNS spørring ble utført, og dette eksemplet hevder ikke at navnene har publiserte poster.
Regnearket bør beholde policyoppslagsresultatet, oppdaget policydomene, original rapporterings-URI, destinasjonsvert, organisasjonsdomenesammenligning, konstruert eier, spørringstype, tidsstempel, eksakt returnerte poster og parseresultat. Legg til et eget felt for enhver overstyring og bekreft vertsbegrensningen. En anmelder skal kunne rekonstruere navnet uten å stole på et skjermbilde fra en leverandør eller en DNS editors forkortede visning.
Bruk en andre akseptseksjon for innsamling: tiltenkt konto, destinasjonspostboks, autorisert rapporttype og rørledningseier. Disse feltene beskriver en planlagt verifiseringsarbeidsflyt, ikke fullført bevis for inntak. Hold DNS relasjonsresultatet forskjellig fra kvittering, parsing, leietakerattribusjon og dashbordpresentasjon. En tillatelsessjekk kan lykkes mens en annen del av innsamlingsbanen forblir uløst.
Publisering og implementering holder
Katalogen krever konstruksjon av det eksakte autorisasjonsoppslaget fra kilde- og destinasjonsdomener og verifisering av svaret. Dette utkastet gir kun en fiktiv konstruksjon. Et faktisk svar, original spørringsutskrift og implementering av mottakerdomene forblir åpne. Ingen DNS post ble publisert, ingen postboks ble åpnet og ingen rapport ble overført.
Før utgivelse som en operasjonell gjennomgang, innhent autorisert bevis for det eksakte produksjonsforholdet og få en kvalifisert anmelder bekrefte policy-oppdagelseskonteksten, versjonsanalyse og overstyringshåndtering. Ta vare på kildedatoen og skille standardkrav fra leverandørspesifikk kontointroduksjon. Alle seks utgivelsesportene forblir åpne, inkludert originale bevis, menneskelig vurdering, kildeanvendelse, produksjonsruter, visuell tilgjengelighet og eierfrigivelse.
En senere endring av destinasjons- eller policy-discovery-domenet kan endre den nødvendige autorisasjonseieren. Behandle det som et nytt omfangsforhold for å verifisere i stedet for å anta at en gammel positiv sjekk dekker hver fremtidig rapporteringsadresse. Det nyttige resultatet er en reviderbar tillatelseskjede, ikke bare en kopiert TXT verdi.