Verifikasi dependensi sebelum mengedit DNS
Penerbitan a BIMI pernyataan adalah perubahan DNS kecil dengan beberapa ketergantungan eksternal. Catatan tersebut mungkin mengacu pada logo atau dokumen bukti yang dihosting oleh tim lain, dan penyedia penerima dapat menolak file yang dapat dibaca karena sertifikat atau ketentuan autentikasinya tidak terpenuhi. Mulailah dengan domain yang disetujui, paket khusus penerima, dan versi aset yang tepat, bukan string TXT umum.
Panduan ini mencakup alur kerja pemilih default yang terdokumentasi. Dokumen BIMI versi-15 yang dipertahankan menjelaskan penyeleksi tambahan dan aturan penemuan, namun tetap merupakan Draf Internet, bukan RFC. Jangan perkenalkan tingkat lanjut pemilih perilaku hanya karena platform pengirim dapat menyisipkan header; konfirmasikan implementasi pengirim dan penerima yang dimaksud terlebih dahulu. BIMI Internet-Draf 15, bagian 4.3–4.4.
Tetapkan pemilik dan nilai pernyataan yang benar
Untuk kasus default sederhana di example.com, pemilik pernyataan adalah default._bimi.example.com. Tag versinya adalah v=BIMI1; lokasi indikator yang digunakan l=, dan lokasi bukti otoritas yang digunakan a=. Draf tersebut mendefinisikan lokasi bukti sebagai sintaksis opsional, namun hal ini tidak menjadikan bukti opsional bagi setiap penerima. BIMI Internet-Draf 15, bagian 4.3.
Ilustrasi fiksi lokasi ganda adalah v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem. Ini bukan catatan produksi, aset yang dihosting, atau rekomendasi sertifikat. Ganti pernyataan asli maupun URL sertifikat asli dengan nilai contoh tersebut.
Google mendokumentasikan penyiapan berbasis PEM untuk Gmail , termasuk contoh yang kosong l= nilai dan lokasi sertifikat di a=. Catatan khusus SVG bukanlah jalur implementasi yang sama. Pilih formulir yang didukung oleh penerima target dan bukti yang diberikan daripada memperlakukan setiap contoh yang diterbitkan sebagai hal yang dapat dipertukarkan. Penyiapan Google BIMI , langkah 2–4.
Periksa kebijakan otentikasi yang berlaku
Konfirmasikan Domain Penulis dan kebijakan domain organisasi yang berlaku menggunakan kebijakan terkini DMARC aturan penemuan. Kemudian periksa pesan sebenarnya dari rute yang dimaksudkan untuk autentikasi yang selaras. BIMI Group menyerukan penegakan hukum dan mencatat terbatasnya dukungan terhadap catatan yang dibuat sendiri, namun baik teks kebijakan maupun hasil pembuat catatan tidak membuktikan bahwa pengirim siap. Panduan implementasi BIMI; RFC 9989 , bagian 4.4 dan 4.10.
Dokumentasi penyedia harus dibaca dengan konteks versinya. Halaman Google saat ini masih menyertakan pct=100, sedangkan RFC 9989 menghapus tag itu. Pertahankan perbedaan ini sebagai pertanyaan kompatibilitas untuk administrator email. Jangan gunakan pengaturan persentase atau mode pengujian sebagai jalan pintas yang diklaim untuk memenuhi syarat BIMI , dan jangan melemahkan penegakan yang ada saat melakukan debug pada masalah aset yang tidak terkait. RFC 9989 , Lampiran A.6.
Verifikasi sumber daya yang akan diiklankan oleh pernyataan tersebut
Pemilik hosting harus memberikan URL HTTPS publik yang tepat, byte yang diinginkan, dan hashnya. Pengambilan yang diusulkan harus mengonfirmasi bahwa responsnya adalah aset atau bundel sertifikat yang diharapkan, bukan halaman login, halaman kesalahan bermerek, atau pengalihan ke sumber daya yang tidak terkait. Catat status, URL final, tipe konten, ukuran dan hasil TLS . Pengamatan ini harus berasal dari jalur produksi sebenarnya, bukan hanya pratinjau file lokal.
Untuk jalur tanda-sertifikat, verifikasi bukti dan rantai yang dikeluarkan terhadap persyaratan penyedia target. Petunjuk Google menjelaskan paket PEM dan pesanan berantai yang disediakan penerbit. Sertifikat server HTTPS melindungi pengambilan; itu bukan VMC atau CMC yang memberikan bukti tanda. Periksa kedua hubungan secara mandiri. Penyiapan Google BIMI , persyaratan server web, dan langkah 2–3.
Tidak ada URL publik yang diambil atas nama penerapan nyata di sini. Jika tim tidak dapat memberikan aset atau sertifikat yang disetujui, biarkan ketergantungan tersebut tidak terselesaikan alih-alih membuat placeholder yang dapat disalahartikan sebagai bukti valid.
Publikasikan melalui otoritas DNS yang benar
Identifikasi layanan DNS otoritatif untuk pemilik sebenarnya dan periksa catatan yang ada sebelum melakukan perubahan. Konfirmasikan apakah editor mengharapkan label host relatif atau nama yang sepenuhnya memenuhi syarat. Pertahankan nilai dan TTL sebelumnya, dan gunakan permintaan perubahan yang telah ditinjau yang menyebutkan nama pemilik, jenis, dan nilai yang dituju. Hindari duplikat pernyataan yang bersaing pada nama penemuan yang sama.
Setelah publikasi resmi, pemeriksaan yang diusulkan meliputi gali @AUTH_IP default._bimi.example.com . TXT +tidak ada kutukan Dan gali @RESOLVER_IP default._bimi.example.com . TXT. Titik akhir huruf besar adalah placeholder. Simpan stempel waktu, selesaikan respons, catat batas, dan nilai sebenarnya. Perintah-perintah ini diusulkan, bukan pengamatan yang dilaksanakan.
Periksa konsistensi otoritatif sebelum menjelaskan ketidaksepakatan sebagai cache. Kemudian bandingkan jalur rekursif yang relevan dengan penerima yang dituju di mana observasi tersebut tersedia. TTL DNS atau perkiraan jendela tampilan penyedia bukan merupakan jaminan bahwa setiap penerima telah melakukan refresh atau akan menampilkan logo.
Validasi pesan dan rencanakan pemulihan
Kirim pesan terkontrol melalui alur kerja yang disetujui hanya setelah prasyaratnya siap. Simpan Domain Penulis, identitas penandatanganan, hasil autentikasi tepercaya, dan diagnostik BIMI apa pun yang relevan. Catat observasi tampilan secara terpisah dengan penyedia kotak surat, versi klien, dan tanggal. Jalur BIMI Apple Mail, misalnya, bergantung pada penyedia penerima yang menyediakan cek dan header yang ditentukan Apple. Panduan server Apple BIMI.
Jika pengambilan gagal, perbaiki ketergantungan yang dihosting atau pulihkan pernyataan sebelumnya yang disetujui berdasarkan rencana perubahan. Jika autentikasi gagal, selidiki pengirim dan kebijakannya. Jika hanya tampilan yang tidak ada, jangan menyimpulkan kesalahan DNS tanpa memeriksa baris penerima. Menyimpan bukti lama yang diperlukan untuk pengembalian yang aman dan resmi; jangan mengurangi perlindungan DMARC secara luas untuk memulihkan logo.
Gerbang bukti yang tepat adalah “Matriks kelayakan khusus penerima dan bukti untuk DNS , logo, sertifikat, dan autentikasi pesan.” Draf ini memberikan matriks dokumenter dan ilustrasi rekaman fiksi. Tidak ada publikasi langsung, permintaan DNS , validasi sertifikat, perubahan penyewa, atau pengujian pesan/tampilan, sehingga gerbang operasional dan persetujuan rilis pemilik tetap terbuka.