Tanyakan apa sebenarnya perubahan yang diusulkan dalam usulan peningkatan tersebut
Klaim yang ditawarkan suatu platform a DMARCbis peningkatan harus mengidentifikasi standar saat ini, perilaku penerapan yang diubah, dan bukti bahwa perubahan tersebut berhasil. Ini tidak boleh diterima sebagai permintaan untuk mengalihkan data DNS ke data yang ditemukan DMARC versi. Arus yang ditahan RFC 9989 masih menentukan nilai versi peka huruf besar-kecil DMARC1 . Dokumen standar baru dan rilis implementasi baru tidak sama dengan token versi baru dalam kebijakan yang dipublikasikan.
Artikel ini mengusulkan tinjauan kesiapan terkait standar. Itu tidak mengklaim bahwa EmailAuth mengimplementasikan RFC 9989 sepenuhnya, bahwa setiap penerima telah mengadopsinya atau bahwa peningkatan telah dilakukan. Tidak ada data DNS , parser, penerima, atau konfigurasi produksi yang diubah. Tinjauan tersebut harus memisahkan perubahan normatif, klaim penerapan pemasok, dan pengamatan interoperabilitas sebelum ada yang menyetujui peluncurannya.
Tolak pintasan peralihan versi
Definisi catatan kebijakan RFC 9989 menyatakan bahwa satu-satunya nilai yang mungkin dari tag versi adalah DMARC1 dan bahwa nilai versi yang berbeda menyebabkan catatan diabaikan dalam pemrosesan yang ditentukan. Oleh karena itu, proposal untuk mempublikasikan v=DMARC2 bukanlah instruksi migrasi berbasis standar dari RFC ini. Minta pengusul untuk mengidentifikasi bagian yang tepat yang mendukung setiap perubahan catatan yang direkomendasikan daripada mengandalkan label produk.
Kehati-hatian yang sama berlaku saat mengganti nama pengaturan dasbor. Pengaturan yang disebut DMARCbis dapat mengaktifkan fitur parser, algoritma penemuan kebijakan, atau interpretasi pelaporan, namun maknanya bersifat spesifik untuk produk hingga didokumentasikan. Catat perilaku aktual yang didukung, versi rilis, dan batasannya. Jangan menyimpulkan bahwa mengubah pengaturan akan memperbarui penerima eksternal, menulis ulang setiap catatan dengan benar, atau memverifikasi semua alur kerja pengiriman yang sah.
Inventarisasi perubahan standar yang relevan
Gunakan diskusi perubahan dan bagian normatif RFC 9989 untuk membuat daftar periksa yang terfokus. Salah satu bidang penting adalah kebijakan berbasis DNS dan penemuan domain organisasi, termasuk Jalan Pohon DNS. Itu adalah perilaku implementasi, bukan sekadar string baru untuk dimasukkan ke dalam catatan yang sudah ada. Pemasok yang mengklaim dukungan harus menjelaskan penemuan dan penyelarasan kasus yang ditanganinya dan memberikan bukti terbatas untuk versi produk sebenarnya.
Perubahan eksplisit lainnya adalah penghapusan tag pct dari spesifikasi saat ini. Lampiran A.6 menjelaskan sejarah dan memperkenalkan tag pengujian t dengan nilai y dan n, yang digambarkan sebagai analog dalam penerapan nilai persen sebelumnya 0 dan 100. Hal ini tidak membenarkan penggantian mekanis menyeluruh dari setiap nilai persentase historis atau janji bahwa setiap penerima menerapkan perilaku baru. Tinjau semantik terkini dan populasi penerapan yang relevan sebelum mengusulkan perbedaan kebijakan.
Pisahkan persyaratan protokol dari aturan kelayakan penyedia
Penyedia dapat mempublikasikan persyaratan kelayakan produk yang mengacu pada konvensi penerapan yang ada. Persyaratan tersebut memerlukan tinjauan sumber terkini dan tidak boleh ditulis ulang secara diam-diam karena dokumen protokol berubah. Sebaliknya, instruksi penyedia historis tidak mendefinisikan ulang konten normatif RFC 9989 . Catat perbedaan yang tampak, tanggal sumber, dan pertanyaan implementasi yang memerlukan penyelesaian alih-alih berpura-pura bahwa kedua lapisan tersebut identik.
Naskah ini tidak mengklaim dukungan penerima universal untuk tag pengujian, perilaku berjalan di pohon, atau fitur revisi lainnya. Penilaian kesiapan harus mengidentifikasi komponen mana yang dikontrol organisasi dan mana yang bersifat eksternal. Pengirim dapat memperbarui penerapan atau kebijakannya sendiri hanya dalam cakupan yang didukung; ia tidak dapat memaksa semua sistem penerima untuk melakukan upgrade. Oleh karena itu, kesimpulan kompatibilitas perlu dibuktikan dan dibuktikan secara terbatas, bukan asumsi adopsi global.
Pisahkan standar pelaporan dan kesiapan parser
RFC 9990 mendefinisikan pelaporan agregat DMARC sebagai spesifikasi terpisah. Evaluator kebijakan dan pengurai penyerapan laporan suatu platform mungkin memiliki persyaratan peningkatan yang berbeda. Tanyakan format pelaporan, bidang, dan perilaku validasi mana yang didukung, dan bagaimana laporan lama yang disimpan tetap dapat diinterpretasikan. Jangan berasumsi bahwa mengubah implementasi penemuan kebijakan secara otomatis memperbarui setiap alur kerja pelaporan atau analisis historis.
Sematkan rilis produk dan simpan referensi standar yang digunakan untuk penilaian. Jika parser menemukan varian kolom atau laporan yang tidak didukung, perilakunya harus didokumentasikan dan diuji, bukan ditafsirkan secara diam-diam sebagai tidak ada aktivitas. Pertahankan asal laporan asli dan bedakan observasi yang hilang dari hasil autentikasi. Tidak ada pengurai laporan yang dilakukan untuk artikel ini, dan tidak ada perlengkapan pengujian yang direpresentasikan sebagai laporan penerima sebenarnya.
Membangun matriks standar hingga implementasi
Buat satu baris per persyaratan yang relevan dengan bagian RFC, perilaku normatif, perilaku produk saat ini, usulan perubahan, komponen yang terpengaruh, referensi bukti, dan batasan yang belum terselesaikan. Pisahkan publikasi kebijakan pengirim, evaluasi penerima, penemuan domain organisasi, pembuatan laporan, dan penyerapan laporan. Sebuah platform mungkin hanya menjalankan beberapa peran tersebut, sehingga peran yang tidak didukung harus ditandai di luar cakupan dan bukan dihitung sebagai penerapan yang tersirat.
Tambahkan kasus yang mewakili kebijakan valid yang ada, nilai versi yang tidak valid, batas penemuan, hubungan penyelarasan, dan kompatibilitas pelaporan jika berlaku. Perlengkapan yang tepat harus dirancang oleh peninjau yang berkualifikasi berdasarkan teks normatif dan peran yang didukung produk. Draf ini tidak memberikan rangkaian kesesuaian implementasi atau mengklaim bahwa sejumlah kecil contoh membuktikan kepatuhan sepenuhnya. Setiap hasil yang diamati memerlukan masukan, versi produk, dan perilaku yang diharapkan dipertahankan.
Ikat setiap perubahan catatan dengan kesiapan pengirim
Jika penilaian mengusulkan perubahan kebijakan DNS , siapkan perbedaan yang tepat, catatan kepemilikan, persetujuan bisnis, rencana verifikasi, dan kriteria rollback. Jaga agar alur kerja pengiriman yang sah tetap terlihat melalui matriks kesiapan pengirim demi pengirim. Peningkatan standar tidak membuktikan bahwa setiap pemasok telah menyelaraskan autentikasi atau bahwa setiap alur kerja penting tidak akan terpengaruh. Jangan gunakan label implementasi baru sebagai alasan untuk melewatkan kesiapan operasional.
Catat apa yang bisa dan tidak bisa ditunjukkan oleh perubahan tersebut. Bukti DNS resmi dapat menunjukkan publikasi pada waktu tertentu; bukti pesan yang diterima dan dipercaya dapat menunjukkan hasil autentikasi yang tercakup; laporan agregat dapat menunjukkan pola dalam cakupan yang dipertahankan. Tidak ada satupun yang bisa menciptakan interoperabilitas universal. Perencanaan rollback harus memperhitungkan status cache dan perbedaan implementasi eksternal, bukan hanya kemampuan untuk memulihkan file konfigurasi lama.
Diagnosis fiktif: catatan DMARC2 yang diminta
Pemasok fiktif mengusulkan peningkatan dan memberitahu pembeli untuk mengubah nilai versi kebijakan menjadi DMARC2. Pembeli meminta referensi standar dan menemukan bahwa RFC 9989 masih menentukan DMARC1 . Peralihan versi yang diusulkan ditolak karena tidak didukung, sementara tinjauan implementasi yang lebih luas terus berlanjut: pemasok mungkin memiliki perubahan yang sah terhadap perilaku penemuan atau pelaporan yang memerlukan bukti terpisah.
Tim akan meminta matriks kesiapan yang tercakup dan mendemonstrasikan hasil untuk rilis produk sebenarnya, bukan menerima atau menolak keseluruhan peningkatan berdasarkan nama pemasarannya. Ini adalah latihan peninjauan fiktif, bukan instruksi pemasok sebenarnya atau cacat produksi yang teramati. Tidak ada catatan yang dipublikasikan dan tidak ada receiver yang diuji. Contoh ini menunjukkan bagaimana pertanyaan standar yang tepat dapat memisahkan jalan pintas yang salah dari pekerjaan implementasi yang berpotensi bermanfaat.
Memerlukan cakupan yang ditunjukkan sebelum menyebut pemutakhiran selesai
Kesimpulan yang berguna adalah mengidentifikasi perubahan terkait standar yang diterapkan, peran yang dicakup, bukti yang dipertahankan, dan kompatibilitas eksternal yang masih belum diketahui. Hal ini tidak boleh dikatakan bahwa organisasi tersebut sekarang menggunakan versi dua atau bahwa semua penerima berperilaku seragam. Peningkatan ini merupakan penilaian implementasi dan kesiapan, bukan peralihan universal.
Katalog ini memerlukan penilaian kesiapan yang terkait dengan standar dan menunjukkan hasil implementasi yang tercakup. Hasil asli tersebut tetap terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Draf ini memberikan metode peninjauan dan contoh fiktif, bukan bukti kesesuaian, migrasi yang diterapkan, atau klaim dukungan EmailAuth yang lengkap.