Tentukan pertanyaan sebelum memilih perangkat lunak
Lab DKIM2 harus mengatasi ketidakpastian yang sempit, seperti apakah dua implementasi merekonstruksi pesan yang dimodifikasi atau mengklasifikasikan ketidakcocokan amplop secara konsisten. “Lihat apakah DKIM2 berfungsi” terlalu luas untuk memberikan hasil yang dapat ditafsirkan. Tulis pertanyaan, cakupan versi, dan kriteria lulus/gagal sebelum memilih perlengkapan. Buat keputusan terpisah mengenai apakah hasil yang diamati akan membenarkan eksperimen lebih lanjut, bukan adopsi produksi otomatis.
Sebagaimana diulas pada 8 November 2026, spesifikasi inti-09 merupakan Internet-Draft aktif tanggal 1 November, sedangkan DNS-03 tanggal 2 November dan BCP-01 tanggal 9 September. Sematkan semua dokumen yang menjadi tempat bergantung kasus. Label perangkat lunak yang bertuliskan “ DKIM2 ” tidak cukup jika pengurainya mengikuti revisi sebelumnya atau profil terpisah dengan cakupan berbeda.
Membedakan implementasi yang dilaporkan dari build yang dipilih
Itu Profil penerapan Milter -08 draf melaporkan DarkChain dan DarkChains sebagai kode beta untuk profil individual tersebut. Bagian statusnya secara eksplisit menolak verifikasi informasi yang diberikan kontributor dan dukungan IETF . Hal ini merupakan petunjuk bagi seorang evaluator, bukan rekomendasi yang telah diuji secara independen. Fungsi profil yang terbatas dan diperluas tidak boleh disamakan dengan setiap persyaratan dalam rancangan inti WG.
Sebelum menjalankan perangkat lunak, rencana yang disetujui harus mengidentifikasi asal repositori, penerapan atau rilis yang tidak dapat diubah, konfigurasi build, pustaka kriptografi, dan cakupan protokol/profil yang diklaim. Catat fitur yang tidak didukung sebagai tidak didukung, bukan sebagai pengujian gagal dari janji implementasi yang berbeda. Instalasi dan pelaksanaan adalah tindakan operasional yang terpisah; tidak ada checkout sumber, pembuatan, instalasi, atau transaksi email yang dilakukan untuk paket ini.
Buatlah kumpulan kasus kecil dengan kontras yang bermakna
Mulailah dengan baseline klasik DKIM yang sudah ada untuk memastikan test harness tidak membingungkan penanganan email biasa dengan perilaku eksperimental. Kemudian tentukan jalur fiksi DKIM2 yang tidak diubah, modifikasi footer yang dinyatakan, dan perubahan yang tidak diumumkan. Simpan byte pesan asli dan yang dimodifikasi di perlengkapan yang akhirnya dikontrol. Jika suatu kasus mengubah beberapa variabel sekaligus, kegagalan mungkin hanya mengungkapkan sedikit tentang mekanisme yang sedang diselidiki.
Tambahkan ketidakcocokan amplop, resep isi nol, dan kegagalan DNS sementara. Di bawah inti -09 bagian 13–14, ini bukanlah kasus “surat buruk” yang dapat dipertukarkan. Resep tubuh nol mencegah pemeriksaan keadaan tubuh sebelumnya; masalah pencarian kunci sementara memiliki kategori hasil yang berbeda dari verifikasi selesai yang gagal. Pertahankan diagnostik yang tepat dan masukan yang hilang.
Kasus stempel waktu harus mempertahankan waktu penerimaan SMTP asli. Kasus yang terkait dengan pemutaran ulang harus membedakan distribusi yang diharapkan, pengiriman selanjutnya yang tidak terduga, dan pengamatan berulang terhadap kasus aslinya. Tandai setiap hasil yang diharapkan sebagai hipotesis hingga perangkat lunak benar-benar menghasilkan observasi. Paket ini menyediakan desain kasus asli, bukan pesan sampel yang dieksekusi atau tabel hasil dengan pass palsu.
Pertahankan masukan yang dibutuhkan untuk reproduksi
Untuk setiap proses yang diotorisasi, catat pengidentifikasi kasus buram, hash byte pesan, pengirim amplop dan penerima, waktu penerimaan, versi penandatangan dan pemverifikasi, cuplikan kunci dan catatan kebijakan yang relevan. Simpan pesan asli dan data pribadi hanya berdasarkan rencana akses dan penyimpanan yang disetujui. Hash mengidentifikasi artefak; itu tidak merekonstruksi byte yang hilang atau membuktikan bahwa diagnostik berasal dari program yang diklaim.
Pisahkan hasil yang diharapkan, hasil observasi, dan interpretasi reviewer. Pertahankan keluaran antara untuk kandidat yang gagal: rekonstruksi resep, verifikasi tanda tangan, pemeriksaan rantai, dan pencocokan domain. Jika rangkaian kabel tidak pernah mencapai pemeriksaan yang diinginkan karena penguraian gagal terlebih dahulu, catat fakta tersebut. Jangan laporkan fitur downstream yang telah diuji hanya karena keseluruhan proses menghasilkan kesalahan.
Gunakan implementasi kedua hanya setelah memeriksa apakah implementasi tersebut menargetkan perilaku yang dipasangi pin yang sama. Kesepakatan antara dua program berguna tetapi bukan bukti kebenaran mutlak; mereka mungkin berbagi kode atau asumsi keliru yang sama. Ketidaksepakatan juga tidak secara otomatis merupakan cacat jika seseorang menerapkan rancangan yang lebih lama. Perbandingan versi ada di samping hasil, tidak disembunyikan dalam catatan kaki.
Tinjau keamanan dan privasi sebelum eksekusi
Resep dapat mengawetkan materi yang dihilangkan dari pesan yang terlihat. Oleh karena itu, konten sintetis lebih disukai untuk lab awal: uji redaksi yang dapat dibalik tidak boleh memasukkan kembali rahasia sebenarnya ke dalam arsip bukti. Gunakan penerima yang dikontrol, kunci penandatanganan terisolasi, dan namespace yang pemiliknya menyetujui eksperimen tersebut. Tetapkan batas yang mencegah pengiriman yang tidak diinginkan, putaran penerusan, atau lalu lintas pemutaran ulang yang tidak diminta.
Tentukan kondisi penghentian untuk email keluar yang tidak dapat dijelaskan, perluasan penerima yang tidak terduga, dampak DNS produksi, atau konten sensitif yang muncul di log. Jangan nonaktifkan otentikasi atau pemfilteran yang sudah ada hanya untuk mendapatkan keberhasilan eksperimental yang bersih. Pembersihan harus mencakup penandatanganan pengujian, catatan, artefak, dan kredensial, dengan kebutuhan penyimpanan didokumentasikan secara terpisah. Eksperimen tidak selesai hanya karena pesan terakhir terkirim.
Jaga agar kesimpulan pelaporan dan penerapan tetap sederhana
Itu Draf BCP-01 membahas operasi campuran DKIM1 / DKIM2 dan meninggalkan aspek DMARC integrasi terbuka. Diterbitkan RFC 9989 masih mendefinisikan mekanisme otentikasinya sendiri. Hasil lab tidak dapat mengubah spesifikasi tersebut atau menetapkan bahwa setiap penerima eksternal menafsirkan pesan eksperimental dengan cara yang sama.
Demikian pula, RFC 9990 pelaporan agregat dan RFC 9991 pelaporan kegagalan bukanlah transportasi umum untuk bidang eksperimental apa pun yang ingin dikumpulkan oleh pengembang. Jaga agar diagnosis laboratorium lokal berbeda dari format laporan yang didukung. Laporan eksternal yang hilang bukan merupakan bukti penolakan, dan laporan yang diterima tidak secara otomatis memaparkan jalur verifikasi DKIM2 secara lengkap.
Nyatakan bukti-bukti yang belum lengkap dengan jelas
Komisi pastinya adalah: Mencatat ruang lingkup lab, versi, kasus, hasil, dan batasan antara eksperimen dan produksi. Cakupan, versi dokumen terkini, dan kasus yang diusulkan dipertahankan di sini. Pin perangkat lunak, proses aktual, hasil yang diamati, pemeriksaan reproduktifitas, dan pembersihan terverifikasi tidak ada. Oleh karena itu, gerbang bukti asli tetap terbuka; tidak ada keberhasilan lab, jaminan keamanan, atau kemampuan EmailAuth yang diklaim.
Pemilik teknis harus menyetujui interpretasi protokol, pemilik keamanan harus mengizinkan eksperimen nyata apa pun, dan peninjau independen harus menilai bukti yang dihasilkan sebelum mengambil keputusan tahap berikutnya. Penerapan produksi, penerimaan situs dan visual, serta izin publikasi tetap merupakan gerbang terpisah. Laboratorium yang baik menghasilkan jawaban terbatas yang dapat ditantang oleh insinyur lain, bukan persyaratan produksi baru yang disimpulkan dari standar yang belum selesai.