Redaktion er en evidenstransformation. Det kan gøre en prøve mere sikker at diskutere, mens den fjerner de nødvendige oplysninger for at besvare det oprindelige tekniske spørgsmål. Start med at definere dette spørgsmål: overskriftsfortolkning, domænejustering, routing, signaturbekræftelse eller indholdsfiltrering. Minimumsanvendelige data er forskellige for hver opgave.
Bevar originalen og identificer derivatet
Gem den originale meddelelse på et begrænset sted, og beregn dens SHA-256-fingeraftryk på byteniveau. Lav en separat kopi til desinficering. Optag samleren, indsamlingsmetoden, tidspunktet og den originale hash; optag derefter en ny hash for derivatet. En hash understøtter senere integritetssammenligninger, men beviser ikke sandheden af beskeden eller hvem der sendte den.
Overskriv ikke den eneste original eller mærk ikke en redigeret fil "rå original". Meddelelsesoverskrifter kan indeholde modtageradresser, interne værter, offentlige og private IP-oplysninger, sporings-URL'er og identifikatorer. MIME dele og vedhæftede beskeder kan gentage følsomme oplysninger, der er fraværende i den synlige krop. RFC 5322 beskriver meddelelsesstruktur; redaktionsarbejdsgangen her er en operationel anbefaling, ikke en foreskrevet redaktionsstandard. RFC 5322 sektion 2 og 3.
Bevar de relationer, der er nødvendige for diagnosen
For en diskussion om domænejustering skal du holde forholdet mellem synlig fra, kuvertidentitet og signeringsdomæner klart. Udskiftning af hvert domæne med den samme pladsholder kan fremstille justering; udskiftning af justerede domæner med ikke-relaterede pladsholdere kan ødelægge det. Hvis rigtige domæner ikke kan deles, skal du angive en eksplicit illustrativ mapping, der bevarer forholdet, og angive, at ægte DNS ikke kan kontrolleres fra derivatet.
Til routing skal du bevare hop-rækkefølgen og tydeligt mærke fjernede værter eller adresser. Til tidslinjeanalyse skal du beholde tidszoneforskydninger og forklare enhver tidsforskydning. Til leveringsstatusanalyse skal du beholde grænser for modtagerblok, handling, status og relevant diagnostik, mens du fjerner ikke-relateret beskedindhold. RFC 3464 definerer disse per-modtager-felter. RFC 3464 afsnit 2.
Lov ikke signaturbevarende redaktion
Ændring af en signeret header eller signeret body kan gå i stykker DKIM. Nogle hvide mellemrumsændringer overlever afslappet kanonisering, men dette er ikke en generel redaktionsgaranti. Selv en ændring uden for en signaturs dækning kan ændre en anden signatur eller fjerne kontekst, der er nødvendig for at fortolke tillid. Bevar signerede bytes, når spørgsmålet kræver kryptografisk verifikation. RFC 6376 afsnit 3.4 og 5.
En redaktionslog skal identificere hver transformation og den diagnostiske evne, den fjerner. Gør ikke krav på, at et derivat bevarer signaturbekræftelse, blot fordi det stadig viser en DKIM-Signature felt. Intet desinfektionsmiddel kan antages at være komplet uden gennemgang af det resulterende indhold.
Undersøg hele derivatet før deling
Gennemgå overskrifter, almindelig tekst og HTML-dele, vedhæftede filer, indlejrede meddelelser, URL'er, kommentarer og filnavne. Fjern handlingstokens såsom modtagerspecifikke afmeldingsværdier, hvor de ikke er nødvendige. Undgå en simpel søg-og-erstat som den eneste fortrolighedskontrol, fordi kodede eller gentagne data kan forblive.
Giv analytikeren en kort kapacitetserklæring: denne kopi kan understøtte fortolkning af overskrifter og det mærkede identitetsforhold, men kan ikke etablere original signaturgyldighed eller ikke-oplyst DNS tilstand. Hvis analytikeren har brug for mere, skal du søge autorisation for de specifikke yderligere data og modtager i stedet for automatisk at sende den fulde original. Hold redaktionsloggen begrænset, når den indeholder kortlægningen tilbage til personlige oplysninger.
Arbejd gennem en hypotetisk justering prøve
Antag, at spørgsmålet er, om et afvisningsunderdomæne og et synligt forfatterdomæne har den relation, der kræves af den konfigurerede justeringstilstand. En autoriseret illustrativ kortlægning kan erstatte forfatteren med brand.example , dens bounce-underdomæne med bounce.brand.example og en ikke-relateret leverandør med vendor.example . At kortlægge alle tre til example.com ville skjule forskellen.
Mærk kortlægningen som illustrativ og angiv det relevante strenge eller afslappede forhold. Det er ikke en erstatning for evaluering af de rigtige domæner, politik eller DNS . Hvis spørgsmålet ændres til DKIM gyldighed, skal du bruge den begrænsede original under en godkendt adgangsordning i stedet for at love, at den redigerede kopi kan besvare det.
Inden deling skal du inspicere hver del for gentagne adresser, tokens og identifikatorer, inklusive indlejrede meddelelser. Dette er en hypotetisk udvælgelsesarbejdsgang, ikke en udført redaktion eller en påstand, som en faktisk prøve er sikker at afsløre.
Del det mindste bevis, der besvarer spørgsmålet
- Hold den eneste originale begrænset og opret et separat mærket derivat.
- Bevar nødvendige identitetsrelationer, modtagerblokke, hoprækkefølge og tidskontekst.
- Gennemgå alle MIME dele, indlejret indhold, links og filnavne.
- Angiv, hvilke tests derivatet ikke længere kan understøtte.
- Få autorisation til de faktiske data og modtager før ekstern deling.