Keputusan penegakan hukum memerlukan ambang batas bukti yang dapat dijelaskan oleh tim sebelum perubahan terjadi. Jika tidak, persentase yang sehat, masa tunggu yang berubah-ubah, atau hasil DNS berwarna hijau dapat menjadi pengganti untuk mengetahui pesan sah mana yang berisiko.
Tentukan kriteria seputar alur bisnis dan domain yang dinilai. Hasilnya harus berupa catatan keputusan yang menjelaskan mengapa perubahan tertentu dapat dibenarkan, apa yang masih belum pasti, dan siapa yang akan bertindak jika pesan penting tidak lagi sampai.
Definisikan keputusan dengan tepat
Tuliskan domain yang tepat, tujuannya, dan perubahan kebijakan yang sedang dipertimbangkan. Keputusan tentang domain tanda terima khusus tidak secara otomatis berlaku untuk email karyawan atau merek yang baru diakuisisi.
Identifikasi pemilik yang menyetujui dan konsekuensi operasional dari suatu kesalahan. Pemberitahuan penting yang gagal mungkin lebih berarti daripada ribuan pesan berisiko rendah yang disampaikan. Masukkan aliran-aliran penting tersebut ke dalam kriteria bukti, meskipun volumenya kecil.
Gunakan panduan pemilihan kebijakan untuk menilai kesesuaian. Penilaian yang lebih kuat bukanlah tujuan otomatis untuk setiap domain: Panduan interoperabilitas dalam RFC 9989 §7.4 sangat relevan dengan partisipasi milis Internet dan surat tujuan umum.
Bangun kriteria yang jelas bisa gagal
Kerangka penerimaan berikut ini merupakan rekomendasi pengoperasian asli. Ini bukan daftar periksa yang diamanatkan protokol atau klaim bahwa setiap organisasi memiliki toleransi risiko yang sama.
- Kriteria: Pelayanan penting diketahui dan dimiliki; Bukti yang dapat mendukungnya: Inventaris ditautkan ke akun, rute, dan pemilik bisnis yang disetujui; Alasan untuk tetap membiarkan keputusan tetap terbuka: Layanan penting tidak memiliki pemilik atau rute yang tidak dapat dijelaskan
- Kriteria: Identitas yang diinginkan berfungsi; Bukti yang dapat mendukungnya: Bukti pesan yang diterima dari setiap rute yang terpengaruh, dengan otentikasi dan penyelarasan tercatat; Alasan untuk tetap membiarkan keputusan tetap terbuka: Hanya status DNS atau pass mentah yang tidak terkait yang tersedia
- Kriteria: Aliran periodik tercakup; Bukti yang dapat mendukungnya: Sampel representatif atau pengujian terdokumentasi yang mencakup siklus bisnis yang relevan; Alasan untuk tetap membiarkan keputusan tetap terbuka: Layanan bulanan atau tahunan belum diperiksa
- Kriteria: Penggunaan tidak langsung dinilai; Bukti yang dapat mendukung hal ini: Kasus-kasus forwarder dan milis yang diketahui dengan temuan rute spesifik; Alasan mengapa keputusan tetap terbuka: Partisipasi daftar staf diabaikan
- Kriteria: Observasi diinterpretasikan dengan benar; Bukti yang dapat mendukungnya: Pelapor, periode, kesalahan, dan kesenjangan yang diketahui dijelaskan bersama dengan bukti layanan; Alasan untuk membiarkan keputusan tetap terbuka: Persentase diperlakukan sebagai buku besar surat terkirim yang lengkap
- Kriteria: Pemulihan dapat dijalankan; Bukti yang dapat mendukungnya: Nama pemilik, catatan sebelumnya, pemicu keputusan dan langkah verifikasi; Alasan untuk tetap membiarkan keputusan tetap terbuka: Tidak ada yang bisa mengubah DNS yang terpengaruh atau memulihkan layanan
Setiap kriteria yang gagal akan menghasilkan pemilik dan tindakan selanjutnya. Hindari daftar periksa yang dapat ditandai hijau tanpa bukti terlampir atau yang memberikan penghargaan kepada tim karena menulis “tidak berlaku” tanpa penjelasan.
Periksa bukti identitas pada tingkat pesan
Untuk setiap aliran kritis, pertahankan domain Dari, identitas yang dievaluasi SPF, dan relevan DKIM menandatangani domain dan hasil penerima. Tunjukkan identitas penerusan mana yang sesuai dengan kebijakan yang berlaku. Pass mentah untuk domain milik layanan dapat hidup berdampingan dengan a DMARC kegagalan untuk domain Dari organisasi.
Bedakan juga pesan yang lewat dari partisipasi penuh pemilik domain. Di bawah RFC 9989 §5.3.5, satu mekanisme penerusan yang selaras dapat menetapkan kondisi kelulusan DMARC tingkat pesan ketika ada kebijakan yang berlaku. Persyaratan partisipasi dalam RFC 9989 §8 penutup sejajar SPF dan DKIM , pelaporan, publikasi kebijakan dan tindakan lainnya. Di bawah RFC 9989 §7.4, penolakan penerbitan domain tidak boleh hanya mengandalkan SPF dan harus menggunakan tanda tangan DKIM yang valid.
Catat apa yang sebenarnya diuji. Demonstrasi melalui pengirim default penyedia tidak menetapkan bahwa aplikasi produksi menggunakan identitas atau akun yang sama. Jika penyedia mendukung beberapa rute, sebutkan rute tersebut dalam bukti.
Gunakan contoh keputusan sintetik
Bayangkan sebuah domain layanan khusus dengan tiga alur yang diketahui: tanda terima, pemberitahuan akun, dan laporan pajak triwulanan. Tanda terima dan peringatan telah menerima sampel terkini dan pemilik yang jelas. Layanan triwulanan disetujui tetapi status penandatanganan produksinya belum diperiksa.
Itu laporan agregat menunjukkan tingkat kelulusan yang tinggi didominasi oleh penerimaan. Pengamatan tersebut berguna namun tidak memenuhi kriteria aliran kritis untuk laporan pajak. Tindakan selanjutnya yang benar adalah mendapatkan tes yang representatif dan mengonfirmasi jalur identitas yang diinginkan.
Misalkan pengujian resmi kemudian memberikan bukti yang hilang dan pemilik mengonfirmasi konfigurasi produksi. Peninjau sekarang dapat mempertimbangkan kembali perubahan tersebut menggunakan bukti baru tersebut. Ini adalah kemajuan sintetik; tidak ada tes aktual, tingkat kelulusan terukur, atau persetujuan yang ditegaskan di sini.
Menyatakan batasan pengamatan secara terbuka
Struktur laporan dan partisipasi penerima dijelaskan dalam RFC 9990 §3.1 Dan RFC 9989 §5.3.8. Jendela pelaporan yang tenang mungkin mencerminkan volume pengiriman yang rendah, partisipasi penerima yang tidak lengkap, atau autentikasi yang berhasil. Ia tidak dapat menentukan penjelasan mana yang berlaku tanpa bukti yang mendukung.
Oleh karena itu, jumlah hari yang tetap bukanlah tes kesiapan umum. Periode yang relevan bergantung pada siklus bisnis domain dan panduan yang berlaku. Untuk domain dengan potensi penggunaan milis Internet yang mempertimbangkan penolakan meskipun telah berhati-hati, RFC 9989 memberikan panduan pemantauan dan perbandingan karantina yang spesifik; hal ini tidak boleh digantikan dengan janji tujuh hari yang umum.
Menggunakan panduan kebijakan pemantauan untuk menentukan apa yang diharapkan diungkapkan oleh periode observasi. Pisahkan tidak adanya bukti dari bukti bahwa layanan tidak dikirimkan.
Buatlah persetujuan dan pemulihan menjadi nyata
Catatan persetujuan harus menghubungkan setiap kriteria dengan bukti-buktinya dan mencatat risiko-risiko yang belum terselesaikan. Pertahankan nilai DNS sebelumnya dan perbedaan persis yang diusulkan. Sebutkan orang yang dapat bertindak, rencana verifikasi dan kondisi yang akan memicu peninjauan atau pemulihan.
Pemulihan adalah proses pengambilan keputusan, bukan janji yang akan disebarkan secara instan. Cache DNS dapat menyimpan informasi sebelumnya, termasuk penggunaan jawaban basi yang memenuhi syarat setelah masa berlaku TTL berakhir RFC 8767 §4. Miliki rencana untuk berkomunikasi dengan pemilik layanan yang terpengaruh dan menguji ulang rute tertentu saat observasi konfigurasi menyatu.
Setelah perubahan disetujui, periksa DNS aktual dan hasil aliran sah serta tinjau periode pelaporan yang mencakup perubahan tersebut. Catat temuan dan tindakan perbaikan. Formulir persetujuan yang telah diisi sebelum penerapan tidak menggantikan verifikasi selanjutnya.
Ambang batas bukti terpenuhi ketika tim dapat memperhitungkan komunikasi penting yang sah, membenarkan kebijakan yang dipilih untuk domain tersebut, dan pulih dari hasil yang tidak diharapkan. Pertahankan kriteria dalam inventaris layanan sehingga permohonan berikutnya atau perubahan pemasok dapat dinilai berdasarkan standar yang sama.
Catat keputusan yang dapat ditinjau
Dalam contoh tiga alur, biarkan kriteria laporan pajak tetap terbuka sampai bukti yang mewakili diperoleh, bahkan jika penerimaan mendominasi persentase yang sehat. Keputusan tersebut dapat berupa penundaan, ruang lingkup yang lebih sempit, atau batasan yang diterima secara eksplisit dengan pemilik yang bertanggung jawab. Ini adalah opsi tata kelola editorial, bukan persetujuan protokol otomatis, dan artikel ini tidak menyetujui perubahan nyata apa pun.