DNSを編集する前に依存関係を確認する
を公開する BIMI アサーションは、いくつかの外部依存関係を伴う小さなDNS変更です。レコードは、別のチームがホストするロゴや証拠文書を参照している可能性があり、受信側プロバイダーは、証明書または認証条件が満たされていないため、読み取り可能なファイルを拒否する可能性があります。一般的なTXT文字列ではなく、承認されたドメイン、受信者固有のプラン、正確な資産バージョンから始めます。
このガイドでは、文書化されたデフォルト セレクターのワークフローについて説明します。保存されているBIMIバージョン 15 の文書には、追加のセレクターと検出ルールが記載されていますが、RFC ではなくインターネット ドラフトのままです。高度なものを導入しない セレクタ 送信プラットフォームがヘッダーを挿入できるという理由だけで動作する。最初に意図した送信側と受信側の実装を確認してください。 BIMIインターネット ドラフト 15、セクション 4.3 ～ 4.4.
正しい所有者とアサーション値を確立する
単純なデフォルトのケースでは、 example.com、アサーションの所有者は default._bimi.example.com。バージョンタグは v=BIMI1;インジケーターの位置が使用する l=、および典拠証拠の場所には次のものが使用されます。 a=。草案では証拠の場所をオプションの構文として定義していますが、すべての受信者にとって証拠がオプションになるわけではありません。 BIMIインターネット ドラフト 15、セクション 4.3.
架空の二重場所のイラストは、 v=BIMI1; l=https://assets.example.com/brand/logo.svg; a=https://assets.example.com/brand/mark.pem。これは、運用記録、ホストされた資産、または証明書の推奨事項ではありません。実際のアサーションも実際の証明書 URL も、これらの例の値に置き換えません。
Google は、空の例を含むGmailの PEM ベースのセットアップを文書化しています。 l= 値と証明書の場所 a=。 SVG のみのレコードは同じ実装パスではありません。公開されているすべての例を互換性のあるものとして扱うのではなく、対象の受信者と提供された証拠によってサポートされる形式を選択してください。 Google BIMIセットアップ、ステップ 2 ～ 4.
該当する認証ポリシーを確認してください
現在の情報を使用して、作成者ドメインと該当する組織ドメイン ポリシーを確認します。 DMARC 発見ルール。次に、調整された認証のために、目的のルートからの実際のメッセージを検査します。 BIMIグループは施行を求め、自己主張レコードのサポートが限定的であることを指摘していますが、ポリシーテキストもレコードビルダーの結果も、送信者の準備が整っていることを証明するものではありません。 BIMI実装ガイド; RFC 9989 、セクション 4.4 および 4.10.
プロバイダーのドキュメントは、そのバージョンのコンテキストとともに読む必要があります。現在の Google ページにはまだ次の内容が含まれています pct=100、 一方 RFC 9989 そのタグを削除しました。この矛盾は、メール管理者に対する互換性に関する質問として保持してください。 BIMI資格への近道としてパーセンテージ設定やテスト モードを使用しないでください。また、無関係な資産の問題をデバッグする際に、既存の適用を弱めないでください。 RFC 9989 、付録 A.6.
アサーションがアドバタイズするリソースを確認する
ホスティング所有者は、正確なパブリック HTTPS URL、対象のバイトとそのハッシュを提供する必要があります。提案された取得では、応答がログイン ページ、ブランド化されたエラー ページ、または無関係なリソースへのリダイレクトではなく、予期されたアセットまたは証明書バンドルであることを確認する必要があります。ステータス、最終 URL、コンテンツ タイプ、サイズ、 TLS結果を記録します。これらの観察は、ローカル ファイルのプレビューだけでなく、実際の運用パスから得られる必要があります。
マーク証明書パスの場合は、発行された証拠とチェーンをターゲット プロバイダーの要件に照らして検証します。 Google の指示には、PEM バンドルと発行会社が提供するチェーン注文について説明されています。 HTTPS サーバー証明書は取得を保護します。それはそうではありません VMC または CMC それはマークの証拠を提供します。両方の関係を個別に確認します。 Google BIMIセットアップ、Web サーバーの要件、手順 2 ～ 3.
ここでは、実際の展開に代わって取得されたパブリック URL はありません。チームが承認されたアセットまたは証明書を提供できない場合は、有効な証拠と間違われる可能性のあるプレースホルダーを作成するのではなく、その依存関係を未解決のままにしておきます。
正しいDNS機関を通じて公開する
正確な所有者の権威DNSサービスを特定し、変更を加える前に既存のレコードを検査します。エディターが相対ホスト ラベルまたは完全修飾名を予期しているかどうかを確認します。以前の値と TTL を保持し、目的の所有者、タイプ、値を指定するレビュー済みの変更リクエストを使用します。同じ検出名で競合するアサーションが重複しないようにします。
承認された出版後に提案されたチェックには次のものが含まれます。 @AUTH_IP のdefault._bimi.example.comを掘ります。 TXT +norecurse そして @RESOLVER_IP のdefault._bimi.example.comを掘ります。 TXT。大文字のエンドポイントはプレースホルダーです。タイムスタンプ、完全な応答、レコード境界および実際の値を保存します。これらのコマンドは提案されたものであり、実行された観察ではありません。
不一致をキャッシュとして説明する前に、権威ある一貫性を確認してください。次に、それらの観測結果が得られる、対象の受信機に関連する再帰パスを比較します。 DNS TTL またはプロバイダーの推定表示ウィンドウは、すべての受信者が更新されたこと、またはロゴが表示されることを保証するものではありません。
メッセージを検証し、回復を計画する
前提条件が準備できた後でのみ、正確に承認されたワークフローを通じて制御されたメッセージを送信します。作成者ドメイン、署名 ID、信頼できる認証結果、および関連するBIMI診断を保持します。メールボックス プロバイダー、クライアントのバージョン、日付を個別に表示観察を記録します。たとえば、Apple Mail のBIMIパスは、Apple が指定するチェックとヘッダーを提供する受信プロバイダーに依存します。 Apple BIMIサーバーのガイダンス.
取得に失敗した場合は、ホストされた依存関係を修復するか、変更計画に基づいて承認された以前のアサーションを復元します。認証が失敗した場合は、送信者とポリシーを調査してください。表示のみがない場合は、受信者の行を確認せずにDNSエラーを推測しないでください。安全で承認されたロールバックに必要な古い証拠を維持します。ロゴを回復するためにDMARC保護を大幅に低下させないでください。
正確な証拠ゲートは、「受信者固有の資格マトリックスと、 DNS 、ロゴ、証明書、およびメッセージ認証の証拠」です。この草案は、ドキュメンタリーのマトリックスと架空の記録の図解を提供します。ライブ パブリケーション、 DNSクエリ、証明書の検証、テナントの変更、またはメッセージ/表示テストは行われないため、運用ゲートと所有者リリースの承認は開いたままになります。