Sikke et jokertegn bevidst udvider
En rapport, som forbrugeren kan være villig til at modtage DMARC rapporter for ethvert domæne i stedet for at offentliggøre én godkendelsesejer for hvert forhold. RFC 9990 tillader eksplicit en DNS post med jokertegn til det formål. Dens eksempel placerer en TXT post ved *. _report._dmarc.example.com med mindst v=DMARC1. Dette er en bred opt-in fra det modtagende domæne, ikke en mekanisme, der beviser, at hver rapporterende kunde er blevet undersøgt.
Sondringen er operationelt vigtig. En udbyder kan lovligt vælge et bredt indtag, mens den separat kræver verifikation på kontoniveau, før de viser data til en kunde. DNS posten implementerer ikke disse kontokontroller. En sikkerhedsgennemgang bør identificere nøjagtigt, hvilken grænse jokertegnet ændrer, og hvilke grænser forbliver ansvaret for den modtagende applikation og dens ejere. RFC 9990 , afsnit 4
Hold nøjagtige forespørgsler synlige under jokertegnet
Reporteren konstruerer stadig autorisationsopslaget fra det domæne, hvor politikken blev hentet, _rapporten. _dmarc etiketter og destinationsværten. Et jokertegn er en DNS udgivelsesstrategi, der kan besvare disse forespørgsler; det fjerner ikke behovet for at forstå den forespurgte ejer eller den returnerede værdi. Bevar den nøjagtige ejer og svaret, når du verificerer et bestemt forhold.
Det bekræftende svar skal bestå parsingreglerne for ekstern verifikation, inklusive obligatorisk først v=DMARC1. Versionsværdien forbliver DMARC1 med det påkrævede tilfælde. En administrators hensigt om at bruge et jokertegn er ikke et bevis på, at en bestemt forespørgsel løses som forventet i det installerede DNS træ. Præcise navneregistreringer og DNS struktur kan påvirke reel opløsning, så foreslåede test skal bevare det faktiske svar i stedet for at antage, at et skærmbillede beviser dækning. RFC 9990 , afsnit 4; RFC 9989 , afsnit 4.7
Adskil indtagstilladelse fra ejerskab og dataadgang
Et jokertegn siger, at det modtagende domæne er villig til at modtage de rapporter, der er omfattet af protokolarrangementet. Det fastslår ikke, at en person, der logger på et dashboard, kontrollerer domænet, der er navngivet i en rapport. Det fastslår heller ikke, at afsenderen af en uploadet artefakt er troværdig, eller at en rapport tilhører den konto, der modtager den.
Definer acceptkrav på applikationsniveau separat: domæne-til-lejer-binding, autentificeret adgang, herkomstsporing, duplikathåndtering og gennemgang af uventede domæner. Disse er foreslåede kontroller, ikke påstande om en implementeret EmailAuth platform. En rapport, der nævner en organisation, bør ikke automatisk oprette et ejerskabsforhold eller afsløre data for den første konto, der gør krav på navnet.
Hold fakturering, onboarding og datagodkendelse uden for DNS slutningen. Bred villighed til at modtage trafik er ikke samtykke til at tilmelde en organisation i en betalt tjeneste eller offentliggøre dens observerede konfiguration. Hvis en arbejdsgang har brug for disse handlinger, kræver den eksplicitte beslutninger og beviser ud over jokertegnposten. Gennemgangen bør navngive den ansvarlige ejer for hver grænse i stedet for at behandle et enkelt DNS resultat som en omfattende godkendelse.
Redegør for misbrug og ressourcepres
RFC 9990 advarer om, at rapportindhold kan angribe dekomprimerings- eller XML-parseren, og at rapportdata kan være forfalsket. En bred indtagstjeneste bør derfor antage, at tilladelse til at modtage rapporter ikke gør enhver ankommende fil sikker eller nøjagtig. Kapacitetsplanlægning, parsergrænser og herkomstkontrol hører sammen med autorisationsdesignet.
Foreslå afgrænsede meddelelsesstørrelser, dekomprimerede størrelsesgrænser, parsingtidsbudgetter, køisolering og advarsler om uventet kildevolumen. De numeriske værdier skal vælges og testes for det faktiske miljø i stedet for at kopieres fra en opfundet universel grænse. Bevar afvisningsårsager og undgå at tillade én støjende kilde at skjule ikke-relateret kundebevis. Ingen af disse kontroller hævdes at være installeret eller testet her. RFC 9990 , afsnit 8.1 og 8.2
Tilbagetrækning og cachelagt godkendelse
En rapportforbruger, der er overvældet af volumen, kan fjerne den bekræftende DNS post, men RFC 9990 bemærker, at positiv caching kan forsinke effekten så længe som postens TTL. Lov ikke øjeblikkelig ophør af rapporter efter en DNS ændring. Indtagssystemer skal muligvis også håndtere rapporter, der allerede er genereret eller i kø uafhængigt af den friske opslagstilstand.
En tilbagetrækningsplan bør identificere registreringsejeren, godkendelsesstien, relevant TTL-bevis, indtagelsesadfærd under overgangen og kommunikationsansvar. Fjernelse af et jokertegn kan påvirke mange legitime forhold på én gang. Et foreslået skift til eksplicit per-domæne-autorisation kræver en opgørelse over disse relationer og en verifikationsplan, ikke blot en rekord sletning.
Bevar sondringen mellem DNS tilbagetrækning og tilbagekaldelse af applikationsadgang. Fjernelse af modtagelsestilladelse sletter ikke i sig selv lagrede rapporter, lukker kundekonti eller tilbagekalder eksisterende brugersessioner. Det er separate kontroller med separate autorisations- og opbevaringsimplikationer. RFC 9990 , afsnit 4
Fiktiv grænsegennemgang og testdesign
Overvej en fiktiv forbruger på reports.example.net , der foreslår *. _report._dmarc.reports.example.net med værdien v=DMARC1; . For en hypotetisk politik på blue.example.com ville den nøjagtige forespørgsel være blue.example.com._report._dmarc.reports.example.net . Ingen forespørgsel, udgivelse eller DNS opstilling blev udført for dette eksempel.
Planen med positive tilfælde bevarer den nøjagtige forespørgsel og bekræfter, at den returnerede godkendelsesværdi består parsing. Den negative sagsplan skal vælges med omhu: et andet kildedomæne, der er rettet til den samme bredt autoriserede destination, er ikke nødvendigvis uautoriseret, fordi jokertegnet med vilje dækker kildedomæner generelt. I stedet kan en separat styret destinationsvært uden tilladelse illustrere grænsen for den ydre destination, forudsat at enhver faktisk armatur er godkendt og isoleret.
Arbejdsarket skal angive jokertegnsejeren, forventet dækning, nøjagtige testejere, svar, versionsparsing, destinationsværtsgrænse og kontrol af lejers adgang. Det bør også registrere tilbagerulningsplanen og begrænsninger for rapportbehandling. Forventede resultater er designhypoteser, indtil faktiske afgrænsede test udføres; de må ikke mærkes bestået, blot fordi ræsonnementet er plausibelt.
Uafklarede originale beviser og frigivelsesporte
Kataloget kræver den nøjagtige autorisationsejer og svar, inklusive en positiv test og en uautoriseret-destinationstest. Disse oprindelige observationer forbliver åbne. Dette manuskript leverer et foreslået testdesign og fiktive navne, ikke en fungerende jokertegnimplementering eller en vurdering af kontoadgang.
Før offentliggørelse som en verificeret driftsvejledning skal en kvalificeret anmelder inspicere de faktiske DNS svar og bekræfte, at den negative test virkelig krydser den tilsigtede autorisationsgrænse. Originale beviser, menneskelig gennemgang, kildeanvendelighed, produktionsruter, visuel tilgængelighed og ejerudgivelse forbliver åbne. Ingen ekstern kontakt, rapportupload eller DNS ændring blev udført for dette arbejde.