Valid secara kriptografis ARC rantai dapat berasal dari perantara yang penerimanya tidak mempunyai alasan untuk mempercayainya. Sebaliknya, layanan yang familiar dapat menghasilkan rantai putus yang tidak boleh dianggap sebagai bukti sah. Bangun keputusan sebagai tahapan terpisah: verifikasi protokol, kepercayaan pada perantara, interpretasi hasil sebelumnya, dan penanganan pesan akhir. Menggabungkannya ke dalam satu tanda izin membuat pemecahan masalah dan peninjauan penyalahgunaan menjadi lebih sulit.
Tetapkan apa yang dibuktikan validasi
Referensi: RFC 8617 §5.2, RFC 8617 §9.
Validasi ARC memeriksa rantai berdasarkan aturan struktural dan kriptografi protokol. Itu tidak secara independen mereproduksi pengamatan otentikasi setiap perantara sebelumnya. Hal ini juga tidak menyatakan bahwa kontrol akun perantara, pemfilteran, atau logika penilaiannya baik. RFC 8617, khususnya pertimbangan keamanannya, menyatakan batas antara validasi rantai dan kepercayaan.
Simpan implementasi dan versi pemverifikasi, waktu evaluasi, domain penandatanganan, penyeleksi, dan detail kegagalan. Ketika validasi gagal, bedakan kumpulan yang salah format dengan kunci yang hilang, kegagalan tanda tangan, dan penyebab diagnosis lainnya. Label kegagalan yang luas berguna untuk perutean tetapi tidak cukup untuk membenarkan perubahan konfigurasi. Jangan mempercayai rantai yang tidak valid karena nama mereknya sudah dikenal.
Tentukan cakupan kepercayaan
Referensi: RFC 8617 §7.2.1.
Untuk konfigurasi penerima sebenarnya, dokumentasikan pemilik perantara, rute yang diharapkan, alasan mengandalkan penilaiannya, tanggal peninjauan dan prosedur pemindahan. Tinjau perannya dalam modifikasi pesan dan kemampuannya untuk membedakan pengiriman yang diautentikasi dari email yang disuntikkan. Mempercayai suatu domain hanya karena domain tersebut muncul dalam pesan memungkinkan penyerang untuk menentukan sumber bukti.
Dokumentasi penyedia mungkin memperlihatkan pengendalian tertentu. Microsoft, misalnya, mendokumentasikan konfigurasi sealer ARC tepercaya, tetapi hal itu tidak membuat domain sembarangan sesuai untuk daftar tersebut. Konsultasikan fitur dan izin khusus penyewa saat ini sebelum perubahan resmi. Penyegel ARC tepercaya Microsoft adalah panduan implementasi, bukan rekomendasi kepercayaan menyeluruh.
Jalankan tes keputusan negatif
Referensi: RFC 8617 §7.2.1, RFC 8617 §9.3.
Perlengkapan lokal menyediakan lima kombinasi. Bukti yang valid namun tidak dapat dipercaya ditolak oleh contoh gerbang pengesampingan. Bukti yang tidak valid namun terpercaya juga ditolak. Kepercayaan dan validitas yang baik tanpa persetujuan sebelumnya tidaklah cukup. Masukan yang menguntungkan memenuhi syarat untuk penggantian contoh, sementara masukan konten berbahaya masih menghalangi penerimaan kebijakan mainan.
Latihan ini menunjukkan pemisahan keputusan dan mencatat keluaran lokalnya. Ini bukan kebijakan wajib ARC atau penyedia mana pun. Itu tidak melakukan pengambilan DNS , memverifikasi rantai nyata atau memodelkan semua reputasi dan memfilter sinyal. Masukan harus tetap diberi label sintetis sehingga pengujian lokal yang lulus tidak akan tertukar dengan penerapan penyedia yang berhasil.
Mengikat perubahan operasional
Referensi: RFC 9989 §7.4.
Sebelum menambahkan atau menghapus entri kepercayaan, identifikasi aliran yang terkena dampak dan pertahankan konfigurasi sebelumnya. Gunakan pesan pengujian resmi dengan kontrol negatif yang diharapkan, termasuk sealer yang tidak tepercaya dan rantai yang tidak valid. Rekam arus DMARC hasil secara terpisah dari pengiriman akhir dan alasan penggantian apa pun. Hindari perubahan yang secara diam-diam mengabaikan malware yang tidak terkait atau perlindungan peniruan identitas.
Jadwalkan peninjauan ketika perantara mengubah kepemilikan, perilaku pemrosesan, atau postur keamanan. Standar lintasan juga berfungsi: pemeriksaan tanggal 8 November 2026 menemukan bahwa proposal Eksperimental RFC 8617 dan proposal Historis masih dalam rancangan kerja aktif. Jangan menyebut proposal sudah selesai pensiun atau mengabaikan relevansinya dengan ketergantungan di masa depan. Bukti yang disimpan mencakup rantai lokal yang terverifikasi dan keputusan lokal di bawah ini; kasus penerapan eksternal tetap terbuka.
Bukti laboratorium yang disimpan
Referensi: RFC 8617 §5.2.
Eksperimen yang dipertahankan pada 7 November 2026 memperoleh validitas rantai dari verifikasi kriptografi dkimpy yang sebenarnya. Rantai penandatanganan yang valid dijalankan melalui konfigurasi lokal yang tepercaya dan tidak tepercaya, sehingga masing-masing menghasilkan keputusan yang memenuhi syarat dan tidak memenuhi syarat. Pesan yang dirusak gagal divalidasi meskipun kepercayaan diaktifkan. Lebih awal SPF Dan DKIM hasilnya berasal dari pyspf dan dkimpy, dan pemeriksaan kebijakan lokal eksplisit yang sebelumnya ketat penyelarasan lulus. Penandatanganan dan gangguan ARC terjadi secara offline setelah penangkapan SMTP enam pesan. Fungsi keputusan terpisah menggunakan input kepercayaan yang dikonfigurasi, bukan pengiriman SMTP tambahan. Hal ini menghasilkan bukti model keputusan yang terbatas untuk laboratorium yang dikontrol, tanpa mengklaim bahwa Microsoft atau penyedia lain menerapkan kebijakan tersebut.
Pelari dan tangkapan yang ditahan diperiksa; tidak ada eksperimen jaringan yang dijalankan ulang untuk tinjauan ini. Eksperimen awal hanya menggunakan loopback dan tidak mengirimkan email Internet. Penerimanya menciptakan Authentication-Results dari pemeriksaannya sendiri, sehingga bidang tersebut diketahui berasal dari laboratorium. Hasil autentikasi dan disposisi tetap terpisah: keenam sampel SMTP menerima 250 berdasarkan kebijakan pengambilan eksplisit, termasuk sampel yang gagal. Batas kepercayaannya adalah laboratorium terkontrol ini, bukan penyedia kotak surat produksi. Adaptor DNS menyediakan jawaban perlengkapan yang dipertahankan daripada menanyakan DNS publik, dan evaluator DMARC hanya menggunakan kesetaraan domain yang ketat. Penemuan domain organisasi secara penuh, penguraian kebijakan produksi, dan hasil penerapan langsung masih belum teruji.
Draf klasifikasi ulang Historis yang aktif merekomendasikan agar tidak menerapkan atau mengandalkan ARC antara pengirim dan penerima yang berbeda. Ini adalah proposal penting yang perlu dipertimbangkan ketika merencanakan ketergantungan baru, bukan menyelesaikan masa pensiun atau bukti bahwa penyedia saat ini telah menonaktifkan ARC . Pertahankan penilaian ketergantungan spesifik penyedia layanan tertanggal sementara proses standar berlanjut.