Label hasil bukanlah diagnosis
kesalahan perm menunjukkan kesalahan permanen dalam SPF evaluasi, tetapi tidak mengidentifikasi cacat yang unik. Kebijakan yang dipilih salah format, dapat diterapkan beberapa kali Catatan SPF, kebijakan rekursif yang hilang atau batas evaluasi yang terlampaui dapat menghasilkan hasil ini melalui aturan yang berbeda. Respons dukungan yang menerjemahkan setiap permerror menjadi “terlalu banyak pencarian DNS ” dapat mengarahkan administrator ke perbaikan yang salah dan berpotensi merusak otorisasi pengirim yang valid.
Mulailah dengan menjaga identitas dan masukan yang digunakan untuk evaluasi. Catat alamat penghubung, HELO atau KIRIM DARI konteks, domain yang dievaluasi, argumen pengirim dan waktu. Kemudian pertahankan respons DNS aktual dan kebijakan SPF yang dipilih. Tanpa masukan-masukan tersebut, dua laporan yang berbeda mungkin akan membahas identitas atau gambaran yang berbeda, dan bukannya berbeda pendapat mengenai kebijakan yang sama. RFC 7208 , bagian 2.3, 2.4 dan 8.7
Periksa pemilihan rekaman dan sintaksis terlebih dahulu
Pemilihan kebijakan SPF memiliki aturan khusus. Beberapa catatan SPF yang dipilih menyebabkan permerror ; kebijakan-kebijakan tersebut tidak digabungkan ke dalam kebijakan yang lebih besar dan tidak boleh diperlakukan sebagai cara yang mudah untuk membagi pemasok. String karakter TXT dalam satu catatan berbeda dengan beberapa catatan independen. Pertahankan batasan catatan sehingga reviewer dapat membedakan detail presentasi dari masalah seleksi sebenarnya.
Sintaksnya juga memerlukan tinjauan kebijakan yang lengkap. RFC 7208 memerlukan pemeriksaan sintaksis sebelum evaluasi mekanisme; Oleh karena itu, mekanisme yang tidak valid dapat menjadi masalah meskipun seseorang mengharapkan mekanisme sebelumnya akan cocok. Mekanisme yang tidak dikenal dan pengubah yang tidak dikenal yang diabaikan bukanlah kategori yang dapat dipertukarkan. Hindari panduan yang tidak jelas untuk menghapus setiap token yang tidak dikenal. Tentukan peran tata bahasanya dan penanganan standarnya sebelum memutuskan apakah itu merupakan kesalahan. RFC 7208 , bagian 3.2, 4.5, 4.6 dan 6
Kemudian klasifikasikan kegagalan evaluasi-anggaran
Untuk keseluruhan anggaran jangka penyebab DNS, sertakan, a, mx, ptr, ada dan jumlah pengalihan selama evaluasi. Batasnya sepuluh, dan melampauinya pasti menghasilkan permerror . Ini bukan sekadar jumlah paket DNS , jumlah penyertaan tingkat atas, atau jumlah pemasok unik. Rekursi membagi anggaran, dan caching tidak menghapus istilah yang dievaluasi secara logis.
Batasan lain memerlukan labelnya sendiri. Respons kosong memiliki batas tingkat HARUS sebesar dua, dengan konfigurasi yang diizinkan dan default yang disarankan sebesar dua jika dapat dikonfigurasi; melebihi batas yang berlaku menghasilkan permerror . Pemrosesan MX memiliki batasan wajib tambahan. Pernyataan bahwa “catatan hanya memiliki sembilan penyertaan” tidak mengecualikan penyebab-penyebab lain ini, dan jumlah paket mentah yang tinggi tidak dengan sendirinya membuktikan batas sepuluh jangka waktu keseluruhan telah terlampaui. RFC 7208 , bagian 4.6.4
Pisahkan hasil kesalahan dari hasil otorisasi
Gagal menegaskan bahwa klien tidak berwenang untuk identitas yang dievaluasi. Permerror berarti evaluasi tidak dapat memberikan hasil otorisasi yang diharapkan karena kesalahan permanen. Temporer mewakili kesalahan sementara. Tidak ada juga merupakan hasil yang berbeda, dengan pemetaan khusus ketika ditemui melalui penyertaan atau pengalihan. Label ini tidak boleh diciutkan menjadi satu wadah “ SPF gagal” saat menjelaskan tindakan perbaikan.
Penerima masih memutuskan bagaimana menangani hasil berdasarkan kebijakannya sendiri. Pesan yang ditolak tidak menentukan cacat SPF mana yang menyebabkan penolakan kecuali ada bukti yang mendukung tautan tersebut. Demikian pula, surat yang diterima tidak membuktikan bahwa kebijakan tersebut valid. Simpan diagnosis autentikasi dan disposisi pengiriman di kolom terpisah, dan hindari menjanjikan bahwa satu perbaikan DNS akan memperbaiki setiap masalah pengiriman. RFC 7208 , bagian 5.2, 6.1 dan 8
Lembar kerja triase dengan alasan penghentian yang jelas
Gunakan lembar kerja yang dibagi menjadi seleksi, parsing dan evaluasi. Dalam pilihan, pertahankan nama kueri, respons, catatan TXT batas dan jumlah catatan SPF yang dipilih. Dalam penguraian, pertahankan teks rekaman gabungan yang tepat, versi pengurai, token yang melanggar jika ada, dan aturan yang dilanggar. Jangan menormalkan kesalahan sebelum menyimpan bukti asli.
Dalam evaluasi, catat setiap mekanisme atau pengubah yang dicapai, domain saat ini, target yang diperluas, jumlah jangka waktu kumulatif, klasifikasi respons, hasil turunan rekursif, dan keputusan kelanjutan. Jaga agar total kekosongan dan batas tambahan tetap berbeda. Tandai alasan penghentian pertama yang didukung. Jika parser menolak kebijakan sebelum evaluasi, jangan menciptakan jalur yang tidak pernah dijalankan oleh evaluator hanya untuk menunjukkan kemungkinan masalah lainnya.
Koreksi yang diusulkan harus menyebutkan cacat yang ditanganinya, pemilik yang mengonfirmasi otorisasi yang dimaksudkan, dan rute yang masih harus berfungsi. Catat temuan sekunder yang belum terselesaikan secara terpisah. Kebijakan yang salah formatnya mungkin juga memuat grafik ketergantungan yang berlebihan, namun penyelidik harus menjelaskan kesimpulan mana yang diamati dan mana yang tetap menjadi perhatian statis sambil menunggu evaluasi yang valid.
Diagnosis fiktif: dua label identik, perbaikan berbeda
Dalam kasus fiktif A, sebuah domain menerbitkan dua data TXT terpisah yang keduanya memenuhi syarat sebagai kebijakan SPF . Diagnosis yang berguna adalah kesalahan pemilihan rekaman, bukan jumlah pencarian yang berlebihan. Usulan perbaikan memerlukan rekonsiliasi otorisasi yang dimaksudkan ke dalam satu kebijakan yang didukung, setelah mengonfirmasi semua rute yang sah. Menghapus catatan sewenang-wenang dapat menghapus layanan yang diperlukan secara diam-diam. Tidak ada respons atau koreksi DNS nyata yang dikumpulkan untuk kasus ini.
Dalam kasus fiksi B, satu kebijakan yang valid secara sintaksis mengikuti rute bersarang yang mencoba menghitung istilah penyebab DNS yang kesebelas sebelum kecocokan apa pun. Diagnosis yang berguna adalah anggaran keseluruhan yang terlampaui. Menggabungkan string TXT tidak akan menyelesaikan masalah tersebut karena kebijakannya sudah berupa satu data yang dipilih. Peninjauan tersebut memerlukan jalur ketergantungan yang tepat dan dukungan desain ulang yang mempertahankan cakupan pengirim.
Laporan fiksi ketiga hanya menyebutkan “ permerror ” dan tidak berisi cuplikan atau jejak rekaman. Hasil yang benar adalah bukti yang tidak cukup, bukan tebakan antara A dan B. Mintalah paket diagnostik minimal melalui saluran resmi, dengan pengecualian konten pesan pribadi dan alamat yang tidak perlu. Skenario ini adalah perbandingan konseptual, bukan perlengkapan yang dijalankan, hasil penerima, atau bukti bahwa penyedia bernama salah dikonfigurasi.
Kriteria penerimaan dan pelepasan
Klaim perbaikan harus lebih sempit daripada “ SPF tetap.” Nyatakan apakah pemilihan catatan, sintaksis, jalur evaluasi tertentu, atau ketergantungan pemasok tertentu telah diperbaiki dan bukti apa yang mendukung klaim tersebut. Validasi bahwa perubahan yang diusulkan tidak mengizinkan pengirim yang tidak diinginkan atau mengecualikan pengirim yang sah. Simpan hasil akhir pengiriman penerima di luar klaim kecuali jika diamati secara terpisah.
Untuk draf ini, jalur beranotasi yang diperlukan yang menunjukkan setiap istilah yang dihitung dan cabang yang gagal tetap ada. Jika permasalahan sebenarnya adalah penguraian atau seleksi, simpan juga bukti utama tersebut dan dapatkan tinjauan manusiawi mengenai bagaimana bukti tersebut memenuhi cakupan artikel yang dimaksudkan. Jangan membuat jalur yang dievaluasi untuk kesalahan yang berhenti sebelum mekanisme diproses.
Tidak ada pemindaian, eksekusi parser, modifikasi DNS , atau pengujian pesan yang dilakukan di sini. Bukti asli, tinjauan manusia, penerapan sumber, jalur produksi, aksesibilitas visual, dan pelepasan pemilik tetap terbuka. Naskah ini memberikan kerangka triase dan contoh penalaran fiksi sambil secara eksplisit menyembunyikan klaim diagnosis operasional yang telah selesai.