Tentukan pertanyaan dan penerimanya terlebih dahulu
Vendor mungkin memerlukan bukti untuk mendiagnosis masalah penandatanganan, dan penyelarasan ketidakcocokan atau perbedaan pelaporan. Jarang diperlukan setiap laporan untuk setiap domain dalam organisasi. Mulailah dengan menyatakan pertanyaan sebenarnya, produk dan akun yang terlibat, penerima yang dituju, dan keputusan apa yang harus didukung oleh bukti. Hal ini mencegah permintaan untuk “the DMARC data” agar tidak menjadi pengungkapan luas yang tidak perlu.
Konfirmasikan bahwa penerima adalah dukungan resmi atau kontak teknik untuk layanan yang relevan. Nama tampilan yang familier atau permintaan yang diteruskan tidak cukup untuk menetapkan bahwa setiap lampiran harus dikirim ke sana. Penyusunan suatu paket terpisah dari izin untuk mengirimkannya. Artikel ini hanya menjelaskan persiapan dan tidak mengizinkan email, unggahan, atau pembagian eksternal.
Jaga agar cakupan tetap terikat pada rute dan interval yang terpengaruh. Pemasok yang menyelidiki alur kerja penerimaannya sendiri tidak boleh menerima surat karyawan, pemasaran, atau lalu lintas pemasok lainnya yang tidak terkait hanya karena pengamatan tersebut menempati file agregat yang sama.
Pahami apa yang dapat diungkapkan oleh laporan tersebut
Laporan agregat berisi observasi teknis dan informasi kebijakan yang dapat mengungkap aspek infrastruktur dan lalu lintas pengirim. RFC 9990 membahas pertimbangan privasi bagi penerima dan data laporan. Meskipun suatu bidang bukan isi pesan, bidang tersebut mungkin masih tidak diperlukan untuk tugas vendor. Perlakukan minimalisasi sebagai keputusan lapangan daripada berasumsi semua informasi agregat tidak berbahaya.
Laporan kegagalan memiliki permukaan paparan yang terpisah dan berpotensi lebih detail di bawahnya RFC 9991. Jangan menggabungkannya dengan ringkasan agregat berdasarkan persetujuan umum untuk “laporan”. Identifikasi jenis laporan, konten dan tujuan penerima secara eksplisit. Jika pertanyaan diagnostik dapat dijawab dengan ringkasan yang lebih kecil atau kutipan yang telah disunting, lebih baik jawabnya daripada artefak mentah yang lengkap. RFC 9990 , bagian 7.1 dan 7.2; RFC 9991 , bagian 7.1 dan 7.2
Buat peta bidang data sebelum redaksi
Peta lapangan harus mencantumkan masing-masing kandidat item, mengapa diperlukan, apakah nilai pasti diperlukan, usulan perlakuan dan konsekuensi dari penghapusannya. Item potensial mencakup domain Dari yang relevan, domain penandatanganan, pemilih, domain amplop, alamat sumber, interval laporan, penghitungan dan hasil evaluasi. Kebutuhannya bergantung pada pertanyaannya; tidak ada bundel universal yang harus selalu dikirimkan.
Beberapa identitas teknis yang tepat mungkin diperlukan untuk mendiagnosis penyelarasan atau menemukan konfigurasi khusus akun. Jika nilai-nilai tersebut tidak dapat dibagikan dalam cakupan yang disetujui, jelaskan batasan diagnostiknya daripada menggantinya dengan nilai-nilai yang menyesatkan. Pengidentifikasi lain dapat dihapus atau secara konsisten menggunakan nama samaran sambil menjaga hubungan. Simpan pemetaan pribadi hanya jika diperlukan dan diotorisasi, dan jangan sertakan dalam paket vendor secara default.
Hapus baris dan domain yang tidak terkait, alamat penerima yang tidak perlu, konten pesan, catatan internal, dan rahasia. Jangan pernah menyertakan kata sandi, kunci API, token sesi, atau kredensial dalam artefak dukungan. Tinjau nama file, metadata, tangkapan layar, dan konten spreadsheet tersembunyi serta teks yang terlihat; paragraf yang disunting tidak menjamin lampirannya diminimalkan.
Pertahankan hubungan diagnostik
Sampel bukti yang berguna harus mempertahankan perbedaan antara hasil otentikasi mentah dan penyelarasan. Jika pertanyaannya adalah mengapa DMARC gagal, mengganti setiap domain dengan placeholder yang sama dapat menghapus hubungan yang perlu dipahami oleh vendor. Pertahankan apakah identitasnya sama, terkait, atau berbeda, dan beri label pengganti sintetis dengan jelas agar tidak disalahartikan sebagai nama DNS asli yang akan dikueri.
Satukan interval pelaporan, bidang hasil yang relevan, dan catatan cakupan. Jika hanya baris terpilih yang dibagikan, nyatakan bahwa sampel telah difilter dan identifikasi aturan pemilihannya. Jangan mengubah hasil agar contoh terlihat lebih sederhana, dan jangan menyiratkan bahwa jumlah yang difilter mewakili total lalu lintas organisasi. Bila perlu, berikan penjelasan analis yang ringkas di samping bidang yang dipertahankan. RFC 9989 , bagian 4.4; RFC 9990 , bagian 3.1
Lembar kerja persetujuan dan retensi
Siapkan catatan persetujuan dengan penerima, organisasi, produk, tujuan, file atau bidang yang tepat, domain atau rute yang terpengaruh, interval waktu, sensitivitas, metode transfer, dan keputusan penyimpanan. Identifikasi apakah vendor dapat menyimpan materi hanya untuk kasus ini, menggunakannya untuk tujuan lain, atau terus membagikannya. Jangan berasumsi bahwa hubungan dukungan umum mengizinkan penggunaan kembali yang tidak terkait atau akses luas.
Keputusan penyimpanan harus menangani salinan vendor dan salinan kerja organisasi. Catat durasi yang diinginkan atau pemicu penghapusan dan siapa yang dapat memverifikasi penyelesaian jika hal tersebut penting. Ini adalah proses tata kelola yang diusulkan, bukan klaim bahwa kontrak vendor telah memberikan ketentuan spesifik. Jika persyaratan yang tersedia atau akses penerima tidak jelas, selesaikan hal tersebut sebelum transmisi.
Penerimaan memerlukan reviewer untuk membandingkan paket akhir dengan peta lapangan yang disetujui. Lampiran sebenarnya, bukan hanya deskripsi, harus diperiksa untuk baris yang tidak berhubungan, data tersembunyi, dan rahasia yang tidak disengaja. Penerima yang berubah, kumpulan data yang diperluas, atau tujuan baru harus memicu tinjauan baru, bukan diperlakukan sebagai kelanjutan yang tidak berbahaya dari bagian yang sama.
Paket dukungan fiktif untuk satu rute penandatanganan
Bayangkan pemasok kwitansi fiktif sedang menyelidiki penyelarasan DKIM kegagalan. Laporan agregat mentah organisasi juga berisi surat karyawan dan observasi kampanye. Tidak ada laporan nyata atau permintaan vendor yang diakses untuk contoh ini. Paket yang diusulkan hanya berisi baris rute penerimaan yang relevan, interval pelaporan yang dibatasi, hubungan identitas terkait, dan penjelasan singkat tentang hal yang tidak pasti.
Baris karyawan dan kampanye dikecualikan karena tidak menjawab pertanyaan pemasok. Jika pemasok memerlukan domain atau pemilih penandatanganan yang tepat, organisasi harus menyetujui nilai tersebut untuk penerima dan tujuan tersebut. Sampel yang disunting dan mengaburkannya mungkin masih berguna untuk diskusi konseptual tetapi tidak dapat dianggap cukup untuk diagnosis DNS langsung.
Persetujuan akhir juga mencatat keputusan retensi berdasarkan kasus tertentu. Tidak ada paket yang dikirim hanya karena draft sudah selesai. Jika pemasok kemudian meminta contoh pesan lengkap, itu adalah permintaan konten baru dengan profil privasi berbeda, terutama jika itu memperkenalkan penerima atau badan pesan. Langkah berikutnya adalah tinjauan terbatas, bukan perluasan otomatis.
Bukti dan status rilis
Katalog memerlukan peta bidang data dan sampel bukti minimal yang disetujui dengan keputusan penyimpanan yang eksplisit. Artikel ini hanya memberikan metode persiapan dan desain paket fiktif. Tidak ada sampel sebenarnya yang disetujui, tidak ada penerima yang diselesaikan, dan tidak ada transmisi atau penghapusan vendor yang diverifikasi.
Keenam gerbang pelepasan tetap terbuka. Peninjau yang berkualifikasi harus memeriksa bahwa minimalisasi yang diusulkan mempertahankan pertanyaan diagnostik dengan tetap menghormati batasan penerima dan tujuan. Sebelum melakukan pembagian nyata, dapatkan otorisasi yang diperlukan untuk data dan tujuan sebenarnya. Draf yang disiapkan dengan aman merupakan kemajuan yang berharga, namun ini bukan bukti bahwa vendor menerima atau menangani apa pun.