Catatan yang dihasilkan adalah artefak keputusan
A catatan DMARC generator dapat memformat kebijakan yang diusulkan, namun tidak dapat memutuskan pengirim sah mana yang dimiliki organisasi, risiko bisnis apa yang diterima, atau apakah tujuan pelaporan diotorisasi. Outputnya harus menjelaskan setiap pilihan kebijakan dan asumsi di baliknya. String yang dapat disalin tanpa keputusan tersebut dapat mendorong publikasi kebijakan yang masuk akal secara sintaksis dan tidak sesuai dengan aliran email organisasi yang sebenarnya.
RFC 9989 mendefinisikan format dan mekanisme kebijakan saat ini. Artikel ini mengusulkan persyaratan untuk generator dan tinjauan keluaran beranotasi. Itu tidak mengklaim bahwa EmailAuth mengimplementasikan generator, menghasilkan catatan siap produksi atau mengubah DNS . Kasus uji asli dan bukti operasional yang diperlukan tetap terpisah dari kerangka penjelasan.
Tetapkan domain kebijakan dan kepemilikan
Catat domain yang kebijakannya sedang disiapkan, pemilik bisnis, pemilik publikasi DNS , dan alur kerja pengiriman yang sah dalam cakupannya. Bedakan nama pemilik pasti tempat kebijakan akan dipublikasikan dari identitas domain yang digunakan oleh pengirim. Generator tidak boleh secara diam-diam memilih domain induk atau anak berdasarkan label tampilan atau asumsi batasan organisasi.
Penemuan kebijakan saat ini mencakup Jalan Pohon DNS dijelaskan oleh RFC 9989. Anotasi generator harus menjelaskan cakupan yang dimaksudkan dan asumsi terkait pewarisan apa pun yang perlu ditinjau, bukan menjanjikan hal tersebut sebuah rekor hanya mempengaruhi alamat yang diketik pengguna. Perilaku aktual yang dapat diterapkan bergantung pada implementasi standar dan penerima. Tidak ada hierarki domain atau kebijakan yang ada yang ditanyakan selama pekerjaan ini.
Jelaskan kebijakan dan kesiapan yang diminta
Kebijakan yang diminta menyatakan preferensi penilaian pemilik domain berdasarkan protokol; ini bukan jaminan atas disposisi akhir penerima atau pernyataan bahwa setiap pengirim yang sah telah siap. Sebelum merekomendasikan penerapan, mintalah tinjauan kesiapan pengirim demi pengirim dan keputusan resmi mengenai kegagalan yang masih ada. Generator dapat menghadirkan pilihan dan konsekuensi, namun tidak boleh menciptakan persetujuan bisnis di baliknya.
Menjelaskan penyelarasan pilihan yang terpisah dari tingkat keparahan kebijakan. Domain Dari yang terlihat, diautentikasi SPF identitas dan DKIM domain penandatanganan telah menentukan hubungan di bawah DMARC. Penyelarasan yang ketat dan longgar bukan hanya sekedar label untuk keamanan keseluruhan yang lebih kuat dan lebih lemah; implikasi operasionalnya bergantung pada struktur domain organisasi dan layanan pengirim. Pertahankan alasan yang dipilih dan ketergantungan yang belum terselesaikan dalam keluaran yang dianotasi.
Pertahankan versi saat ini dan beri tag semantik
RFC 9989 masih menentukan nilai versi peka huruf besar-kecil DMARC1 . Generator tidak boleh mengiklankan dokumen standar baru sebagai peralihan ke DMARC2. Posisi dan nilai tag versi yang diperlukan harus divalidasi sesuai dengan format saat ini. Tag yang tidak dikenal harus diabaikan oleh pemrosesan protokol berdasarkan definisi formal, sehingga alat tersebut harus membedakan peringatan tag yang tidak didukung dari aturan yang dibuat bahwa setiap tag yang tidak dikenal akan membatalkan keseluruhan kebijakan.
Lampiran A.6 menjelaskan penghapusan persen dan pengenalan t dengan nilai y dan n. Generator saat ini tidak boleh meneruskan penggeser persentase yang sudah usang seolah-olah itu adalah kontrol normatif saat ini, atau berasumsi bahwa mengganti setiap persentase historis dengan t adalah migrasi universal yang aman. Ini harus mendokumentasikan standar yang ditargetkan, semantik pengujian yang tepat, dan pertanyaan kompatibilitas yang tersisa untuk lingkungan yang diinginkan.
Perlakukan tujuan pelaporan sebagai penerima yang disetujui
RFC 9990 mendefinisikan pelaporan agregat dan verifikasi tujuan eksternal. Generator harus menjelaskan bahwa menerbitkan permintaan laporan dan menerima laporan adalah langkah yang berbeda. Ini harus mengidentifikasi penerima yang diusulkan, tujuan data dan apakah otorisasi tujuan eksternal yang berlaku sudah ada. Jangan menyimpulkan otorisasi hanya karena pengguna menempelkan alamat ke dalam formulir.
Artikel ini tidak memberikan alamat pelaporan, menerbitkan catatan otorisasi, atau mengirim data ke pihak ketiga. Output yang diusulkan harus menggunakan placeholder non-operasional yang jelas sampai tujuannya disetujui. Anotasi juga harus menyatakan bahwa ketersediaan laporan bergantung pada penerima dan pengiriman, jadi menyertakan URI bukanlah jaminan observasi yang lengkap. Pilihan pelaporan kegagalan, jika ditawarkan, memerlukan spesifikasi yang didukung dan tinjauan privasi daripada digabungkan begitu saja ke dalam pengaturan laporan agregat.
Jelaskan penanganan rekaman dan duplikat yang ada
Generator harus menanyakan bagaimana kebijakan yang diusulkan berkaitan dengan status publikasi yang ada. Memproduksi kandidat kebijakan kedua pada pemilik yang sama dapat memberikan hasil yang berbeda dibandingkan mengganti rekaman yang sudah ada dan disetujui. Oleh karena itu, keluarannya harus mendeskripsikan perbedaan persis yang diinginkan dan mempertahankan materi pemulihan, bukan hanya mengatakan tambahkan ini catatan TXT. Data TXT yang tidak terkait tidak boleh dihapus sebagai efek samping dari pembuatan kebijakan.
RFC 1035 mendefinisikan struktur data TXT . Beberapa string dalam satu data TXT tidak sama dengan beberapa data kebijakan. Anotasi dan pengujian harus mempertahankan perbedaan tersebut sehingga tampilan editor tidak menyesatkan operator. Tidak ada status DNS yang diperiksa di sini; penanganan duplikat tetap menjadi persyaratan pengujian yang diusulkan daripada hasil yang diverifikasi.
Lembar kerja keluaran beranotasi
Buat lembar kerja dengan domain kebijakan, pemilik publikasi, rekaman yang diusulkan, arti setiap tag, alasan yang dipilih, bukti prasyarat, dan pemilik persetujuan. Tambahkan referensi status yang ada, perbedaan yang diinginkan, otorisasi penerima pelaporan, batasan kompatibilitas, rencana verifikasi, dan kriteria rollback. Pisahkan sintaksis yang dihasilkan dari persetujuan dan status publikasi. Formulir yang telah diisi tidak secara otomatis menyiratkan izin untuk melakukan perubahan langsung.
Kumpulan perlengkapan yang diperlukan harus mencakup kasus positif yang valid, kasus versi atau format yang diperlukan tidak valid, kandidat kebijakan duplikat, dan perilaku tag yang tidak didukung. Nyatakan hasil yang diharapkan dari standar saat ini dan aturan penyajian produk secara terpisah. Simpan versi generator, masukan pengujian, dan keluaran yang diamati saat pengujian resmi dijalankan nanti. Draf ini belum menghasilkan atau mengevaluasi perlengkapan tersebut dan tidak membuat klaim kesesuaian implementasi.
Diagnosis fiktif: penggeser persentase menyembunyikan keputusan
Tim fiktif menggunakan formulir kebijakan lama dengan penggeser persentase dan berasumsi bahwa memilih angka yang lebih kecil akan membuat perubahan penerapan apa pun aman. Peninjau menanyakan standar apa yang diterapkan dalam formulir tersebut, kesiapan pengirim yang sah dari organisasi, dan bagaimana keluaran yang diusulkan akan diterapkan pada penerima yang relevan. Tampilan kontrol tidak menjawab pertanyaan tersebut.
Respons yang diusulkan adalah memperoleh perilaku terkait standar saat ini, mendokumentasikan keputusan kebijakan, dan memverifikasi rencana perubahan yang tepat, daripada menerjemahkan bilah geser ke tag lain secara otomatis. Tidak ada generator atau penyedia nyata yang dituduh melakukan perilaku ini. Latihan ini bersifat fiktif, tanpa catatan yang dibuat, modifikasi DNS , atau pengujian penerima dilakukan. Hal ini menggambarkan mengapa dasar pemikiran kebijakan harus tetap terlihat seiring dengan sintaksisnya.
Memerlukan bukti sebelum menyebut output siap
Hasil generator yang berguna menyatakan masukan mana yang diberikan, asumsi mana yang tersisa, dan apa yang harus dilakukan sebelum dipublikasikan. Hal ini dapat membantu pemilik yang memenuhi syarat membuat keputusan yang konsisten tanpa mengklaim bahwa teks yang diformat menghasilkan penegakan yang aman. Kewenangan akhir tetap pada proses perubahan bisnis dan teknis yang disetujui.
Katalog memerlukan catatan beranotasi dan kasus uji tag positif, tidak valid, duplikat, dan tidak didukung. Artefak asli tersebut tetap terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Draf ini menyediakan lembar kerja yang diusulkan dan diagnosis fiktif, bukan kebijakan yang siap dipublikasikan, pengujian yang telah selesai, atau fitur alat EmailAuth yang terverifikasi.