1 つのメッセージと 1 つの意図されたアサーションから始める
ドメインには複数のドメインを含めることができます BIMI すべてのメッセージを使用せずにアサーションをすべて使用します。意図したデザインでは異なるものを使用します セレクタ さまざまなアサーションを識別するための名前。競合とは別の状況です。1 つの所有者名で候補レコードが重複している場合、セレクター ヘッダーが競合している場合、または送信プラットフォームがオペレーターが予期しているもの以外のセレクターを選択している場合です。別の正当なメール ストリームをサポートしている可能性のあるレコードを削除する前に、これらのケースを個別に診断してください。
この記事では、 BIMIグループのセレクター ガイダンスと、保持されているDNSおよび認証の仕様を使用します。すべての受信者がすべてのドラフト動作を実装するとは主張しません。ライブDNSクエリやメッセージ検証は実行されませんでした。必要な証拠チェーンは実際のメッセージから始まり、そのセレクターとパブリックDNS応答を経て、信頼できる検証結果で終わります。 DNS エディターのスクリーンショットだけではそのチェーンを提供できません。
セレクターと重複レコードを区別する
BIMIグループのガイダンスでは、フォーム セレクターのアサーション名について説明しています。 _bimi.domain 。代替手段が選択されていない場合は、デフォルトが従来のセレクターになります。これは、 BIMIバージョンとセレクター名を保持する BIMI-Selector ヘッダーを記述し、アサーションを選択するために表示される From ドメインと組み合わせます。異なるセレクターでの個別のアサーションは、複数のロゴのメカニズムです。複数の競合するアサーションを同じ名前で追加することは、同じ設計ではありません。 BIMIセレクターのガイダンス
インベントリの場合は、各所有者名、対象とするストリーム、資産、および責任チームをリストします。 default._bimi.example.comと、 seasonal._bimi.example.comおよび送信サブドメイン内の同様の名前のレコードを区別します。これらの例の名前は説明用であり、クエリされたレコードではありません。メッセージの選択された名前が関連する開始点となるため、それらの意味を 1 つの「ドメインにBIMIがある」という結果にまとめないでください。
TXTデータをエディター行ではなくDNSレコードとして読み取ります
DNS TXTリソース レコードには 1 つ以上の文字列を含めることができます。このワイヤ レベルの構造は、表示内の複数の引用部分が必ずしも複数のレコードではないことを意味します。逆に、プロバイダー インターフェイスでは、2 つの別々のレコードが 1 つのグループ化されたエントリのように見えることがあります。ドメインに重複したアサーションがあると判断する前に、実際に返されたレコード境界を検査してください。 RFC 1035 TXTフォーマット
安全な修復提案は、選択された所有者名での意図された明確なBIMIアサーションであり、別個のセレクターに代替ロゴが割り当てられています。この記事は、重複した主張の中から普遍的な受信者の選択を主張したり、入手できない草案テキストから規範的な重複レコードのアルゴリズムを提供したりするものではありません。競合する候補を構成保持として扱い、観察された選択順序に依存する前に、ターゲット受信者の文書化された動作を検証します。
送信パイプラインを通じてセレクターをトレースします。
ヘッダーを保存した、受信メッセージの承認されたコピーを取得します。表示されている From ドメインとすべての BIMI-Selector の出現を記録します。受信状態を、送信プラットフォームの構成およびヘッダーを追加または変更できる仲介者と比較します。アウトバウンド サービスが別のデフォルト設定を挿入している間に、アプリケーションが季節セレクターを要求する場合があります。実際のメッセージがなければ、 DNSチームは受信者が使用を要求されていない名前を調査する可能性があります。
BIMIグループは、DMARC 連携に BIMI-Selector を含めることを推奨します。 DKIM署名 そして、署名されていないセレクター ヘッダーは無視される可能性があることを警告します。関連する署名の署名付きヘッダー リストと検証証拠を保存します。合格した署名がこの特定のヘッダーを自動的にカバーするとは考えないでください。署名は、セレクターの設定を保護の外に置いたまま、メッセージの他の部分を認証できます。 BIMI署名ガイダンス
複数のセレクター ヘッダーが表示される場合は、受信者がどれを受け入れるかを推測するのではなく、それらが追加された場所を特定し、送信構成を解決します。修正を提案する前に、元のメッセージを保存してください。受信したヘッダーを編集して、その編集したメッセージを元の検証結果の証拠として提示しないでください。その後の管理されたテストは、独自の ID とタイムスタンプを持つ、新鮮で承認された観察でなければなりません。
信頼できる検証境界を確立する
Authentication-Results どの信頼できるシステムがそれを生成したかを消費者が知っている場合にのみ役立ちます。任意のヘッダーに信頼できないアサーションを含めることができます。 RFC 8601では、この信頼境界について説明しています。来歴なしで貼り付けられた結果を受け入れるのではなく、受信者発信元の証拠または明示的に信頼できる別の検証者を使用します。 BIMI決定を維持し、 DMARC 結果と DKIM 調査で区別できる範囲。 RFC 8601信頼境界
DNS観察時間とリゾルバー コンテキストをメッセージ時間とともに記録します。その後のDNSルックアップでは、メッセージが評価されたときには表示されなかった修復された状態が表示される場合があります。逆に、現在の失敗は、古いメッセージが同じ応答を見たということを証明するものではありません。収集された証拠を時間制限のあるチェーンとして扱い、今日のエディターの内容から過去のDNS状態をでっち上げることを避けます。
オリジナルのセレクター競合ワークシート
影響を受けるストリームごとにこのワークシートを使用します。フィールドは、完了したチェックではなく、提案された証拠リクエストです。機密メッセージの内容は、必要かつ許可されている場合にのみ保存してください。ヘッダーに焦点を当てた編集では、多くの場合、関連する関係を保持できます。
- メッセージ ID: 受信時刻、表示される From ドメイン、および承認された証拠の場所。
- セレクターの状態: 存在せず、単一または複数のヘッダーが出現し、正確な値が保持されます。
- 署名範囲: 調整されたDKIM ID、署名付きヘッダー リスト、および信頼できる検証結果。
- DNSターゲット: 選択された所有者名、パブリック応答、レコード境界、および観察時間。
- アサーションの所有権: 対象のストリーム、アセット、証明書の依存関係、およびDNS所有者変更。
- 競合: 重複したアサーション、不一致のセレクター、署名されていない設定、または未解決の受信側の動作。
- 提案された修正: 影響を受ける正確なレコードまたは送信構成、承認およびロールバック計画。
- クロージャ: 新しい制御されたメッセージ、対応するDNS観察、および信頼できる受信者の結果。
ワークシートでは事実と仮説を区別する必要があります。 「この名前で 2 つのレコードが返された」ということは、実際の回答が保持されている場合にのみ事実となります。 「仲介者が別のヘッダーを追加した可能性がある」は、メッセージ パスがサポートするまでの仮説です。この区別を可視化しておくことは、もっともらしいがテストされていない説明に基づいた広範なDNS変更を回避するのに役立ちます。
架空の例: 2 つのチームがデフォルト名を共有する
架空の Amber Ferry には企業メール チームとキャンペーン代理店があります。どちらも、デフォルトの所有者名でBIMIアサーションを公開することを提案していますが、代理店のプラットフォームは季節セレクターを要求するように構成されています。発明された計画レビューにより、デフォルトの意図が競合していることと、意図した主張を持たない可能性のある選択された名前という 2 つの独立した問題が明らかになります。デフォルト レコードを 1 つ削除するだけでは、季節メールが正しいパスをたどることは確立されません。
提案された解決策は、所有権に同意し、選択された名前ごとに 1 つの意図されたアサーションを保持し、新しい認可されたテストで機関のセレクター ヘッダーと署名のカバレッジを検証することです。レコードがリタイアされる前に、既存のストリームをチェックする必要があります。 Amber Ferry DNSレコードやメッセージは検査されず、修正やテストも実行されませんでした。この例では、修復が成功したと主張するのではなく、競合を分離する方法を示しています。
観察されたチェーンのみを閉じます
1 つのセレクターの観察が成功しても、他のすべてのセレクター、サブドメイン、または送信プラットフォームが検証されるわけではありません。どのストリームとレシーバーがチェックされたかを正確に記録し、不明な部分は保存します。 BIMI Group はまた、証明書の証拠はロゴに関連付けられているため、別のアートワークを指す 2 番目のセレクターによって、単なるDNS命名タスクではなく、別の証拠とドキュメントの依存関係が導入される可能性があると指摘しています。 複数のロゴのガイダンス
カタログには、パブリックDNSと信頼できる検証を備えたメッセージからセレクターへの証拠チェーンが必要です。この原稿では実際の展開に対応するものはありません。オリジナルの証拠、人間の SME、ソースの適用性、生産ルート、視覚的なアクセシビリティ、および所有者の公開は未解決のままです。このドラフトは診断ワークフローであり、重複処理や受信者の選択がテストされたことを証明するものではありません。