Definer spørsmålet før du velger programvare
Et DKIM2 laboratorium bør løse en smal usikkerhet, for eksempel om to implementeringer rekonstruerer den samme modifiserte meldingen eller klassifiserer en konvoluttmismatch konsekvent. "Se om DKIM2 fungerer" er for bredt til å gi et tolkbart resultat. Skriv et spørsmål, et versjonsomfang og et bestått/ikke bestått kriterium før du velger en inventar. Hold en separat avgjørelse for om et observert resultat vil rettferdiggjøre ytterligere eksperimentering, ikke automatisk produksjonsadopsjon.
Som gjennomgått 8. november 2026, kjernespesifikasjon-09 er et aktivt Internett-utkast datert 1. november, mens DNS-03 er datert 2. november og BCP-01 er datert 9. september. Fest alle dokumenter en sak er avhengig av. En programvareetikett som sier " DKIM2 " er utilstrekkelig hvis parseren følger en tidligere revisjon eller en separat profil med annen dekning.
Skille en rapportert implementering fra en valgt bygg
De Milter-distribusjonsprofil -08 utkast rapporterer DarkChain og DarkChains som betakode for den individuelle profilen. Statusdelen fraskriver seg eksplisitt bekreftelse av bidragsyter-levert informasjon og IETF godkjenning. Det er en ledetråd for en evaluator, ikke en uavhengig testet anbefaling. Profilens begrensede og utvidede funksjoner må ikke stilles likestilles med alle krav i WGs kjerneutkast.
Før du kjører programvare, bør en godkjent plan identifisere repository herkomst, uforanderlig commit eller release, build-konfigurasjon, kryptografiske biblioteker og den påståtte protokollen/profildekningen. Registrer funksjoner som ikke støttes, som ikke støttes, ikke som mislykkede tester av et annet implementeringsløfte. Installasjon og utførelse er separate operasjonelle handlinger; ingen kildeutsjekking, build, installasjon eller posttransaksjon ble utført for denne pakken.
Bygg et lite etui med meningsfulle kontraster
Start med en eksisterende klassisk DKIM-grunnlinje for å sikre at testselen ikke forveksler vanlig posthåndtering med eksperimentell oppførsel. Spesifiser deretter en fiktiv uendret DKIM2 bane, en erklært bunntekstendring og en ikke-erklært endring. Behold de originale og modifiserte meldingsbytene i den eventuelle kontrollerte armaturen. Hvis en sak endrer flere variabler samtidig, kan en feil avsløre lite om mekanismen som undersøkes.
Legg til en konvoluttmismatch, en null body-oppskrift og en midlertidig DNS feil. Under kjerne -09 avsnitt 13–14, disse er ikke utskiftbare "dårlig post"-saker. En null body-oppskrift forhindrer kontroll av tidligere kroppstilstand; et midlertidig nøkkeloppslagsproblem har en annen resultatkategori enn fullført verifisering som mislykkes. Ta vare på den nøyaktige diagnostikken og den manglende inngangen.
Et tidsstempeltilfelle bør beholde den opprinnelige SMTP godkjenningstiden. En replay-relatert sak bør skille mellom tiltenkt distribusjon, uventet viderelevering og gjentatte observasjoner av den opprinnelige instansen. Merk hvert forventet resultat som en hypotese til programvare faktisk produserer en observasjon. Denne pakken leverer et originalt kassedesign, ikke utførte eksempelmeldinger eller en resultattabell med fabrikkerte pass.
Ta vare på inngangene som trengs for reproduksjon
For hver autorisert kjøring, ta opp en ugjennomsiktig kasusidentifikator, meldingsbyte-hash, konvoluttavsender og mottakere, godkjenningstid, underskriver- og verifikatørversjoner, viktige øyeblikksbilder og relevante retningslinjer. Lagre originale meldinger og private data kun under den godkjente tilgangs- og oppbevaringsplanen. En hash identifiserer en artefakt; den rekonstruerer ikke manglende byte eller beviser at en diagnostikk kom fra det påståtte programmet.
Skill forventet resultat, observert resultat og anmeldertolkning. Behold mellomutdata for kandidatfeil: rekonstruksjon av oppskrifter, signaturverifisering, kjedesjekker og domenematching. Hvis selen aldri nådde den tiltenkte kontrollen fordi parsing mislyktes først, noter dette faktum. Ikke rapporter en nedstrømsfunksjon som testet bare fordi den totale kjøringen returnerte en feil.
Bruk en andre implementering bare etter å ha sjekket at den er målrettet mot samme festede atferd. Enighet mellom to programmer er nyttig, men ikke et absolutt bevis på korrekthet; de kan dele kode eller samme feilaktige antagelse. Uenighet er heller ikke automatisk en mangel dersom man implementerer et eldre utkast. Versjonssammenligningen hører til ved siden av resultatet, ikke skjult i en fotnote.
Gjennomgå sikkerhet og personvern før utførelse
Oppskrifter kan bevare materiale fjernet fra den synlige meldingen. Syntetisk innhold er derfor å foretrekke for et innledende laboratorium: en reversibel redaksjonstest bør ikke gjeninnføre en ekte hemmelighet i bevisarkivet. Bruk kontrollerte mottakere, isolerte signeringsnøkler og et navneområde hvis eier godkjente eksperimentet. Angi grenser som forhindrer utilsiktet levering, videresendingssløyfer eller uønsket replay-trafikk.
Angi stoppbetingelser for uforklarlig utgående e-post, uventet mottakerutvidelse, produksjons- DNS påvirkning eller sensitivt innhold som vises i logger. Ikke deaktiver etablert autentisering eller filtrering bare for å oppnå en ren eksperimentell suksess. Opprydding bør dekke testsignering, poster, artefakter og legitimasjon, med oppbevaringsbehov dokumentert separat. Et eksperiment er ikke fullført bare fordi den siste meldingen ble levert.
Hold rapportering og distribusjonskonklusjoner beskjedne
De BCP-01 utkast diskuterer blandet DKIM1 / DKIM2 -operasjon og forlater aspekter ved DMARC integrering åpen. Publisert RFC 9989 definerer fortsatt sine egne autentiseringsmekanismer. Et laboratorieresultat kan ikke endre den spesifikasjonen eller fastslå at hver ekstern mottaker tolker den eksperimentelle meldingen på samme måte.
Tilsvarende RFC 9990 samlet rapportering og RFC 9991 feilrapportering er ikke generisk transport for de eksperimentelle feltene en utvikler ønsker å samle inn. Hold lokal laboratoriediagnostikk forskjellig fra støttede rapportformater. En manglende ekstern rapport er ikke bevis på avvisning, og en mottatt rapport viser ikke automatisk hele DKIM2 verifiseringsbanen.
Fortell det uferdige beviset tydelig
Den eksakte kommisjonen er: Registrer laboratorieomfang, versjoner, tilfeller, resultater og grensen mellom eksperiment og produksjon. Omfang, gjeldende dokumentversjoner og forslag til saker beholdes her. Programvarepinner, faktiske kjøringer, observerte resultater, reproduserbarhetskontroller og verifisert opprydding er fraværende. Porten for originalbevis forblir derfor åpen; ingen laboratoriesuksess, sikkerhetsgaranti eller EmailAuth evne er hevdet.
En teknisk eier bør godkjenne protokolltolkningen, en sikkerhetseier bør autorisere ethvert reelt eksperiment, og en uavhengig anmelder bør vurdere det resulterende beviset før en beslutning i neste trinn. Produksjonsanvendelse, nettsted og visuell aksept, og publiseringstillatelse forblir separate porter. Et godt laboratorium produserer et avgrenset svar som en annen ingeniør kan utfordre, ikke et nytt produksjonskrav utledet fra en uferdig standard.