Jadikan interoperabilitas sebagai perbandingan yang dapat direproduksi
Pernyataan yang didukung oleh receiver telah diperbarui DMARC bukan merupakan hasil interoperabilitas. Pertanyaan yang berguna adalah apakah implementasi yang teridentifikasi, dengan masukan setara yang terkontrol, menghasilkan penemuan yang diharapkan, penyelarasan, kebijakan dan perilaku pelaporan. Perbandingan perlu mempertahankan tahapan tersebut daripada mengurangi eksperimen pada apakah dua pesan sampai ke kotak masuk.
Mulailah dengan katalog kasus berversi dan pemilik tes bernama. Catat perangkat lunak atau layanan penerima, konfigurasi, informasi versi yang dapat diakses, dan segala hal yang tidak diketahui. Layanan terkelola tidak boleh mengungkapkan versi implementasinya; batasan itu termasuk dalam matriks. Jangan mengganti informasi yang hilang dengan klaim adopsi yang diperoleh dari pengumuman produk atau stempel waktu laporan terkini.
Bekukan masukan yang dapat mengubah hasil
Untuk setiap kasus, pertahankan byte pesan, asumsi envelope dan sumber penghubung, data DNS yang relevan, waktu observasi, dan profil konfigurasi. Buatlah perbedaan antara dua pengujian berjalan secara disengaja dan terlihat. Jika satu rute memodifikasi pesan yang ditandatangani atau menggunakan domain envelope yang berbeda, perbandingannya tidak lagi semata-mata tentang perilaku implementasi DMARC .
Gunakan hanya domain resmi, penerima, dan pesan tidak sensitif yang dikontrol. Pisahkan kasus desain fiktif dari perlengkapan yang dapat dieksekusi dan sampel pengiriman sebenarnya. Tuliskan hasil yang diharapkan dan referensi spesifikasinya sebelum menjalankan pengujian; jika tidak, hasil yang mengejutkan dapat digambarkan secara surut seperti yang diharapkan. Kasus yang belum dijalankan harus tetap tidak dijalankan secara eksplisit, tidak menerima izin yang disimpulkan dari dokumentasi.
Inventaris pengirim juga penting. Sertakan jalur perwakilan yang sah, terutama layanan tidak langsung dan berkala, ketika memutuskan apakah cakupan laboratorium relevan dengan perubahan produksi. Kasus protokol bisa saja benar sambil menghilangkan alur bisnis yang sebenarnya akan terpengaruh.
Bandingkan penemuan dan penyelarasan sebelum disposisi
RFC 9989 bagian 4.10 menjelaskan perilaku penelusuran pohon DNS , sementara implementasi sebelumnya dapat menggunakan metode penemuan lama yang didukungnya. Kasus harus mencakup kebijakan Domain Penulis yang eksplisit dan pengaturan fallback yang terkontrol. Tambahkan kasus kebijakan subdomain dan domain yang tidak ada hanya dengan ketentuan DNS yang ditentukan dengan jelas; label yang menyatakan subdomain tidak cukup untuk menentukan kebijakan yang diharapkan.
Tangkap rekaman yang dipilih dan pengidentifikasi terotentikasi yang digunakan untuk penyelarasan. Kemudian catat kebijakan p, sp atau np yang dipilih dan status pengujian. RFC 9989 bagian 4.4 mendefinisikan hubungan keselarasan. Lewat SPF atau DKIM karena identitas yang tidak terkait tidak boleh disalahartikan sebagai DMARC yang berhasil hanya karena penerima pada akhirnya menerima pesan tersebut.
Terakhir, catat penggantian lokal dan disposisi aktual sebagai hasil yang terpisah. Pemfilteran konten, perutean, dan keputusan lokal dapat menghasilkan hasil penayangan yang berbeda meskipun perhitungan DMARC biasa sesuai. Diagnosis tahap perbedaan paling awal daripada mengaitkan setiap perbedaan kotak surat dengan penemuan kebijakan.
Sertakan transisi pengujian tanpa mengasumsikan kesetaraan
Sebuah kasus yang berguna membandingkan bagaimana proses implementasi diidentifikasi sebuah rekor mengandung p=reject dan t=y. Di bawah RFC 9989 bagian 4.7, perlakuan pengujian untuk pesan yang gagal satu tingkat lebih rendah, yaitu karantina. Implementasi lama yang tidak mengenali t mungkin mengikuti logika berbeda yang didukung. Ini adalah pertanyaan kompatibilitas yang diharapkan untuk diukur, bukan alasan untuk menerapkan catatan tersebut sebagai saklar keamanan universal.
Pisahkan persen kasus historis dari t kasus. Paket yang pernah meminta pengambilan sampel tidak boleh dinyatakan kompatibel hanya karena penerima yang diperbarui mengabaikan kontrol lama tanpa kesalahan sintaksis. Efek bisnis yang diinginkan, mekanisme yang ditentukan, dan hasil yang diamati semuanya membutuhkan bidangnya masing-masing.
Pertahankan kasus tag yang tidak diketahui, kebijakan yang hilang, dan input yang salah dalam lingkup pengujian yang terkontrol. Jangan gunakan domain produksi sebagai target eksperimen untuk rekaman yang sengaja dibuat ambigu. Desain pengujian itu sendiri harus mengidentifikasi persyaratan persetujuan dan pemulihan yang relevan sebelum pelaksanaan operasional apa pun.
Uji pelaporan sebagai kemampuan terpisah
RFC 9990 mendefinisikan struktur laporan agregat, termasuk metode_penemuan opsional dan konteks pengujian. Laporan yang memuat bidang-bidang tersebut dapat mendukung pengamatan terhadap laporan tersebut; bidang opsional yang dihilangkan tidak membuktikan perilaku lama. Pertahankan laporan mentah dan profil parser, karena konsumen dapat kehilangan informasi meskipun penerima membuatnya dengan benar.
Periode laporan dapat mencakup transisi kebijakan, sehingga satu agregat tidak selalu merupakan transkrip dari satu kebijakan yang dibekukan. Selaraskan rentang waktu perbandingan dan bukti sumber sebelum menggunakan hitungan untuk menjelaskan pesan tertentu. Kompatibilitas deduplikasi dan skema menjadi bagian dari rencana pengujian pelaporan, bukan disembunyikan di dasbor.
Pelaporan kegagalan adalah dimensi independen lainnya. RFC 9991 meninggalkan generasi tergantung pada kemauan penerima dan batasan privasi. TIDAK laporan kegagalan bukanlah bukti yang cukup bahwa uji interoperabilitas gagal. Catat apakah pelaporan diminta, didukung, diotorisasi, diterima, dan dapat ditafsirkan tanpa mengumpulkan konten pesan yang tidak diperlukan.
Matriks fiksi tanpa sel hasil yang diamati
Lembar kerja fiksi menyebutkan Penerima A sebagai referensi semantik saat ini dan Penerima B sebagai profil warisan. Keduanya diberi pesan penemuan dan snapshot DNS yang sama untuk p=reject; t=y kasus. Kolom kebijakan yang diharapkan untuk A berasal dari spesifikasi. Implementasi B dan seluruh hasil aktualnya masih memerlukan bukti; tidak ada produk yang dianggap berperilaku seperti label.
Matriks yang direncanakan juga mencakup kontrol yang diselaraskan langsung, kasus domain terautentikasi yang tidak terkait, kasus penemuan fallback, dan kasus format agregat. Setiap sel eksekusi tetap tidak berjalan. Hal ini menjadikan persiapan lembar kerja berguna tanpa membuat bukti kesesuaian atau adopsi penerima.
Pertahankan persyaratan rilis yang tepat
Gerbang bukti aslinya adalah: Pertahankan matriks interoperabilitas berversi dengan kasus masukan yang identik dan hasil yang diamati sepenuhnya. Persyaratan commissioning adalah: Validasi spesifikasi utama saat ini dan simpan contoh yang sudah dikerjakan sebelum dibuat. Matriks fiksi yang dipertahankan tidak memenuhi observasi langsung maupun kesiapan produksi. Bukti implementasi yang disebutkan, hasil yang terkendali, tinjauan UKM manusia, persetujuan peluncuran bisnis, dan otorisasi publikasi tetap terbuka. Naskah ini tidak melakukan pengujian penerima, perubahan DNS , atau transmisi pesan.