En bevispakke bør la en annen analytiker forstå hendelsen uten å gjenta innsamlingsarbeidet eller gjette hvilken fil som er autoritativ. Organiser det rundt leserens spørsmål og selve leveringsruten. En stor ZIP av skjermbilder er mindre nyttig enn et lite, sporbart sett med gjenstander med tydelig opprinnelse og uløste spørsmål.
Oppgi hendelsen og dens omfang
Start med en kort saksoppsummering: forventet atferd, observert symptom, berørt tidsvindu, relevant avsender- og mottakeromfang, virksomhetspåvirkning og spørsmålet fortsatt ubesvart. Skille individuelle feil fra bredere trender. Registrer om bevis kom fra en leverandør, en lokal test eller et konstruert undervisningseksempel.
Skill gjeldende hypotese fra etablerte fakta. For eksempel, "en gateway kan ha modifisert kroppen" er en hypotese inntil før-og-etter-bytes eller tilsvarende pålitelige bevis støtter det. EN DKIM feil alene identifiserer ikke det modifiserende systemet. RFC 6376 beskriver signatursjekkene, ikke en automatisk tildeling av ansvar. RFC 6376 del 6.
Ta vare på originalene og lag et manifest
Oppbevar uendrede mottatte meldinger, relevante avsenderlogger, mottakerdiagnostikk og autoriserte DNS observasjoner i et begrenset originalområde. Registrer innsamlingsmetoden, samleren, tid, tidssone og en SHA-256-hash for hver artefakt. Sett desinfiserte derivater i et eget område med sine egne hashes og en transformasjonslogg. En hash bekrefter bytekonsistens mot manifestet; den autentiserer ikke det underliggende kravet.
For DNS bevis, registrer den nøyaktige spørringen, posttype, løser, responstid og returnerte data. Et skjermbilde av dagens rekord er ikke et historisk bevis på gårsdagens konfigurasjon. For meldinger, behold de rå bytene når signaturverifisering er nødvendig, og behold menneskelesbare utdrag som praktiske visninger i stedet for erstatninger.
Bygg en tidslinje per mottaker
Spor innsending, relégodkjenning, mottakerspesifikke avslag, gjenforsøk, endelige svar og varsler som distinkte hendelser. Inkluder kildefilnavn eller hashes for hver rad. RFC 5321 forklarer SMTP aksept og gjenforsøk kontekst; RFC 3464 definerer mottakerblokker for leveringsstatus. RFC 5321, RFC 3464.
Behold originale tidsstempler sammen med normaliserte UTC-verdier. Merk usikre klokkeforskyvninger og manglende hendelser. Ikke utlede postboksplassering fra en relés endelige 250-svar eller utlede et bestemt meldingsutfall fra en samlet DMARC telle. Merk eksplisitt om hver påstand er observert, avledet eller fortsatt hypotetisk.
Inkluder reproduserbare kontroller og begrensninger
Oppgi kommandoene eller skriptet, verktøyversjoner, valgt signatur eller post, input-hasher, forventede observasjoner og faktisk utgang. Unngå å bygge inn legitimasjon eller produksjonssigneringshemmeligheter. En lokal test som bruker en injisert offentlig nøkkel skal si at det ikke skjedde noe DNS oppslag; et syntetisk parsereksempel bør ikke maskere seg som en leverandørevaluering.
For en fullført sjekk, behold den faktiske produksjonen og merk eksplisitt manglende eller endrede artefakter. For en foreslått kontroll merker du at den ikke er utført og oppgir tilgangen eller inndataene som trengs. Ikke fyll en tom bevispakke med forventede resultater presentert som observasjoner.
Gjør neste handling klar
Avslutt med det bekreftede funnet, gjenværende hull, foreslått smal korreksjon, eier og suksesstilstand. Hold autorisasjon for konfigurasjonsendringer og ekstern deling atskilt fra bevisinnsamling. Etter en godkjent reparasjon, legg til en ny identifisert test og bevar det gamle beviset i stedet for å erstatte feilen med et vellykket skjermbilde.
En annen analytiker skal kunne svare på tre spørsmål fra pakken: hva skjedde i henhold til hver kilde, hva som kan kontrolleres uavhengig, og hva som fortsatt krever tilgang eller vurdering. Det er fullføringsstandarden, selv når den ærlige konklusjonen er at de tilgjengelige registreringene ennå ikke kan fastslå en årsak.
Skisser en hypotetisk uløst leveringssak
Anta at en applikasjonslogg registrerer reléaksept, men mottakeren rapporterer ingen melding. Sakssammendraget skal si at destinasjonslevering er uløst, ikke at autentisering mislyktes. En minimal foreslått pakke inkluderer den autoriserte originale innsendingen eller dens beholdte byte, reléets køidentifikator og tidsstempel, sporing per mottaker, eventuelt senere DSN og mottakersideobservasjon når tilgjengelig.
Merk hvert utilgjengelig element som manglende. Neste eier er personen med tilgang til det aktuelle reléet eller mottakersporet; la personen være uoppdelt inntil det faktisk er avtalt. En passende suksessbetingelse er en korrelert disposisjon for den opprinnelige mottakeren og en forklaring på gjenværende gap, ikke bare en annen vellykket sending.
Dette er en hypotetisk pakkeoversikt, ikke leverte filer, en utført hendelsesundersøkelse eller en påstand som en reell organisasjon godkjente innsamling, deling eller oppbevaring.
Gjør pakken nyttig for neste analytiker
- Start med symptom, omfang, tidsvindu og uløst spørsmål.
- Koble hver observasjon til en original artefakt og samlingskontekst.
- Skill originaler, avledninger og hypotetiske forklaringer.
- Inkluder reproduserbare sjekkinnganger og faktiske utganger kun når de utføres.
- Tildel neste bevisforespørsel og dens suksesstilstand uten å finne opp en eier eller godkjenning.