Definer først spørgsmålet og modtageren
En leverandør kan have brug for beviser for at diagnosticere et signeringsproblem, en justering uoverensstemmelse eller uoverensstemmelse i rapporteringen. Det har sjældent brug for hver rapport for hvert domæne i organisationen. Start med at angive det nøjagtige spørgsmål, det involverede produkt og konto, den påtænkte modtager og hvilken beslutning beviset skal muliggøre. Dette forhindrer en anmodning om "den DMARC data” fra at blive en unødvendig bred offentliggørelse.
Bekræft, at modtageren er den autoriserede support- eller ingeniørkontakt for den relevante service. Et kendt visningsnavn eller videresendt anmodning er ikke nok til at fastslå, at hver vedhæftet fil skal sendes dertil. Udarbejdelse af en pakke er adskilt fra tilladelse til at sende den. Denne artikel beskriver kun forberedelse og godkender ikke en e-mail, upload eller ekstern deling.
Hold skopet bundet til den berørte rute og interval. En leverandør, der undersøger sin egen arbejdsgang for kvittering, bør ikke modtage ikke-relateret medarbejdermail, marketing eller anden leverandørtrafik, blot fordi disse observationer optager den samme samlede fil.
Forstå, hvad rapporten kan afsløre
Samlede rapporter indeholde tekniske observationer og politikinformation, der kan afsløre aspekter af afsenderens infrastruktur og trafik. RFC 9990 diskuterer privatlivsovervejelser for modtagere og rapporterer data. Selv når et felt ikke er en meddelelsestekst, kan det stadig være unødvendigt for en leverandørs opgave. Behandl minimering som en felt-for-felt-beslutning i stedet for at antage, at al aggregeret information er harmløs.
Fejlrapporter have en separat og potentielt mere detaljeret eksponeringsflade under RFC 9991. Bring dem ikke sammen med samlede resuméer under en generisk godkendelse til "rapporter". Identificer rapporttype, indhold og modtagerformål eksplicit. Hvis et diagnostisk spørgsmål kan besvares med et mindre resumé eller redigeret uddrag, skal du foretrække det frem for en komplet rå artefakt. RFC 9990 , afsnit 7.1 og 7.2; RFC 9991 , afsnit 7.1 og 7.2
Byg et datafeltkort før redigering
Feltkortet bør angive hver enkelt kandidatvare, hvorfor det er nødvendigt, om en nøjagtig værdi er nødvendig, den foreslåede behandling og konsekvensen af at fjerne den. Potentielle elementer omfatter det relevante Fra-domæne, signeringsdomæne, vælger, kuvertdomæne, kildeadresse, rapportinterval, optælling og evalueringsresultat. Deres nødvendighed afhænger af spørgsmålet; der er ingen universel bundt, der altid skal sendes.
Nogle nøjagtige tekniske identiteter kan være nødvendige for at diagnosticere justering eller finde en kontospecifik konfiguration. Hvis disse værdier ikke kan deles under det godkendte omfang, skal du forklare den diagnostiske begrænsning i stedet for at erstatte dem med vildledende værdier. Andre identifikatorer kan fjernes eller konsekvent pseudonymiseres, mens relationer bevares. Hold kun en privat kortlægning, når det er nødvendigt og godkendt, og medtag det ikke i leverandørpakken som standard.
Fjern ikke-relaterede rækker og domæner, unødvendige modtageradresser, beskedindhold, interne noter og hemmeligheder. Inkluder aldrig adgangskoder, API-nøgler, sessionstokens eller legitimationsoplysninger i en supportartefakt. Gennemgå filnavne, metadata, skærmbilleder og skjult regnearksindhold samt synlig tekst; et redigeret afsnit garanterer ikke, at den vedhæftede fil minimeres.
Bevar diagnostiske relationer
En nyttig bevisprøve bør bevare sondringen mellem rå autentificeringsresultater og justering. Hvis spørgsmålet vedrører, hvorfor DMARC fejlede, kan udskiftning af hvert domæne med den samme pladsholder slette forholdet, som leverandøren skal forstå. Bevar, om identiteter er ens, relaterede eller forskellige, og mærk tydeligt syntetiske erstatninger, så de ikke forveksles med rigtige DNS navne, der skal forespørges.
Hold rapporteringsintervallet, relevante resultatfelter og omfangsnoter sammen. Hvis kun udvalgte rækker deles, skal du angive, at prøven er filtreret, og identificere udvælgelsesreglen. Ret ikke et resultat for at få eksemplet til at se enklere ud, og antyd ikke, at et filtreret antal repræsenterer organisationens samlede trafik. Giv om nødvendigt en kortfattet analytikerforklaring sammen med de bevarede felter. RFC 9989 , afsnit 4.4; RFC 9990 , afsnit 3.1
Arbejdsark til godkendelse og fastholdelse
Forbered en godkendelsespost med modtager, organisation, produkt, formål, nøjagtige filer eller felter, berørt domæne eller rute, tidsinterval, følsomhed, overførselsmetode og beslutning om opbevaring. Identificer, om sælgeren kun må beholde materialet til sagen, bruge det til et andet formål eller dele det videre. Antag ikke, at et generelt supportforhold tillader ikke-relateret genbrug eller bred adgang.
Beslutningen om opbevaring bør både omhandle leverandørkopien og organisationens arbejdskopi. Registrer den påtænkte varighed eller sletningsudløser, og hvem der kan bekræfte fuldførelsen, hvor det er vigtigt. Dette er en foreslået styringsproces, ikke en påstand om, at en leverandørkontrakt allerede indeholder specifikke vilkår. Hvis de tilgængelige vilkår eller modtageradgang er uklare, skal du løse det før transmission.
Accept kræver, at en anmelder sammenligner den endelige pakke med det godkendte feltkort. Den faktiske vedhæftede fil, ikke blot en beskrivelse, bør kontrolleres for ikke-relaterede rækker, skjulte data og utilsigtede hemmeligheder. En ændret modtager, udvidet datasæt eller nyt formål bør udløse fornyet gennemgang i stedet for at blive behandlet som en harmløs fortsættelse af den samme andel.
Fiktiv støttepakke til én signeringsrute
Forestil dig en fiktiv kvitteringsleverandør, der undersøger en aligned DKIM fiasko. Organisationens rå aggregerede rapport indeholder også medarbejder-mail og kampagneobservationer. Ingen reel rapport eller leverandøranmodning blev tilgået for dette eksempel. Den foreslåede pakke indeholder kun de relevante kvitteringsrute-rækker, det afgrænsede rapporteringsinterval, de relevante identitetsrelationer og en kort forklaring på, hvad der er usikkert.
Medarbejder- og kampagnerækkerne er udelukket, fordi de ikke besvarer leverandørens spørgsmål. Hvis leverandøren har brug for et nøjagtigt signeringsdomæne eller vælger, skal organisationen godkende disse værdier for den pågældende modtager og formål. En redigeret prøve, der skjuler dem, kan stadig være nyttig til en konceptuel diskussion, men kan ikke præsenteres som tilstrækkelig til en live DNS diagnose.
Den endelige godkendelse registrerer også en sagsspecifik afgørelse om opbevaring. Ingen pakke sendes, blot fordi kladden er komplet. Hvis leverandøren senere beder om fuldstændige meddelelseseksempler, er det en ny indholdsanmodning med en anden privatlivsprofil, især hvis den introducerer modtagere eller meddelelsesorganer. Det næste trin er en omfattende gennemgang, ikke automatisk udvidelse.
Beviser og frigivelsesstatus
Kataloget kræver et datafeltkort og godkendt minimal bevisprøve med en eksplicit beslutning om opbevaring. Denne artikel giver kun en forberedelsesmetode og fiktivt pakkedesign. Ingen egentlig prøve er blevet godkendt, ingen modtager løst og ingen transmission eller sælgersletning bekræftet.
Alle seks udløserporte forbliver åbne. En kvalificeret anmelder bør kontrollere, at den foreslåede minimering bevarer det diagnostiske spørgsmål, samtidig med at modtager- og formålsgrænser respekteres. Indhent den nødvendige autorisation for de faktiske data og destination, før nogen reel andel. Et sikkert udarbejdet udkast er værdifuldt fremskridt, men det er ikke bevis for, at sælgeren har modtaget eller håndteret noget.