Definer spørsmålet og mottakeren først
En leverandør kan trenge bevis for å diagnostisere et signeringsproblem, en justering uoverensstemmelse eller et rapporteringsavvik. Den trenger sjelden hver rapport for hvert domene i organisasjonen. Start med å angi det nøyaktige spørsmålet, produktet og kontoen som er involvert, den tiltenkte mottakeren og hvilken beslutning beviset skal muliggjøre. Dette forhindrer en forespørsel om "den DMARC data» fra å bli en unødvendig bred avsløring.
Bekreft at mottakeren er den autoriserte støtte- eller ingeniørkontakten for den aktuelle tjenesten. Et kjent visningsnavn eller videresendt forespørsel er ikke nok til å fastslå at hvert vedlegg skal sendes dit. Å utarbeide en pakke er atskilt fra tillatelse til å overføre den. Denne artikkelen beskriver kun forberedelse og godkjenner ikke en e-post, opplasting eller ekstern deling.
Hold omfanget knyttet til den berørte ruten og intervallet. En leverandør som undersøker sin egen arbeidsflyt for kvittering bør ikke motta urelatert medarbeiderpost, markedsføring eller annen leverandørtrafikk bare fordi disse observasjonene opptar den samme samlede filen.
Forstå hva rapporten kan avsløre
Samlede rapporter inneholde tekniske observasjoner og policyinformasjon som kan avdekke sider ved avsenderens infrastruktur og trafikk. RFC 9990 diskuterer personvernhensyn for mottakere og rapporterer data. Selv når et felt ikke er en meldingstekst, kan det fortsatt være unødvendig for en leverandørs oppgave. Behandle minimering som en felt-for-felt-beslutning i stedet for å anta at all samlet informasjon er ufarlig.
Feilrapporter ha en egen og potensielt mer detaljert eksponeringsflate under RFC 9991. Ikke sett dem sammen med samlede sammendrag under en generisk godkjenning for "rapporter". Identifiser rapporttype, innhold og mottakerformål eksplisitt. Hvis et diagnostisk spørsmål kan besvares med et mindre sammendrag eller redigert utdrag, foretrekker du det fremfor en fullstendig rå artefakt. RFC 9990 , avsnitt 7.1 og 7.2; RFC 9991 , avsnitt 7.1 og 7.2
Bygg et datafeltkart før redigering
Feltkartet bør liste opp hvert kandidatelement, hvorfor det er nødvendig, om en nøyaktig verdi er nødvendig, foreslått behandling og konsekvensen av å fjerne den. Potensielle elementer inkluderer det relevante Fra-domenet, signeringsdomenet, velger, konvoluttdomene, kildeadresse, rapportintervall, telling og evalueringsresultat. Deres nødvendighet avhenger av spørsmålet; det er ingen universell bunt som alltid skal sendes.
Noen eksakte tekniske identiteter kan være nødvendig for å diagnostisere justering eller finne en kontospesifikk konfigurasjon. Hvis disse verdiene ikke kan deles under det godkjente omfanget, forklar den diagnostiske begrensningen i stedet for å erstatte dem med misvisende verdier. Andre identifikatorer kan fjernes eller konsekvent pseudonymiseres mens relasjoner bevares. Behold en privat kartlegging bare når det er nødvendig og autorisert, og ikke inkludere det i leverandørpakken som standard.
Fjern urelaterte rader og domener, unødvendige mottakeradresser, meldingsinnhold, interne notater og hemmeligheter. Inkluder aldri passord, API-nøkler, økttokens eller legitimasjon i en støtteartefakt. Se gjennom filnavn, metadata, skjermbilder og skjult regnearkinnhold samt synlig tekst; et redigert avsnitt garanterer ikke at vedlegget minimeres.
Bevar diagnostiske relasjoner
En nyttig bevisprøve bør beholde skillet mellom rå autentiseringsresultater og justering. Hvis spørsmålet gjelder hvorfor DMARC mislyktes, kan å erstatte hvert domene med samme plassholder slette forholdet leverandøren trenger å forstå. Ta vare på om identiteter er like, relaterte eller forskjellige, og merk tydelige syntetiske erstatninger slik at de ikke blir forvekslet med ekte DNS navn å spørre etter.
Hold rapporteringsintervallet, relevante resultatfelt og omfangsnotater sammen. Hvis bare utvalgte rader deles, oppgi at prøven er filtrert og identifiser utvalgsregelen. Ikke endre et resultat for å få eksemplet til å se enklere ut, og ikke antyd at et filtrert antall representerer organisasjonens totale trafikk. Om nødvendig, gi en kortfattet analytikerforklaring sammen med de beholdte feltene. RFC 9989 , avsnitt 4.4; RFC 9990 , avsnitt 3.1
Arbeidsark for godkjenning og oppbevaring
Forbered en godkjenningspost med mottaker, organisasjon, produkt, formål, eksakte filer eller felt, berørt domene eller rute, tidsintervall, sensitivitet, overføringsmetode og oppbevaringsbeslutning. Identifiser om leverandøren kan beholde materialet kun for saken, bruke det til et annet formål eller dele det videre. Ikke anta at et generelt støtteforhold tillater urelatert gjenbruk eller bred tilgang.
Oppbevaringsbeslutningen bør ta for seg både leverandørkopien og organisasjonens arbeidskopi. Registrer den tiltenkte varigheten eller slettingsutløseren og hvem som kan bekrefte fullføringen der det betyr noe. Dette er en foreslått styringsprosess, ikke en påstand om at en leverandørkontrakt allerede gir spesifikke vilkår. Hvis tilgjengelige vilkår eller mottakertilgang er uklare, må du løse det før overføring.
Aksept krever at en anmelder sammenligner sluttpakken med det godkjente feltkartet. Selve vedlegget, ikke bare en beskrivelse, bør sjekkes for urelaterte rader, skjulte data og tilfeldige hemmeligheter. En endret mottaker, utvidet datasett eller nytt formål bør utløse fornyet gjennomgang i stedet for å bli behandlet som en harmløs fortsettelse av samme andel.
Fiktiv støttepakke for én signeringsrute
Se for deg en fiktiv kvitteringsleverandør som undersøker en justert DKIM feil. Organisasjonens rå aggregerte rapport inneholder også observasjoner av ansattes e-post og kampanjer. Ingen reell rapport eller leverandørforespørsel ble åpnet for dette eksemplet. Den foreslåtte pakken inneholder kun de relevante kvitteringsrute-radene, det avgrensede rapporteringsintervallet, de relevante identitetsrelasjonene og en kort forklaring på hva som er usikkert.
Medarbeider- og kampanjeradene er ekskludert fordi de ikke svarer på leverandørens spørsmål. Hvis leverandøren trenger et eksakt signeringsdomene eller velger, må organisasjonen godkjenne disse verdiene for den mottakeren og formålet. En redigert prøve som skjuler dem kan fortsatt være nyttig for en konseptuell diskusjon, men kan ikke presenteres som tilstrekkelig for en live DNS diagnose.
Den endelige godkjenningen registrerer også et saksspesifikk oppbevaringsvedtak. Ingen pakke sendes bare fordi utkastet er komplett. Hvis leverandøren senere ber om fullstendige meldingsprøver, er det en ny innholdsforespørsel med en annen personvernprofil, spesielt hvis den introduserer mottakere eller meldingsinstanser. Det neste trinnet er en omfattende gjennomgang, ikke automatisk utvidelse.
Bevis og utgivelsesstatus
Katalogen krever et datafeltkart og godkjent minimal bevisprøve med en eksplisitt oppbevaringsbeslutning. Denne artikkelen gir kun en forberedelsesmetode og fiktiv pakkedesign. Ingen faktisk prøve er godkjent, ingen mottaker løst og ingen overføring eller leverandørsletting bekreftet.
Alle seks utløserportene forblir åpne. En kvalifisert anmelder bør kontrollere at den foreslåtte minimeringen bevarer det diagnostiske spørsmålet samtidig som mottaker- og formålsgrenser respekteres. Før noen reell deling, innhent den nødvendige autorisasjonen for de faktiske dataene og destinasjonen. Et trygt utarbeidet utkast er verdifullt fremskritt, men det er ikke bevis på at leverandøren har mottatt eller håndtert noe.