Definiera frågan innan du väljer programvara
Ett DKIM2 labb bör lösa en snäv osäkerhet, till exempel om två implementeringar rekonstruerar samma modifierade meddelande eller klassificerar en enveloppemissmatch konsekvent. "Se om DKIM2 fungerar" är för brett för att ge ett tolkbart resultat. Skriv en fråga, ett versionsomfång och ett kriterium för godkänd/underkänd innan du väljer en fixtur. Håll ett separat beslut om huruvida något observerat resultat skulle motivera ytterligare experiment, inte automatiskt produktionsantagande.
Som granskats den 8 november 2026, kärn spec-09 är ett aktivt Internet-utkast daterat 1 november, medan DNS-03 är daterat 2 november och BCP-01 är daterat 9 september. Fäst alla dokument som ett ärende beror på. En mjukvaruetikett som säger " DKIM2 " är otillräcklig om dess parser följer en tidigare version eller en separat profil med annan täckning.
Skilj en rapporterad implementering från en utvald byggnad
De Milter utbyggnadsprofil -08 utkast rapporterar DarkChain och DarkChains som betakod för den enskilda profilen. Dess statussektion avsäger sig uttryckligen verifiering av information från bidragsgivare och IETF godkännande. Det är en ledtråd för en utvärderare, inte en oberoende testad rekommendation. Profilens begränsade och utökade funktioner får inte i tysthet jämställas med varje krav i WG kärnutkastet.
Innan programvaran körs bör en godkänd plan identifiera förvarets ursprung, oföränderlig commit eller release, byggkonfiguration, kryptografiska bibliotek och den påstådda protokoll-/profiltäckningen. Registrera funktioner som inte stöds som inte stöds, inte som misslyckade tester av ett annat implementeringslöfte. Installation och utförande är separata operativa åtgärder; ingen källutcheckning, build, installation eller posttransaktion utfördes för detta paket.
Bygg ett litet fodral med meningsfulla kontraster
Börja med en befintlig klassisk DKIM-baslinje för att säkerställa att testselen inte blandar ihop vanlig posthantering med experimentellt beteende. Ange sedan en fiktiv oförändrad DKIM2 sökväg, en deklarerad sidfotsändring och en odeklarerad ändring. Behåll de ursprungliga och modifierade meddelandebytena i den eventuella kontrollerade fixturen. Om ett fall ändrar flera variabler samtidigt, kan ett misslyckande avslöja lite om den mekanism som undersöks.
Lägg till ett kuvert som inte matchar, ett recept med noll text och ett tillfälligt DNS fel. Under kärna -09 avsnitt 13–14, dessa är inte utbytbara "dålig post"-fall. Ett noll body-recept förhindrar kontroll av tidigare kroppstillstånd; ett tillfälligt problem med nyckelsökning har en annan resultatkategori än genomförd verifiering som misslyckas. Bevara den exakta diagnostiken och den saknade ingången.
Ett tidsstämpelfall bör behålla den ursprungliga SMTP acceptanstiden. Ett reprisrelaterat fall bör särskilja avsedd distribution, oväntad vidareleverans och upprepade observationer av den ursprungliga instansen. Markera varje förväntat resultat som en hypotes tills programvaran faktiskt producerar en observation. Detta paket tillhandahåller en original casedesign, inte exekverade exempelmeddelanden eller en resultattabell med tillverkade pass.
Bevara indata som behövs för reproduktion
För varje auktoriserad körning, spela in en ogenomskinlig case-identifierare, meddelande-byte-hash, kuvertsändare och mottagare, accepttid, signerare och verifierarversioner, viktiga ögonblicksbilder och relevanta policyposter. Lagra originalmeddelanden och privata data endast under den godkända åtkomst- och lagringsplanen. En hash identifierar en artefakt; den rekonstruerar inte saknade byte eller bevisar att en diagnostik kom från det anspråkade programmet.
Separera förväntat resultat, observerat resultat och granskartolkning. Behåll mellanliggande utdata för kandidatfel: receptrekonstruktion, signaturverifiering, kedjekontroller och domänmatchning. Om selen aldrig nådde den avsedda kontrollen eftersom analysen misslyckades först, registrera det faktumet. Rapportera inte en nedströmsfunktion som testad bara för att den övergripande körningen returnerade ett fel.
Använd endast en andra implementering efter att ha kontrollerat att den riktar sig mot samma fästa beteende. Överensstämmelse mellan två program är användbar men inte ett absolut bevis på riktighet; de kan dela kod eller samma felaktiga antagande. Oenighet är inte heller automatiskt en defekt om man implementerar ett äldre utkast. Versionsjämförelsen hör till resultatet, inte gömd i en fotnot.
Granska säkerhet och integritet innan exekvering
Recept kan bevara material som tagits bort från det synliga meddelandet. Syntetiskt innehåll är därför att föredra för ett initialt labb: ett reversibelt redaktionstest bör inte återinföra en verklig hemlighet i bevisarkivet. Använd kontrollerade mottagare, isolerade signeringsnycklar och ett namnområde vars ägare godkände experimentet. Sätt gränser som förhindrar oavsiktlig leverans, vidarebefordringsslingor eller oönskad återuppspelningstrafik.
Ange stoppvillkor för oförklarlig utgående e-post, oväntad mottagarexpansion, produktions- DNS påverkan eller känsligt innehåll som visas i loggar. Inaktivera inte etablerad autentisering eller filtrering bara för att få en ren experimentell framgång. Rengöring bör täcka testsignering, register, artefakter och referenser, med lagringsbehov dokumenterade separat. Ett experiment är inte komplett bara för att det senaste meddelandet levererades.
Håll rapportering och implementeringsslutsatser blygsamma
De BCP-01 utkast diskuterar blandad DKIM1 / DKIM2 -drift och lämnar aspekter av DMARC integration öppen. Publicerad RFC 9989 definierar fortfarande sina egna autentiseringsmekanismer. Ett labbresultat kan inte ändra den specifikationen eller fastställa att varje extern mottagare tolkar experimentmeddelandet på samma sätt.
Liknande, RFC 9990 aggregerad rapportering och RFC 9991 felrapportering är inte generiska transporter för vilka experimentfält en utvecklare än vill samla in. Håll lokal labbdiagnostik åtskild från rapportformat som stöds. En saknad extern rapport är inte ett bevis på avslag, och en mottagen rapport visar inte automatiskt hela DKIM2 verifieringsvägen.
Ange det oavslutade beviset tydligt
Den exakta provisionen är: Registrera laboratorieomfattning, versioner, fall, resultat och gränsen mellan experiment och produktion. Omfattning, aktuella dokumentversioner och föreslagna ärenden behålls här. Programvarustift, faktiska körningar, observerade resultat, reproducerbarhetskontroller och verifierad rensning saknas. Den ursprungliga bevisporten förblir därför öppen; ingen labbframgång, säkerhetsgaranti eller EmailAuth förmåga görs anspråk på.
En teknisk ägare bör godkänna protokolltolkningen, en säkerhetsägare bör godkänna alla verkliga experiment, och en oberoende granskare bör bedöma det resulterande beviset innan ett beslut i nästa steg. Produktionstillämplighet, plats och visuell acceptans och publiceringstillstånd förblir separata portar. Ett bra labb ger ett avgränsat svar som en annan ingenjör kan utmana, inte ett nytt produktionskrav som härleds från en ofullbordad standard.