Pengujian mengubah permintaan, bukan hasil autentikasi
Tag t saat ini DMARC adalah sinyal mode pengujian yang dilampirkan pada catatan kebijakan. Itu tidak mengubah pesan yang tidak diautentikasi menjadi pesan yang diautentikasi, dan tidak menjanjikan pengiriman. Tujuan kegunaannya adalah untuk memperhalus penilaian yang diminta untuk email yang gagal DMARC sekaligus memungkinkan penanganan khusus yang relevan. Oleh karena itu, rencana penerapan memerlukan dua keluaran independen: interpretasi kebijakan yang diharapkan dan perilaku aktual penerima.
RFC 9989 bagian 4.7 mendefinisikan t=y dan t=n, dengan n sebagai default. Pengujian beroperasi pada kebijakan penilaian mana pun yang dipilih dari p, sp atau np. Mulailah dengan menetapkan kebijakan tersebut dan apakah DMARC gagal. Jangan terapkan transformasi ke tag p sembarang ketika penggantian subdomain benar-benar mengatur pesan tersebut.
Bangun ekspektasi enam sel sebelum mengirim apa pun
Untuk kebijakan tidak ada yang dipilih, y dan n keduanya tidak memberikan penilaian yang diminta. Untuk karantina yang dipilih, y tidak meminta apa pun sementara n mempertahankan karantina. Untuk penolakan yang dipilih, y meminta karantina sementara n mempertahankan penolakan. Hasil none masih memungkinkan pemfilteran penerima biasa; ini bukan instruksi untuk melewati kontrol anti-penyalahgunaan atau jaminan bahwa pesan akan masuk ke kotak masuk.
Dalam desain tes fiksi, _dmarc.trial.north.example menyimpan satu catatan alternatif pada satu waktu, masing-masing dimulai v=DMARC1 dan berisi satu nilai p yang dipilih ditambah satu nilai t. Enam alternatif membentuk sebuah matriks, bukan enam catatan kebijakan TXT secara bersamaan. Beberapa catatan kebijakan pada nama kandidat yang sama merupakan masalah penemuan yang berbeda dan akan membatalkan perbandingan yang dimaksudkan. Tidak ada catatan yang diterbitkan dan tidak ada surat yang dikirim untuk artikel ini.
Pertahankan hasil yang diharapkan secara terpisah untuk pesan kontrol yang meneruskan DMARC. Pengujian tidak menulis ulang hasil tersebut menjadi gagal atau membuat gagal SPF hasil lulus. Otentikasi, penyelarasan, penilaian yang dipilih dan disposisi akhir harus menempati bidang yang berbeda dalam paket bukti. Jika tidak, tangkapan layar yang bertuliskan "terkirim" dapat mengaburkan perilaku yang ingin dibuat oleh eksperimen tersebut.
Sertakan penanganan khusus tanpa bergantung padanya
Definisi pengujian memungkinkan penanganan khusus yang relevan, seperti penulisan ulang dari lapangan oleh perantara, di samping penilaian yang lebih lunak. Dikatakan pengurangan penilaian itu berlaku terlepas apakah ada penanganan khusus atau tidak. Oleh karena itu, desain pengujian harus memperhatikan kedua dimensi tersebut dibandingkan membuat kebijakan yang dikurangi bergantung pada penulisan ulang yang terlihat.
RFC 9989 Lampiran A.6 menjelaskan sejarahnya: penanganan persentase yang tidak konsisten menyebabkan penghapusan pct, sementara praktik berguna seputar pct=0 menginformasikan tag biner baru. Riwayat tersebut tidak menjadikan t=y sebagai persentase pengambilan sampel lalu lintas atau klaim bahwa semua perilaku bersejarah direproduksi. Itu Registri IANA sekarang mencantumkannya sebagai aktif dan sebagian bersejarah. Entri registri tidak dapat menentukan perangkat lunak mana yang dijalankan oleh organisasi penerima.
Perantara dapat mengubah pengidentifikasi dengan cara yang mempengaruhi penyelarasan di kemudian hari. Pertahankan bukti pesan pra-perantara dan pasca-perantara hanya dalam pengujian yang aman dan aman bagi privasi. Jangan menyimpulkan mekanismenya hanya dari perubahan nama tampilan atau folder akhir. Laporan tersebut harus mengidentifikasi bidang persis yang diubah, lompatan di mana bidang tersebut diubah, dan hasil autentikasi yang terlihat di bagian hilir.
Penolakan akhir masih memerlukan analisis yang lebih luas dari penerima
Sel matriks berlabel penolakan menjelaskan penilaian yang diminta, bukan hasil SMTP otomatis. RFC 9989 bagian 7.4 mengharuskan penerima untuk tidak menolak hanya berdasarkan kebijakan penolakan domain pengirim. Mereka harus menggabungkannya dengan analisis lain, dan tanpa pengetahuan tambahan tersebut, mereka akan memperlakukan pesan yang gagal sebagai karantina. Pengujian yang mengabaikan perbedaan ini dapat menyebabkan kesalahan pada penerima yang sesuai.
Bagian yang sama menyoroti risiko penerusan dan interoperabilitas milis. Penolakan penerbitan domain tidak boleh hanya mengandalkan SPF untuk mengamankan izin DMARC dan harus berlaku valid DKIM tanda tangan. Mode pengujian tidak memperbaiki tanda tangan yang rusak atau menetapkan bahwa setiap rute tidak langsung aman. Sertakan pengiriman langsung dan jalur tidak langsung perwakilan yang disetujui ketika penerapan sebenarnya bergantung pada jalur tersebut, daripada melakukan ekstrapolasi dari satu kotak surat.
Cakupan klaim penerima dengan bukti yang dapat Anda simpan
RFC yang dipublikasikan merupakan referensi normatif, bukan pengumuman peluncuran untuk setiap penyedia. Implementasi yang lebih lama mungkin mengabaikan tag yang tidak dikenalinya, sehingga berpotensi membiarkan karantina yang dinyatakan atau penilaian penolakan tidak diperlunak. Ini adalah risiko yang harus dievaluasi, bukan temuan terukur mengenai penerima yang disebutkan namanya. Dokumentasikan pernyataan penyedia saat ini, versi perangkat lunak aktual bila tersedia, dan observasi spesifik yang mendukung setiap kesimpulan kompatibilitas.
Proses resmi yang diusulkan harus mempertahankan snapshot dan waktu kebijakan DNS , nama rekaman yang tepat, pengidentifikasi pesan, input penyelarasan, respons penerima, dan laporan apa pun yang tersedia. Catat penggantian kebijakan lokal secara terpisah. Ulangi perbandingan enam sel dalam kondisi terkendali daripada mengubah beberapa variabel pengirim sekaligus. Menyertakan ketentuan penghentian untuk penolakan yang tidak terduga dan mempertahankan rencana pengembalian yang disetujui; artikel ini tidak mengizinkan tindakan operasional tersebut.
Pelaporan juga tetap terpisah. Tag t itu sendiri tidak mengubah pembuatan laporan. Permintaan agregat menggunakan rua dan RFC 9990 aturan pelaporan; umpan balik kegagalan memiliki kondisi dan kebijaksanaan penerima sendiri. Umpan balik yang hilang tidak dapat membuktikan bahwa tag pengujian diabaikan, dan umpan balik saja mungkin tidak menjelaskan alasan disposisi akhir penerima secara lengkap.
Biarkan gerbang eksekusi terbuka dengan jujur
Komisi pastinya adalah: Uji t=y dan t=n dengan setiap kebijakan dan pertahankan hasil penerima. Paket ini berisi matriks enam sel asli yang diharapkan, disiapkan sebelum penyusunan, tetapi tidak ada hasil penerima. Oleh karena itu, ini tidak memenuhi persyaratan eksekusi tersebut. Gerbang bukti asli tetap terlihat terbuka dan tidak digantikan oleh klaim kesesuaian berdasarkan teks standar.
Sebelum dirilis, pemilik teknis harus menyetujui perlengkapan tersebut, pemilik operasional harus mengizinkan pengujian nyata, dan peninjau harus merekonsiliasi pengamatan dengan spesifikasi terkini dan ruang lingkup penerima. Verifikasi kesalahan, penerimaan spesialis, pemeriksaan jalur produksi, tinjauan visual, dan izin publikasi masih menunggu keputusan. Kesimpulan yang dapat dipertahankan saat ini adalah apa yang diminta oleh tag saat ini untuk dilakukan oleh implementasi yang sesuai, bersama dengan bukti tepat yang masih diperlukan untuk mengandalkannya.