Sebuah pesan dengan beberapa DKIM tanda tangan memerlukan penilaian per tanda tangan. Menghitung tanda tangan atau memilih hasil kelulusan pertama dapat salah mengidentifikasi domain yang mengautentikasi penulis yang terlihat. Di bawah RFC 9989 §4.4.1, setiap pengidentifikasi yang diautentikasi DKIM dan selaras dengan Domain Penulis dapat menyediakan jalur DKIM ke DMARC lulus.
Pertahankan identitas setiap hasil
Ekspor pesan mentah melalui proses yang disetujui. Catat domain Dari yang terlihat dan, untuk setiap tanda tangan, domainnya d= penandatanganan domain, s= pemilih, a= algoritma dan relevan kanonikalisasi pengaturan. Kaitkan hasil sistem penerima tepercaya dengan tanda tangan tersebut. Dua tanda tangan dapat menggunakan domain yang sama tetapi penyeleksi atau algoritme berbeda, sehingga domain saja mungkin tidak dapat membedakannya.
Jangan percaya sembarangan Authentication-Results bidang hanya karena muncul dalam pesan. RFC 8601 §1.2 menjelaskan batas kepercayaan untuk bidang tersebut. Gunakan hasil yang diatribusikan pada sistem penerima yang penilaiannya sedang Anda selidiki, dan pertahankan sumber tersebut saat mengekspor bukti. Pengirim dapat menyisipkan teks header yang menyesatkan; label status yang disalin bukan merupakan verifikasi independen.
Pertahankan verifikasi dan penyelarasan sebagai keputusan terpisah
Verifikasi menentukan apakah tanda tangan memvalidasi domain penandatanganannya. Penyelarasan membandingkan domain yang diautentikasi tersebut dengan Domain Penulis berdasarkan aturan DMARC yang berlaku. Tanda tangan penyedia yang tidak terkait dapat benar-benar valid tanpa mengautentikasi domain penulis yang terlihat untuk DMARC .
Untuk penyelarasan DKIM yang ketat, domain harus sama persis, dengan perbandingan kasus nama domain sebagai berikut RFC 1035 §2.3.3. Penyelarasan yang santai menggunakan hubungan organisasi-domainnya sebagaimana ditentukan oleh proses DMARC yang berlaku. RFC 9989 §4.10.2 mendefinisikan DNS Tree Walks untuk penentuan ini. Jangan memutuskan penyelarasan dari kata umum dalam dua nama domain, dan jangan diam-diam berasumsi bahwa setiap penerima telah mengadopsi penerapan penemuan terbaru.
Bekerja melalui pesan sintetis
Asumsikan kebijakan DMARC yang valid dan berlaku, Domain Penulis example.com dan tidak selaras SPF lulus. Tanda tangan A digunakan d=example.net, berhasil diverifikasi dan tidak selaras. Tanda tangan B digunakan d=example.com tetapi gagal verifikasi setelah perubahan konten hilir. Keduanya tidak menyediakan identitas DKIM yang selaras, sehingga kombinasi ini tidak menghasilkan pass DMARC .
Sekarang tambahkan tanda tangan C dengan d=example.com yang berhasil memverifikasi. Ini sejajar persis, sehingga menyediakan jalur DKIM ke jalur DMARC . Pass yang tidak terkait dan tanda tangan yang gagal tidak secara otomatis membatalkan C. Ini adalah evaluasi ilustratif, bukan klaim tentang pesan pelanggan yang diambil atau penempatan kotak surat yang terjamin.
Tuliskan contoh tersebut ke dalam kolom terpisah dalam catatan investigasi Anda: pengidentifikasi tanda tangan, hasil verifikasi, hasil penyelarasan, dan kontribusi terhadap DMARC . Jangan pernah menggabungkan pass tanda tangan A dengan domain selaras tanda tangan B untuk menghasilkan hasil yang tidak dicapai oleh tanda tangan individu.
Jelaskan mengapa ada banyak tanda tangan
Algoritme paralel, tanda tangan operasional penyedia, dan tanda tangan perantara selanjutnya dapat menghasilkan banyak hasil. Ini adalah hipotesis sampai konfigurasi rute dan penandatangan menentukan alasannya. RFC 8463 §6 menjelaskan penyeleksi berbeda untuk RSA dan Ed25519 tanda tangan peralihan; hasilnya harus dilacak secara individual.
Jika gateway menandatangani ulang email yang diubah, periksa domain barunya. Tanda tangan gateway yang lewat tidak secara otomatis memperbaiki otentikasi penulis asli. Jika organisasi mengontrol tahap penandatanganan akhir, verifikasi bahwa organisasi tersebut menandatangani konten pasca-pemrosesan yang dimaksudkan dengan identitas yang disetujui. Jangan menghapus tanda tangan yang tampaknya berlebihan tanpa memeriksa tujuan operasionalnya.
Tutup dengan kesimpulan tingkat pesan
Setelah menilai semua tanda tangan DKIM yang relevan, evaluasi pengidentifikasi dan penyelarasan SPF yang diautentikasi secara terpisah. Jika tidak ditemukan kebijakan DMARC yang berlaku, jangan memberi label ulang pada situasi tersebut sebagai kegagalan DMARC normal. Membedakan hasil autentikasi dari disposisi akhir penerima, yang dapat mencerminkan kebijakan atau penyaringan tambahan.
Simpan pesan asli, sumber hasil tepercaya, analisis per tanda tangan, dan alasan kesimpulan akhir. Jika alat pelaporan mengumpulkan tanda tangan secara berbeda, bandingkan bukti mentahnya sebelum memperlakukan ringkasan yang berbeda sebagai kontradiksi protokol. Hasil yang bermanfaat adalah jalur identitas yang dapat dijelaskan, bukan sekadar sejumlah besar indikator ramah lingkungan.
Catat contohnya tanpa mencampuradukkan identitas
Untuk pesan sintetis di atas, pertahankan satu baris per tanda tangan:
- A: example.net ; izin verifikasi; tidak ada penyelarasan; Kontribusi DKIM ke DMARC no.
- B: example.com ; verifikasi gagal; domain akan cocok tetapi tidak diautentikasi; Sumbangan DKIM no.
- C: example.com ; izin verifikasi; penyelarasan ya; Kontribusi DKIM ya.
Sebelum C hadir, tidak adanya SPF yang selaras tidak menyisakan jalan keluar. Dengan adanya C, DMARC lolos berdasarkan asumsi kebijakan yang berlaku. Tidak ada hasil penerima aktual atau hasil penempatan kotak masuk yang diklaim.
Bacaan terkait
Penyelarasan DKIM : bandingkan d= dengan domain Dari yang terlihat · Tanda tangan RSA dan Ed25519 DKIM : pertanyaan penerapan dan interoperabilitas.