Pesan masuk dapat melewati autentikasi domain dan tetap meminta penerimanya melakukan sesuatu yang berbahaya. Itu juga dapat gagal dalam otentikasi karena rute yang sah rusak. Perlakukan autentikasi sebagai salah satu properti pesan yang terukur, lalu terapkan kontrol lain pada sistem penerima dan proses verifikasi bisnis organisasi. Menghentikan langkah-langkah ini akan menghasilkan jaminan palsu dan gangguan yang tidak perlu.
Identifikasi ketiga keputusan tersebut
Keputusan pertama bersifat teknis: apakah pengidentifikasi yang diautentikasi selaras dengan domain penulis berdasarkan ketentuan yang berlaku DMARC aturan? Yang kedua bersifat operasional: bagaimana seharusnya lingkungan penerima pesan menangani pesan tersebut, dengan mempertimbangkan kebijakan dan sinyal lainnya? Yang ketiga adalah spesifik bisnis: apakah tindakan yang diminta sah dan sah? RFC 9989 mendefinisikan otentikasi dan kebijakan berbasis domain; itu tidak mengubah pesan yang lewat menjadi persetujuan untuk membayar faktur. spesifikasi DMARC.
Catat keputusan ini di kolom terpisah. Untuk permintaan perubahan faktur, bidang autentikasi mungkin lulus, karantina bidang penanganan menunggu peninjauan, dan bidang bisnis belum diverifikasi. Nilai-nilai tersebut sejalan. Penerima dapat menggunakan sinyal di luar DMARC , dan karyawan harus mengikuti alur kerja persetujuan independen bahkan ketika email telah diautentikasi.
Gunakan hasil dari batas tepercaya
Sebuah Header Authentication-Results berguna hanya jika asal usulnya dipahami. Penyerang dapat memasukkan teks header ke dalam pesan. Organisasi penerima harus membedakan hasil yang dihasilkan oleh layanan autentikasi tepercaya dari pernyataan yang tidak tepercaya. RFC 8601 menjelaskan batas kepercayaan tersebut. Hasil Otentikasi.
Pertahankan pesan mentah dan log sistem penerima tepercaya. Bandingkan domain Dari yang terlihat dengan setiap domain terverifikasi DKIM penandatanganan domain dan SPF identitas sebenarnya dievaluasi. Hindari memperlakukan nama tampilan, bidang Balas Ke, atau tangkapan layar yang diteruskan sebagai domain penulis yang diautentikasi. Jika pesan diteruskan, catat titik evaluasi awal dan transformasi selanjutnya sebelum memutuskan bukti mana yang berlaku.
Bandingkan tiga permintaan sintetis
Pertimbangkan tiga pesan hipotetis perubahan pembayaran. Yang pertama mengklaim brand.test tetapi hanya memiliki tanda tangan evil.test yang lulus dan tidak memiliki izin SPF ; satu-satunya pengidentifikasi terautentikasi yang diasumsikan gagal total penyelarasan. Yang kedua menggunakan brand-pay.test di From dan melewati identitas DKIM , sehingga autentikasi yang dimodelkan berhasil meskipun ada masalah yang serupa. Yang ketiga menggunakan brand.test secara konsisten dan juga lolos, sehingga memungkinkan terjadinya penyalahgunaan akun atau permintaan yang tidak sah.
Tindakan bisnis yang diusulkan untuk setiap kasus adalah: menahan perubahan dan memverifikasinya secara independen. Ini adalah masukan autentikasi yang diciptakan, bukan hasil kriptografi atau penerima. Kasus tertulis mengasumsikan identitas yang disebutkan adalah satu-satunya pengidentifikasi terautentikasi yang tersedia, mengisolasi pencocokan domain persis yang ketat, dan tidak menerapkan penemuan DMARC penuh. Tidak ada tes pesan, tanda tangan, atau penerima yang dijalankan. Hal ini menunjukkan mengapa tindakan bisnis tidak dapat dihitung hanya dari boolean autentikasi saja.
Penanganan desain tanpa melewati review
Pilih pesan pengujian resmi untuk setiap jalur kontrol dan catat apakah sistem menolak, mengkarantina, mengirimkan, atau memperbaikinya nanti. Label fitur vendor bukanlah bukti perilaku Anda yang dikonfigurasi. Sertakan pengecualian dan izinkan aturan dalam pengujian karena hal tersebut dapat mengubah hasil efektif. Hindari pemberian izin secara luas hanya untuk membuat jalur sah yang rusak bisa dilewati.
Untuk permintaan keuangan, gunakan saluran kontak yang telah dibuat sebelumnya. FBI merekomendasikan untuk memverifikasi permintaan pembayaran dan perubahan detail rekening secara independen. Jangan gunakan rincian kontak yang dimasukkan oleh pesan mencurigakan sebagai saluran independen. Panduan kompromi email bisnis FBI.
Tutup tinjauan dengan ketiga keputusan tersebut, bukti untuk setiap masalah yang belum terselesaikan. Hal ini memungkinkan tim email untuk memperbaiki autentikasi sementara bagian keuangan mempertahankan penangguhan pembayaran, atau keamanan untuk menyelidiki pesan yang lewat namun mencurigakan tanpa mengklaim DMARC rusak.
Batas sumber dan eksekusi
RFC 9989 Bagian 4.4, 5.3.5 dan 5.4 membedakan otentikasi, penyelarasan dan penanganan; pass tidak mendukung konten pesan. Keputusan operasional di sini adalah rekomendasi yang tercakup dan contoh hipotetis yang eksplisit, bukan pengujian baru terhadap pelanggan, penyedia, atau perlengkapan historis. Setiap perubahan nyata memerlukan cakupan resminya sendiri, bukti yang disimpan, dan keputusan yang dapat dipertanggungjawabkan.