Dua pihak membuat hubungan pelaporan
Menerbitkan tujuan pelaporan di domain DMARC kebijakan mengungkapkan permintaan pemilik domain. Pihaknya tidak secara sepihak mengharuskan negara tujuan yang tidak terkait untuk menerima laporan yang dihasilkan. Verifikasi tujuan eksternal melindungi penerima agar tidak dipilih sebagai target laporan yang tidak diinginkan. Sisi penerima menerbitkan izin melalui DNS , sedangkan sisi pelapor memeriksa izin tersebut sebelum menggunakan tujuan eksternal.
RFC 9990 menerapkan prosedur verifikasinya bila relevan Domain Organisasi perbandingan menunjukkan tujuan eksternal untuk pelaporan agregat. Jangan ganti aturan tersebut dengan pengujian sederhana yang menyatakan bahwa string dalam alamat Dari dan alamat laporan berbeda. Domain kebijakan yang ditemukan, host tujuan, dan konteks domain organisasi harus dipertahankan sehingga keputusan untuk melakukan verifikasi dapat direproduksi. RFC 9990 , bagian 4
Susun nama pemilik dalam urutan yang benar
Ekstrak host tujuan dari URI pelaporan. Tambahkan _laporan. _dmarc , lalu tambahkan nama domain tempat kebijakan diambil, ubah domain tersebut menjadi label-A jika diperlukan. Pemilik DNS yang dihasilkan memiliki formulir policy-domain._report. _dmarc.destination-host. Hal ini dipertanyakan catatan TXT. Jika nama yang dibuat melebihi batas DNS , penentuan otorisasi positif tidak dapat dilakukan.
Konstruksi ini menggunakan domain sebenarnya dari mana kebijakan tersebut diambil. Jangan menyingkatnya menjadi induk yang sudah dikenal hanya karena induk tersebut terlihat seperti merek organisasi. Demikian pula, bagian lokal dari alamat mailto tidak dimasukkan ke dalam nama pemilik DNS . Pertahankan URI asli dan host tujuan yang diurai sehingga peninjau dapat melihat bagaimana nama yang dibuat mengikuti masukan. RFC 9990 , bagian 4
Validasi respons daripada mengenali string yang sudah dikenal
Catatan yang dikembalikan diurai sebagai daftar nilai tag. Tag wajib v=DMARC1 harus muncul terlebih dahulu, dan tanda titik koma di belakangnya bersifat opsional. Catatan yang gagal dalam uji penguraian yang ditentukan akan dibuang. Setidaknya satu catatan kualifikasi yang tersisa menetapkan pengaturan pelaporan eksternal berdasarkan prosedur. Jawaban kosong, nilai TXT yang tidak terkait atau sebuah rekor dengan penempatan versi yang salah tidak memberikan izin.
Nilai versi DMARC peka huruf besar-kecil: DMARC1 adalah nilai yang diperlukan, bukan perkiraan huruf kecil atau versi protokol yang baru ditemukan. Aturan perbandingan nama DNS tidak boleh tertukar dengan persyaratan kasus nilai versi. Tinjauan harus mempertahankan byte jawaban yang tepat dan batas catatan alih-alih menormalkan detail sebelum validasi. RFC 9990 , bagian 4; RFC 9989 , bagian 4.7 dan 4.8
Hormati perilaku override dan kegagalan
Catatan otorisasi dapat memberikan penggantian tujuan pelaporan berdasarkan prosedur. URI utama harus menggunakan host tujuan yang sama yang diekstraksi di awal. Pembatasan ini mencegah respons otorisasi mengalihkan proses ke rantai penerima yang tidak terkait. Jika konfirmasi berisi penggantian dengan host yang berbeda, pembuat laporan tidak boleh membuat laporan ke URI asli atau URI pengganti.
Jika verifikasi tidak mengonfirmasi otorisasi, URI eksternal harus diabaikan. Kesalahan DNS sementara memiliki penanganannya sendiri: penerima dapat memilih untuk gagal mengirimkan sementara sehingga uji verifikasi dapat diulangi nanti. Pertahankan izin tersebut sebagai MUNGKIN, bukan jaminan percobaan ulang universal atau deskripsi implementasi yang diuji. Pemeriksaan DNS yang berhasil tetap tidak membuktikan bahwa kotak surat tujuan ada, menerima ukuran laporan, atau memasukkan dasbor pelanggan yang dituju. RFC 9990 , bagian 4
Membedakan permintaan laporan agregat dan kegagalan
Untuk laporan agregat, prosedurnya dikaitkan dengan rua. Pelaporan kegagalan ditentukan secara terpisah di RFC 9991. Untuk tujuan laporan kegagalan eksternal, dokumen tersebut memerlukan prosedur verifikasi eksternal yang sama dengan ruf yang diganti di mana pun rua muncul. Jangan menganggap pelaporan kegagalan diaktifkan secara otomatis hanya karena laporan agregat sedang mengalir, atau menyalin penanganan tujuan agregat tanpa mengakui jenis laporan terpisah.
Laporan kegagalan meningkatkan kekhawatiran mengenai keterpaparan data tambahan karena kontennya mungkin lebih detail dibandingkan ringkasan agregat. Catatan otorisasi DNS yang benar bukanlah pengganti keputusan organisasi mengenai data mana yang boleh dibagikan, dengan siapa, dan untuk tujuan apa. Naskah ini tidak memberikan izin untuk meminta, mengirimkan atau mengunggah laporan aktual. Setiap pengaturan nyata harus memenuhi privasi, penerima, dan persetujuan operasional yang berlaku. RFC 9991 , bagian 5 dan 7
Lembar kerja konstruksi dan penerimaan fiksi
Asumsikan kebijakan fiktif diambil dari blue.example.com dan meminta laporan gabungan di mailto:reports@red.example.net. Pemilik otorisasi yang dibuat adalah blue.example.com._report._dmarc.red.example.net . Jawaban TXT hipotetis yang nilai lengkapnya v=DMARC1; memenuhi persyaratan versi pertama yang diilustrasikan. Tidak ada permintaan DNS yang dijalankan, dan contoh ini tidak mengklaim bahwa nama-nama tersebut telah menerbitkan catatan.
Lembar kerja harus menyimpan hasil pencarian kebijakan, domain kebijakan yang ditemukan, URI pelaporan asli, host tujuan, perbandingan domain organisasi, pemilik yang dibuat, jenis kueri, stempel waktu, catatan yang dikembalikan secara tepat, dan hasil penguraian. Tambahkan bidang terpisah untuk penggantian apa pun dan konfirmasikan pembatasan hostnya. Peninjau harus dapat merekonstruksi nama tersebut tanpa bergantung pada tangkapan layar penyedia atau tampilan singkatan editor DNS .
Gunakan bagian penerimaan kedua untuk pengumpulan: akun yang dituju, kotak surat tujuan, jenis laporan resmi, dan pemilik saluran. Bidang tersebut menjelaskan alur kerja verifikasi yang direncanakan, bukan bukti penyerapan yang telah selesai. Jaga agar hasil hubungan DNS berbeda dari penerimaan, penguraian, atribusi penyewa, dan presentasi dasbor. Pemeriksaan izin dapat berhasil sementara bagian lain dari jalur pengumpulan masih belum terselesaikan.
Publikasi dan implementasi ditangguhkan
Katalog memerlukan konstruksi pencarian otorisasi yang tepat dari domain sumber dan tujuan serta verifikasi jawabannya. Draf ini hanya memberikan konstruksi fiksi. Jawaban aktual, transkrip kueri asli, dan implementasi domain penerima tetap terbuka. Tidak ada data DNS yang dipublikasikan, tidak ada kotak surat yang diakses, dan tidak ada laporan yang dikirimkan.
Sebelum dirilis sebagai panduan operasional, dapatkan bukti resmi untuk hubungan produksi yang sebenarnya dan mintalah peninjau yang berkualifikasi untuk mengonfirmasi konteks penemuan kebijakan, penguraian versi, dan penanganan penggantian. Pertahankan tanggal sumber dan bedakan persyaratan standar dari orientasi akun khusus penyedia. Keenam gerbang pelepasan tetap terbuka, termasuk bukti asli, tinjauan manusia, penerapan sumber, jalur produksi, aksesibilitas visual, dan pelepasan pemilik.
Perubahan selanjutnya pada domain tujuan atau penemuan kebijakan dapat mengubah pemilik otorisasi yang diperlukan. Perlakukan ini sebagai hubungan tercakup baru untuk diverifikasi daripada mengasumsikan pemeriksaan positif lama mencakup setiap alamat pelaporan di masa mendatang. Hasil yang bermanfaat adalah rantai izin yang dapat diaudit, bukan hanya nilai TXT yang disalin.