BIMIの整理しておきたいポイント (2022年10月時点)

2022-09-102024-08-14

当サイトには広告を含みます。

当サイトでは、広告掲載ポリシーに沿って広告を掲載しています。
※広告でなく、単に商品やサービスを自主的に紹介しているだけという場合もあります。

"オススメ" として紹介している商品やサービスは、個人的にそう思えたものだけです。

共感、興味をもっていただけるものがあればご利用ください。

[日替わり] Amazonタイムセール

1,000P獲得できるお得なAmazonプライム入会

電子メールの送信元ドメインが詐称されていないかを検証する送信ドメイン認証 (Sender Domain Authentication)。

本記事は、送信ドメイン認証の関連技術であるBIMI(Brand Indicators for Message Identification)についてまとめたものです。

SPF、DKIM、DMARC、ARC、BIMIといった送信ドメイン認証のまとめ記事はこちらです。

本記事では、BIMIが扱う画像(Brand Indicators)のことを簡単に”ロゴ”と記載しています。

本記事では、整理しておきたいポイントを中心に記載しています。ネット上に解説記事が多そうな内容については省略している場合があります。

また、本記事は、BIMI認証についてまとめてありますが、以下については含んでいません。適宜IETFの文書等を参照願います。
– BIMI Reportingの詳細
– ロゴ画像(SVG)の詳細
– 認証マーク証明書(VMC)の詳細

基本

BIMIは、既存のDMARCポリシーを活用し、電子メールの認証を普及を促進することを目的とした技術です。

BIMIの動作例

例として、楽天グループから届いたメールをWebブラウザ版のGmailで表示した際に、BIMIのロゴが表示されている画像を掲載します(楽天推しという訳ではありません)。

送信元ドメインがBIMI対応していない場合、イニシャル(“RG”)等が表示されますが、BIMI対応している場合には、その送信元ドメインに応じたロゴが表示されます。この仕組みがBIMIです。
メールを読む人に対し、そのメールが詐称されていないことの安心感や、ロゴのビジュアル自体によるブランドイメージのアピールができます。

ロゴ表示するためには、メールの送信元と、メールを受信するシステムやメールクライアント(WebMailやメーラ)の両方でBIMI対応している必要性があります。

楽天グループの詐称メール対策に関する説明ページに、「Gmail」におけるブランドシンボル(ロゴ画像)の表示にはBIMIが使用されている旨の説明があります。大手EC企業ですので、このような詐称メール対策に関する情報発信は大事かと思います。

クレジットカード会社の三井住友カードの場合の例は、以下の記事にまとめてあります。

BIMIの認証対象と認証成否

メールのヘッダFromドメインの管理元により指定されたロゴ(画像)を認証します。
BIMI自体は、送信者ドメイン認証の関連技術です。SPF、DKIM、DMARC、ARCといった既存の送信者ドメイン認証技術に依存し、BIMI自体の認証方法が定められていますが、それ自体が新たな送信ドメイン認証のプロトコルという訳ではありません。
ヘッダFromドメインのDNSに登録されたBIMIレコードに基づいてロゴを検証する等、BIMI認証に必要な一連の処理を行い、正しいものであると判断できれば認証成功です。
DNSレコードを保有するドメインの管理元により、「そのロゴをメールに表示することを認められている」という点が担保されます。

認証時の動作

メールを受信する側が、上記の認証を行います。
BIMI認証の際には多くの検証処理が行われます。詳細は後述します。

BIMI対応に必要な設定(メールを送信するドメイン側)

メール送信元ドメインとしてBIMI対応に必要な設定等は、基本的にロゴ画像の準備とDNSレコードの登録なのですが、そのために多くの準備が必要です。商標登録済みのロゴ画像や、ロゴ画像を配置するWebサーバ、さらにロゴ画像が正当なものであることを証明するためのVMC(証明書)の購入等です。
また、BIMI対応の前提として、DMARCを正式運用できている必要性があります。
DMARC対応が前提になるということは、SPFもしくはDKIM、あるいはその両方に対応している必要性があります。環境によってはARC対応も考えられます。
詳細は後述します。

BIMI対応に必要な設定(メールを受信する側)

メールを受信する側としてBIMI対応に必要な設定等は、MTAとMUAの環境設定です。
分かりやすい例だと、GmailのWebMailやアプリは、既にBIMI対応済みです。
詳細は後述します。

認証結果

BIMIの認証結果は、以下のいずれかです(IETF文書より)。
- pass
- none
- fail
- temperror
- declined
- skipped
この認証結果は、以下に記載されます。
- Authentication-Resultsヘッダ内のbimiの値
- 以下のようにコメントを追記しても良いです。
  - bimi=fail (Invalid SVG)
  - bimi=skipped (sender not trusted)
  - bimi=skipped (message failed DMARC)

詳細

RFC

BIMIのRFCは発行されていません。

BIMIの仕様策定や普及の状況

参考情報として、BIMIの仕様策定や普及の状況について記載します。

BIMIの仕様を定めたRFCはまだ存在せず、2022年11月現在、IETFにおいて”Internet-Draft”の扱いです。
- BIMI GroupのWebサイトに、一連の文書へのリンクがあります。
- これらの”Internet-Draft”は2023年4月12日に期限切れになります。次の文書が公開されると思われます。
普及状況としては、以下のページが参考になります。
- Where Is My BIMI Logo Displayed?
  - 受信したメールに対するBIMIのロゴ表示に関するページです。
  - BIMIは、一般的なメーラよりもMBPが提供する専用アプリあるいはWebMailの方が実装が早いようです。
    例えばGmailなど、MTAとMUA(WebMail)が同じMBPの管理下にある場合には、MTAのBIMI認証結果をMUAが信頼できるよう構成しやすいため、その結果BIMI対応をスムーズに進められるようになると推察されます。
- BIMI GroupのWebサイト(bimigroup.org)
  BIMIのサポート状況が記載されています。基本的にMBPやMUAの製品やサービスの提供元のサポート状況は、受信したメールのBIMI認証の対応状況を指しているはずです。
  以下、2022年11月時点の状況を控えておきます。
  - 2022年秋に、macOS Ventura 13、iOS 16、iPadOS 16にてBIMI対応済みです。”Appleメール”は標準のメールアプリのことだと思います。
    ただし、BIMIのロゴ表示ができるのは、一部のドメインからのメールのみのようです。
  - QUALITIA(Webメールソフトウェア”Active!Mail”提供元の日本企業)、Yahoo!JapanもBIMI対応を検討中です(Considering BIMI)。
    - Yahoo!JapanのBIMI対応に関する記事(2022-09-06)がありました。
      BIMI対応を検討中ではあるものの、当面はBIMIでなく独自のブランドアイコン機能を使用するようです。
  - Microsoft(OutlookやMS365/Exchange Online)は”Does not support BIMI”と記載されています。
    注記に、”may have other logo services available”とあるのはMicrosoft独自のverified iconのことでしょうか。詳細は不明です。
- 一方で、メールを送信する側のBIMI対応は、送信元のドメインおよびメールシステムの管理元が推進するものです。詐称メール対策やブランディングに積極的な組織では、対応が早いと思われます。
その他のメール関連システムにおけるBIMI機能の実装は、SPF、DKIM、DMARC、ARCほどは進んでいないようです。今後、BIMI対応するシステムは増えると思われます。
オンプレミスのWebメールソフトウェアでは、BIMIのロゴ画像表示に対応したものは見当たりませんでした(2022年8月時点)。
- Axigen
  Axigenのロードマップに”BIMI support”の記載あり。
- Roundcube
  GitHub上のディスカッションに挙がってはいるが、具体的な予定は見当たらず。

導入ステップや運用ポリシーに応じた調整のポイント

BIMIは、メールを送信するドメイン側、メールを受信する側の両方で対応が必要です。

メールを送信するドメイン側

BIMI自体には、SPFにおける修飾子やDMARCにおけるポリシー(p=)のような、検証基準を調整するパラメタはありません。
ただし、送信する全てのメールをBIMI対応させる本番運用開始の前に、テスト用に個別のセレクタを用意し、テスト用に送信するメールにのみ、そのセレクタ名を指定することで、試験的な段階を設けることはできそうです。
なお、BIMI対応の前提として、DMARCを正式運用できている必要性があります(DMARC Enforcement)。
BIMI対応を進める上で、このDMARCポリシーに対する要件は、メールシステムの技術面、運用面で課題になりやすいでしょう。
その他、商標登録済みのロゴ画像や、ロゴ画像を配置するWebサーバ、さらにロゴ画像が正当なものであることを証明するためのVMC(認証マーク証明書)の購入等、直接的なシステム設定以外の手順が多い点には注意が必要です。
各ドメインの管理元がBIMI対応するきっかけとして、以下のようなものが考えられます。
- ロゴ表示による自組織のブランド価値向上
  2022年11月時点で、Gmailの受信トレイを開いてみると、大手のECやSNS関連企業から届いたメールにはロゴ表示されているものが多いです。それらは既にBIMI対応済みということです。
  将来的にBIMIの普及が進めば、BIMI対応していないことにより、その組織のブランド価値が低く見られてしまう場面は少なからず生じそうです。
  BIMIのInternet-Draft文書にも、ロゴを表示できることが、送信ドメイン認証を普及させるための動機付け(インセンティブ)になる旨が記載されています(As an additional benefit, mail-originating organizations are incentivized to authenticate their email as doing so will enable them to influence how email and Indicators from the organization are displayed.)。
- 送信ドメイン認証に対する投資成果の可視化
  既に多くのコストや時間をかけてSPF、DKIM、DMARC、ARC等の送信ドメイン認証に対応してきたとしても、それらのセキュリティにおける価値を分かりやすく可視化、表現するのは難しいものです。
  BIMIは、馴染みのあるロゴの表示という誰にでも分かりやすいアプローチで、それらのセキュリティ価値をアピールできます。
- ユーザエクスペリエンスの変化
  これは私の主観ですが、BIMIのロゴ表示によりメール読者に対してポジティブな印象を与えられるようになると考えられます。
  従来型のスパム対策は透過的に動作するものが多く、メール読者に対して基本的に何もアピールしません。強いて言うなら、メールがスパム対策を通過して読者の受信トレイに届いたということが「これは不正なメールではありません」という検査結果のようなものの代わりになります。
  対して、BIMIのロゴ表示は「これは本物のブランドロゴ付きのメールです」というポジティブなアピールを含みます。これは読者に対してそのままポジティブな印象として伝わるでしょう。
  ユーザは無意識にその体験を蓄積していくので、メールを信頼するかどうかの判断をする際の基準(嗜好)が徐々に変化し、このBIMIのようにキャッチーな技術が”当たり前”なものになっていくと思います。
なお、あるメールのBIMI認証が何らかの理由で失敗した際、その失敗が理由でメール配送を拒否するようなポリシー運用の受信者はいないはずです。影響は、メールを開いたユーザに対してロゴが表示されないだけでしょう。
メール自体が届かない、読めないといったトラブルの心配まではせずにBIMI対応を進められます。

メールを受信する側

使用しているメールシステムの環境により、BIMI対応のためのステップは異なります。
- Gmail等のクラウドサービスを利用している場合には、メールを受信する側としてのBIMI対応はできています。GmailのWebMailや専用アプリを使用すれば、BIMIによりロゴ画像を表示できます。追加の設定等は不要です。
  逆に、GmailのMUA(WebMailや専用アプリ)において、BIMIを無効化(ロゴ画像を表示しないように)する設定は見当たりません。
- 自組織でメールシステムを運用している場合は、そのメールシステムをBIMI対応させる必要性があります。
  - MTAは、受信したメールに応じBIMIレコードを検索し、ロゴ画像を取得、検証できるよう設定します。さらに、その検証結果に基いてMUAに伝達すべきBIMI関連情報をメールヘッダに反映するための設定も必要です。
  - MUAは、受信したメールの内容に応じ、ロゴ画像をユーザインタフェースに表示できる実装が必要です。また表示するかどうかを決定するための判断処理の実装も必要です。
  - なお、2022年8月現在、一般に配布や販売されているオンプレミス向けメールシステムでは、BIMIを実装できそうな仕組みは見つかりません。
注意すべき点は、MUAにとって、MTAによるBIMI認証結果が信用できるシステム構成であるべきということです。
- 送信ドメイン認証を外部サービスに委託している構成の場合、BIMI認証を含む送信ドメイン認証の基準が信頼できるものかの確認が重要です。また自組織のセキュリティ運用に従い、その基準を調整できる権限があることも重要です。
- 言い換えると、MUAとMTAが同じ信頼境界の中に存在しているべきという観点です。

実企業でのステップを確認してみた例

公開されている情報の範囲内で確認した結果ですが、以下の記事で、DMARCのポリシーを p=NONE → p=REJECT と段階的に切り替えた後、しらばく経ってからBIMI対応が完了した、という流れを読み取ってみました。

(小ネタ)あるドメインからのメールがBIMI対応済みかどうかの確認方法

小ネタです。BIMIの動作を理解する上での参考情報として記載します。
例えば、受信したメールのBIMI対応有無や、メールは受信していなくても任意のドメインに対するBIMI対応有無を確認する方法です。

Gmail等のBIMI対応のMUA環境でメールを表示する

そのメールにロゴ画像が表示されれば、当然そのメールの送信元ドメイン(ヘッダFromドメイン)はBIMI対応済みです。またそのメールもBIMI対応したものであると言えます。

DNSレコードを確認する

Instagramからのメールにロゴが表示されていましたので、試しにそのロゴ表示に使用されたBIMIレコードを検索してみます。

検索方法は、以下のTXTレコードを検索するというものです。
(セレクタ名)._bimi.(ヘッダFromドメイン名)
セレクタ名は、BIMI-Selectorヘッダで指定されている値です。BIMI-Selectorヘッダが無い場合、’default’がデフォルトのセレクタ名です。

ヘッダFromドメインでBIMIレコードが得られない場合、次に組織ドメインで検索することになっています。ヘッダFromドメインがaaa.bbb.domain.comであれば、domain.comが組織ドメインです。以下は、InstagramからのメールのBIMI-Selectorヘッダで指定されたセレクタ名(fb2021q2v1)のBIMIレコードをWindows上で検索する際のコマンド例です。
> nslookup -type=TXT fb2021q2v1._bimi.mail.instagram.com
検索の結果、得られたBIMIレコードは以下です。
"v=BIMI1; l=https://instagram.com/images/bimi/ig-logo.svg; a=https://instagram.com/bimi-vmc.pem;"参考までに、セレクタ名defaultのBIMIレコードは存在しませんでした。
>nslookup -q=TXT default._bimi.mail.instagram.com
*** UnKnown が default._bimi.mail.instagram.com を見つけられません: Non-existent domain次に、取得したBIMIレコードのlタグとaタグの内容を確認してみます。

受信したメールのヘッダを確認する

MUAで開いたメールのヘッダから、送信元ドメインのBIMI対応状況を正確に判断することはできませんが、手がかりになる情報を含む場合があります。
これらの情報を確認する際の前提として、該当メールヘッダが改ざんされたものでないこと、BIMIの規約に準拠し動作するメールシステムを経由して配送されたメールであること、が挙げられます。
以下は各ヘッダの簡単な確認方法です。各ヘッダのもう少し詳細な説明を含む項目は後述します。

BIMI-Selectorヘッダ
メールヘッダ中にBIMI-Selectorヘッダが存在する場合、メール送信者が意図的にロゴ表示のためBIMIレコード検索用のセレクタ名を指定した上でメールを送信したと考えらます。
省略した場合はセレクタ名defaultが使用されます。
BIMI-Locationヘッダ、BIMI-Indicatorヘッダ
メールヘッダにBIMI-LocationヘッダやBIMI-Indicatorヘッダが存在する場合、メールを受信したMTAが、MUAにロゴを表示させるためにこれらのヘッダを追加したと考えられます。
これらのヘッダは、MTAでBIMIの検証が行われた結果、認証成功した場合に追加されることがあるものです。
Authentication-Resultsヘッダ
MTAによるBIMIの認証結果(bimi=)が記載されている場合があります。
なお、ARCはDMARC認証の必須要素ではありませんが、ARC-Authentication-ResultsヘッダにBIMIの認証結果(bimi=)が記載される場合もあります。
DKIM-Signatureヘッダ
DKIM署名の範囲(h=)にBIMI-Selectorを含めることにより、BIMI-Selectorヘッダの改ざんを検知できるようになります。よって、DKIM署名者(基本的にはメール送信者)の署名時点におけるBIMI-Selectorヘッダの内容が改ざんされていないことを確認できます。
なお、ARCはDMARC認証の必須要素ではありませんが、ARC-Message-Signatureヘッダ内のDKIMと同等の署名範囲にBIMI-Selectorが含まれる場合もあります。
例として、InstagramからのメールをGmailで受信した際のBIMI関連ヘッダを記載します。このメールはBIMIのロゴが表示されています。
- BIMI-Selectorヘッダ
  BIMI-Selector: v=BIMI1; s=fb2021q2v1;
- Authentication-Resultsヘッダ
  dkim=pass …
  spf=pass …
  dmarc=pass …
  Gmail側で受信した際の認証結果が記載されていますが、bimi=passの記載はありませんでした(ARヘッダへのBIMI認証結果の記載はMUSTでなくSHOULDなので必須ではありません)。
  BIMI認証成功の前提となるDMARCの認証結果は”pass”です。
- DKIM-Signatureヘッダ
  DKIM-Signature: … d=mail.instagram.com … h=Date:To:Subject:From:MIME-Version:Content-Type;
  Instagramドメインによる署名ですが、署名範囲にBIMI-Selectorヘッダが含まれていません。含まれていた方が良いと思います。
- ARC-Message-Signature
  ARC-Message-Signature: i=1; … d=google.com; …h=…:bimi-selector:…;
  Gmail側のメールシステムによりメール受信した際に追加されたARC署名です。
  署名範囲にBIMI-Selectorヘッダが含まれています。ただ、Instagramドメイン側のDKIM署名(あるいはARC署名)の範囲にBIMI-Selectorヘッダが含まれていないので、Gmail側に届く前までの改ざんを検知する効果はありません。
  また、Gmail側の動作として、他のメールも確認したところ、BIMI-Selectorヘッダが存在しないメールの場合、ARC署名範囲にBIMI-Selectorヘッダを含めないようでした(そのヘッダが無かったことも分かるようにするという意味では、含めた方が良いと思います)。

lタグで示されたURIからは、SVG形式のロゴ画像を取得できます。
l=https://instagram.com/images/bimi/ig-logo.svg
メールに表示されたロゴと同じ画像です。
aタグで示されたURIからは、VMC(認証マーク証明書)を取得できます。
a=https://instagram.com/bimi-vmc.pem
取得したVMCの拡張子を.crt等に変更してWindows上で開いてみると、証明書の内容を確認できます。

VMCの中身

拡張キー使用法が”不明なキー使用法 (1.3.6.1.5.5.7.3.31)”と表示されますが、このOIDはBIMI用(id-kp-BrandIndicatorforMessageIdentification)のようです。WebサイトのHTTPS対応に使用されるサーバ証明書では”サーバー認証 (1.3.6.1.5.5.7.3.1)”となっている箇所ですので、異なる用途の証明書であることが分かります。

BIMI全般

ここでは、BIMI全般について記載します。
主に、Brand Indicators for Message Identification (BIMI) draft-brand-indicators-for-message-identification-02に関する内容です。
後で文書が改版された際にチェックしやすいよう、カッコ()の中はこの文書の見出しを示しています。

概要(1. Introduction)
- BIMIは、既存のDMARCポリシーを活用し、電子メールの認証の普及を促進することを目的としています。DMARCは、SPF、DKIM、ARCをサポートしています。

メールを送信するドメイン側のBIMI対応

(2. Overview)

BIMI対応のために、メールの送信元ドメインにおいて必要な項目を記載します。

送信元ドメインの管理元

送信元ドメインの管理元においては、以下の対応が必要です。

DMARC正式運用(DMARC Enforcement)
DMARC対応において、以下の全てを満たす必要性あります。
- p=none以外(reject or quarantine)のDMARCポリシー(MUST)
  - p=quarantine、かつ、pctタグがある場合は、pct=100
  - p=rejectの場合、pctの値は任意
- サブドメインポリシー(spタグ)がある場合、sp=none以外(reject or quarantine)のDMARCポリシー(MUST NOT be “none”)
- 組織ドメインおよびその全てのサブドメインに対してDMARCポリシーを公開
- SPFやDKIMで使用される識別子(認証対象となるドメイン)の一致(alignment)
BIMIレコードを通じロゴの公開
- BIMIレコードの内容については後述します。
- (以下は、6. Domain Owner Actionsより)
  - BIMIレコード公開に際し、ロゴ画像を決定します。(6.1. Determine and Publish Indicator(s) for Use)
  - BIMIレコードを公開します。(6.2. Publish Assertion Records)
  - 複数のドメイン(同じ信頼境界内)に同じロゴを使用し、かつ、そのロゴを１つのDNSドメインで管理したい場合、CNAMEの使用が推奨されます(RECOMMENDED)。SPFのredirect修飾子と似た用法です。
    BIMIでは、lタグが送信元ドメインと一致していなくても良いので、CNAMEが良い方法です。(6.3. Manage multiple uses of the same Indicator(s) within a trust boundary)
  - (6.4. Set the headers on outgoing email as appropriateについては後述)
エビデンス(VMC)の準備も必要です。
- エビデンスにより、そのロゴ画像の管理元を確認できます。VMCはそのエビデンスの一種です。
- エビデンスの有無に関する参考記事
- 本記事では省略していますが、IETF文書に詳細が記載されています。

メールの送信者

メールの送信者(作成者)においては、以下の対応が必要です。

メールが適切に認証され、DMARCポリシーを満たすこと
なお、” has a sufficiently strict DMARC [RFC7489] policy”とありますが、これはDMARCのアラインメントモードがstrictであることを要求している訳ではないように思われます。

メールを受信する側のBIMI対応(後述)

内容が多く、また別文書の内容とまとめるため後述します。

用語と定義

(3. Terminology and Definitions)

BIMI Assertion
- Protocol Clientが、BIMIレコードを取得し、またロゴ画像を取得するためのURIを構成する仕組み
Indicator
- ロゴ画像
Mark Verifying Authority (MVA)
- エビデンスを提供することができる主体
- 例えばVMCを発行するCA
- MVAはロゴを審査する(サイズ、商標等)
BIMI Evidence Document
- MVAにより発行されたドキュメント
- 例えばVMC
- 単に”Evidence”と呼ぶことも
Verified Mark Certificate
- ロゴ用の証明書(VMCガイドラインに沿ったCAにより発行)
- VMCはBIMI Evidence Documentの一種
Protocol Client
- ロゴを取得するためにレコードを取得、解釈する主体
- 基本的にメールを受信する側のMTA
Verifying Protocol Client
- Protocol Clientのうち、エビデンスを検証する機能をもつもの

以下、追加で整理しておきたい用語を追加で記載します。

MBP(Mail Box Providers)
- 基本的にはメールストアの役割を含むメールシステムを指すことが多そう
- 文脈によるが、メールを受信する側のMTAとMUAの役割を含むメールシステム全体を提供するサービスプロバイダのことを、MBPと表現することも
reciever
- 自ドメイン以外からのメールを受け取るMTAやメールシステム全体を指すことが多そう
- メールの宛先やメール読者はrecieverでなく”recipient”
- 本記事ではとりあえず”受信者”や”受信する側”、あるいは”MTA”と記載

DNS上のBIMIレコード

(4. BIMI DNS Records)

BIMI対応のために、メールの送信元ドメインが公開する必要性のあるDNSレコードについて記載します。

このDNSレコードは、BIMI Assertion Recordsと呼ばれます。本記事ではBIMIレコードと記載します。
ドメインの管理元は、BIMIレコードの公開により、MUAに表示させたいロゴの認証や取得に必要な設定情報(policy)を提示します。この設定情報は、Protocol Client(主にメールを受信する側のMTA)により解釈、適用されます。
BIMIの設定情報は以下の意図により、DNS経由でのみ発行されます。メールヘッダは使用されません。
- MTAの振る舞いをシンプルにできる
  - MTAは特定のDNSレコードを確認するだけ
- 不正なヘッダを攻撃に使われないようにできる
  - そのためにはロゴは事前に取得＆キャッシュすべき(SHOULD)

BIMIレコードの形式と各タグ

(4.2. Assertion Record Definition)

BIMIレコードは、以下の問合せにより取得可能なTXTレコードです。
(セレクタ名)._bimi.(ヘッダFromドメイン)

TXTレコードの内容は、以下です。
"v=BIMI1[; l=(ロゴのURI)][; a=(VMCのURI)]

例えば、”example.com”ドメインの所有者が、”default._bimi.example.com”というBIMIレコードを公開したとします。BIMI対応済みのメール受信者は、ヘッダFromが”example.com”ドメインのメールを受け取ると、BIMI認証のため”default._bimi.example.com”のTXTレコードを検索します。そのレコードの情報を用いて一連の認証処理を行った後、MUAでロゴを表示できるようになります。

DKIM(RFC 6376)で定義されたタグ構文を使用可能です。
メール受信者は、BIMIレコードの構文や大文字小文字のエラーを修正してはいけません(MUST NOT)。BIMIレコードは正確に定義されるものであるためです。
BIMIレコードで使用可能なタグは以下の通りです。
- vタグ(必須)
  - バージョン情報です。
  - 本記事作成時点で選択可能な値は”BIMI1″のみです。
- lタグ(必須)
  - ロゴのファイルを取得するためのURIです。
  - 空の値は、ロゴの公開拒否を示します。
  - URIは、HTTPS必須です。
- aタグ(任意)
  - BIMIエビデンスドキュメント(VMC)を取得するためのURIです。
  - 指定する場合は、空の値、もしくは単一のURIを指定します(MUST)。
  - 空の値は、ドメインの管理元がエビデンスを開示したくない、もしくはエビデンスが無いことを示します。
  - aタグが無い場合、空の場合と同じであるとみなされます。
  - URIは、HTTPS必須です。
  - aタグは任意ですが、適切なBIMI運用のためにはエビデンス公開は必須と思われます。エビデンスが無い場合、メール受信者自身が信頼する送信元ドメインを個別に定義するようなポリシーの場合にのみロゴ表示されることになります。
vタグ以外の順序は任意です。
BIMI対応しないこと(辞退)を明示的に示す場合、以下のBIMIレコードを公開します。(4.2.1. Declination to Publish)
v=BIMI1; l=; a=;
- lタグ、aタグの両方が空なので、そのレコードが公開されたドメインおよびセレクタはBIMI対応しないことを示しています。
- 例えば、組織ドメインがBIMI対応しているものの、そのサブドメインの方はBIMI対応しないことを明示しておきたい場合に有効です。
- また、辞退用のレコードを公開するためのBIMIセレクタを用意しておき、そのセレクタ名を指定(BIMI-Selectorヘッダ)して送信されたメッセージは、ロゴ表示されません。他のセレクタではロゴ表示できるようになっていても、セレクタで使い分けることができます。

ロゴ画像の形式

(4.2.2. Supported Image Formats for l= tag)

BIMIで使用できるロゴ画像の形式について記載します。

2022年8月時点で、SVGとその圧縮形のSVGZが許可されています。
RFC6170 section 5.2に定義されたSVG、SVGZファイルをlタグに使用可能です。
その他の制限として、SVG Tiny Portable/Secure(SVG Tiny PS)の要件が適用されます(参考：BIMIの準備：ロゴの準備(digicert))。
メール受信時の検証の際、lタグで指定されたURI中のファイル拡張子が異なっていたり、受信したファイルが別形式の場合、BIMI認証はエラーとなります(MUST)。

セレクタ

(4.3. Selectors)

メール送信者は、BIMI-Selectorヘッダにより、そのメッセージのBIMI認証に適用すべきセレクタを指定できます。指定が無い場合は”default”というデフォルトのセレクタ名が使用されます。DKIMのセレクタと同様のものです。
これは、1つのFromヘッダドメインが、複数のBIMIの設定情報を使い分けることができるということです。シーズンやイベントごとのブランディング方針に応じ、複数のロゴを使い分けることができます。
セレクタ名は、それ自体をピリオド(.)でサブドメインのように分割可能できます。セレクタをカテゴリ分け等する際に有用です。
例：name.category._bimi.example.com
定義可能なセレクタの数は無制限です。

BIMI-*メールヘッダ

(5. BIMI Header Fields)

DNSでBIMIレコード(ポリシー)の公開の他に、ドメインの管理元はBIMI関連メールヘッダを通じて追加情報を提供できます。
BIMI関連ヘッダは大文字小文字は区別しません。必須タグが無い場合、BIMI認証はエラーになります。

BIMI-Selectorヘッダ(5.1. BIMI-Selector Header)
- default以外のセレクタ名以外を使用したい場合に、メール送信者が指定します。
- 以下の書式です。
  - vタグ(必須)
    - バージョン情報です。
    - 本記事作成時点で選択可能な値は”BIMI1″のみです。
  - sタグ(必須)
    - セレクタ名です。
BIMI-Locationヘッダ(5.2. BIMI-Location Header)
- メール受信者(BIMI認証を行ったMTA等)が、MUAにどこからロゴを取得するかを示すために追加されるヘッダです。
- 以下の書式です。
  - vタグ(必須)
    - バージョン情報です。
    - 本記事作成時点で選択可能な値は”BIMI1″のみです。
  - lタグ(aタグがある場合は任意、それ以外の場合は必須)
    - ロゴを取得するためのURIです。
    - 基本的にBIMIレコードに含まれるlタグもしくはaタグのURIと同じ内容です(詳細は”7.9. Construct BIMI-Location URI”)。
    - MTAによって必要なチェックとBIMIレコード取得後に追加されます。
    - URIはHTTPS必須です。
  - aタグ(エビデンスが検証成功した場合は必須)
    - エビデンス(VMC)を取得するためのURIです。
    - 基本的にBIMIレコードに含まれるaタグのURIと同じ内容です。
    - MTAによって必要なチェックとBIMIレコード取得後に追加されます。
    - URIはHTTPS必須です。
- BIMI-Locationヘッダはメール送信者によって追加されてはいけません(MUST NOT)。(6.4. Set the headers on outgoing email as appropriate)
BIMI-Indicatorヘッダ(5.3. BIMI-Indicator Header)
- メール受信者(BIMI認証を行ったMTA等)が、MUAにロゴを渡すために追加されるヘッダです。
- BASE64でエンコードされたSVGファイルが格納されます。
- BIMI-Locationで取得する画像と一致している必要性があります(MUST)。
- SVGZの場合、解凍後にBASE64化する必要性があります(MUST)。
ヘッダ署名(5.4. Header Signing)
- BIMI-Selectorヘッダが存在する場合、それがDKIM署名対象範囲に含まれるべきです(SHOULD)。ここで言及されているDKIM署名は、ヘッダFromドメインを認証対象としたDKIM(DMARC aligned DKIM)のことです。
  BIMI-SelectorヘッダがDKIM署名対象範囲に含まれない場合、そのヘッダ(BIMI-Selector)は無視されるべきです(SHOULD)。
- 受信者はBIMI-Selectorの検証方法を追加することができます(MAY)。例えばARC認証です。ARC認証成功した場合に、BIMI-Selectorが署名対象であるメッセージと同等の扱いをしても良いです(MAY)。
- BIMI-Locationヘッダ、BIMI-IndicatorヘッダはDKIM署名対象に含まれてはいけません(MUST NOT)。これらのヘッダは、MTAによりDKIM検証された後、MTAとそのMUA間でのみ使用されるものであるためです。よって、これらのヘッダを署名対象に含めるのは無意味です。

メールを受信する側のBIMI対応

ここでは、メールを受信する側のBIMI対応について記載します。
参照しているIETF文書は、主に以下の2つです。

General Guidance for Implementing Branded Indicators for Message Identification (BIMI) draft-brotman-ietf-bimi-guidance-06
- メールを受信する側のBIMI対応に関する文書です
Brand Indicators for Message Identification (BIMI) draft-brand-indicators-for-message-identification-02
- BIMIに関するメインの文書です

draft-brotman-ietf-bimi-guidance-06の内容

メールを受信する側のBIMI対応に関し、システム構成上、整理しておきたいポイントのみ抜粋します。

MUA、MTAの役割

(3.3. MUA Authors、3.4. MTA Authors)
ロゴを最終的に表示する(かどうかを決める)のはMUAです。
一方で、受信したメッセージを検証するのは受信者やMBPです。
また、MBPがBIMIレコード中のURLやエビデンスから直接取得せずプロキシを使用するよう構成することが理想的です。

BIMIの前提

(5.2.1. BIMI processing requirements)
BIMIはDMARC認証成功を前提としていますが(MUST)、さらに追加の要件をローカルポリシーとして設定してよいことになっています。
そのローカルポリシーの基準が厳しいほど、誤ってMUAに対しロゴ表示を許可することが少ないです。
例えば、以下のようなポリシーが例示されています。

DKIMとSPFの両方がヘッダFromアドレスの組織ドメインで検証済みであること
DMARCでは、DKIMとSPFのどちらか一方がヘッダFromと一致することが必須要件になっています。
SPFにおいて、”-all”を必須とすること
“?all”や、大きなアドレス空間に対する許可設定を拒否する設定です。

BIMI対応済みの受信者は、既に存在しているBIMI-Selector以外のBIMI-*ヘッダを削除もしくはリネームすべきです。それらのヘッダが攻撃者によって追加されたものかもしれないためです。”BIMI-Selector以外”というのは、BIMI-SelectorがDKIM署名に含まれている場合の話です。そうでない場合はBIMI-Selectorも削除もしくはリネーム、あるいは無視されるべきです。
BIMI対応していない受信者も、これらのヘッダを削除すべきです。MUAが適切に認証されていないメールにロゴを表示することを避けるためです。MUAは、BIMI関連ヘッダーを使用すべきでなく、メールストアの設定に依存すべきですが、MUA単独でヘッダを使用してしまう動作は可能です。
メールをいったん受信後、そのサイトの外に出ていくメールについても、同様にBIMI-*ヘッダーを削除すべきです(再配送などのケースと思われます)。

MTAからMUAへのBIMI認証結果の伝達

(5.3. Communicating BIMI results between the MTA and the MUA)
メール受信するシステム(MTA)は、MUAに画像表示すべきことを知らせるために、以下を行います。

MTAはBIMI認証しなければいけません。認証成功した場合、表示すべきロゴを含むヘッダを追加します。
MUAはロゴを読み込む前に、BIMI認証成功したかをチェックしないといけません。
MTAによって追加されたヘッダは、それらが信頼できるものによって追加されたヘッダであることの追加チェック無しで、MUAから依存(信頼)されるべきではありません。例えば、MTAがメール受信時に既存のBIMI-*ヘッダを削除しているかどうかの確認や、信頼のおけるARヘッダからbimi=passを確認を行うことです。

MUAによるロゴの取得

(5.4. Image Retrieval)
BIMIの仕様において、MUAによるロゴの取得方法は重要です。以下の方法があります。

MUAが、BIMI-Locationヘッダ内のURIから直接ダウンロード
最も基本的な方法です。
MTAがメールヘッダに追加したロゴ画像データをMUAが取得
推奨される方法です。
MTAがメールヘッダにBASE64エンコードしたロゴ画像データを追加し、MUAがそのヘッダからロゴを取得するものです。MUAにとっては、既にMTAが取得および認証したロゴを取得できるので推奨されています。
この方法は、メールのサイズに関して注意が必要です。1～30KBのSVGファイルをBASE64エンコードすると35%程度大きくなります。そのエンコード後のサイズ分、増加することになります。
キャッシュされたロゴをMUAが取得
ローカル領域にロゴをキャッシュし、その領域をメールヘッダにロゴ取得用のアドレスとして示す使用する方法です。プロキシのような運用方法です。
具体的なローカル領域の場所について言及が無いので、推測となりますが、原理的には受信者側の裁量で任意の場所を指定可能と思われます。
- 受信者サイト内のどこか(MTA、MBP、その他)にキャッシュ
- MUA内にキャッシュ
キャッシュの具体的な仕組みはMBP全体の実装によると思われます。
- 例えば(GmailのBIMI動作を見て思ったことですが)、キャッシュしたロゴを使用するためにBIMI-SelectorヘッダやBIMI-Locationヘッダを必ずしも使用しなくても動作は可能と推察されます。
  MUA(WebMailや専用アプリ)とMBPがBIMI対応のため独自に連携できている場合、MUAへのロゴ情報伝達としてのこれらのヘッダ使用を省略し、MBP主導で適切にキャッシュ画像表示を処理する方が効率や安全性が高い実装になるだろうという意味です。
- ちなみに、(キャッシュでなく)ロゴのおおもとの配布元についても、送信元ドメインとは別ドメインのURIでもよいことになっています(7. Brands)。

HTTPリダイレクトの制限

(5.5. Limited use of HTTP Redirects)

メールを受信する側は、ロゴやエビデンス(VMC)を取得するためのURIへのアクセス時にHTTPリダイレクト応答となった場合、そのリダイレクトに従わない、もしくは限られた回数までのリダイレクトにのみ従うといった動作を選択可能です。
そういった制限をしている受信者によりロゴが受信されなくなる事態を避けるため、送信者はHTTPリダイレクトを排除、もしくはその回数を制限すべきです。

キャッシュした画像のTTL

(5.6. TTL of cached images)
メールを受信する側の設定として、MUAがロゴを再取得しない期間(TTL)の話です。

TTLが短すぎるとMUAによる画像参照が多くなりすぎます。
TTLを以下のように設定することも可能です。
- 数時間
- 1日
- ロゴ画像を含むエビデンス(VMC)の有効期限と同じ
キャッシュ実装の欠点は、キャッシュの仕組みにおいて証明書失効チェックや再取得が必要となる点です。

プライバシーに関する考慮

(6. MUA Authors -> 6.3. Privacy Concerns)
メールを受信する側において、プライバシー漏えいに関する以下の考慮が必要です。

例えば、送信者は宛先メールアドレスごとに異なるセレクタを用意したり、ロゴ取得用のURIに追跡のための文字列を追加することができます。
これにより、宛先メールアドレスごとにロゴ画像取得タイミングから行動を追跡される可能性があります。
メールを受信する側は、ある組織ドメインが使用しても良いセレクタの数を定義し、その数を超えた場合に処理を拒否することができます。
MTAは、追跡を制限するため、BIMIレコード、エビデンス(VMC)、ロゴをキャッシュした方が良いです。
MUAは、ロゴを直接取得するよりBIMI-Indicatorヘッダから取得した方がよいです。これはMUAがロゴを取得していることが分かるのはMTAのみ(ここはMTA以外に、BIMI-Indicatorヘッダで指定された、信頼されているであろうロゴ取得先やキャッシュ先も含む意味かと推察しています)となるように制限できるからです。
BIMIは、SVGプロファイルで外部からSVGを読み込むことを禁止することを認めています。これはMUAがロゴを表示する際の追跡に関するリスクを取り除くことができます。

ロゴの配置等

(7. Brands)

ロゴを配置するホストは、メールの送信元ドメインと別ドメインのホストでも問題ありません。全てのメール送信元ドメインに対応するWebサーバが存在するとは限らないためです。(7.1. Logo Hosting Considerations)
BIMIのロゴ取得の処理は通常のブラウザと異なる動作となるため、CDNから要求されるチャレンジ応答不可となり、ロゴを取得できない場合があります。
そのため、CDN側の対応としては、誰からでもアクセスできるよう構成すべきです(チャレンジ要求無しで)。(7.2. CDN Considerations)
エビデンス(VMC)は、1つ以上のドメイン名を提供します。SAN(別名)を定義することも可能です。
これらのドメイン名は、ヘッダFromドメイン名と一致している必要性はありませんが、BIMIレコードで使用されているドメインと一致している必要性があります(そのレコード自体のドメインのことかと思われます)。
例えば、VMCに組織ドメインを定義してある場合、3rdレベルドメインもこのVMCを使用できることになります。
(7.3. Domains listed in your evidence document)

基本的なフロー

(9. Basic flow example)
後述の別文書の方が詳しい記述なので、そちらにまとめます。

draft-brand-indicators-for-message-identification-02の内容

メールを受信する側のBIMI対応に関し、システム構成上、整理しておきたいポイントのみ抜粋します。

メール受信時のBIMI認証フロー

BIMI認証の前提

(7.1. Authentication Requirements)

1. ヘッダFromが複数ある場合、BIMI処理は実行されていないけません(MUST NOT)。
2. ヘッダFromのDNSドメインをAuthor Domainと定義します。
3. Author Domainの組織ドメインを決定します。これをAuthor Organizational Domainと定義します。Author Domainが組織ドメインであれば、そのまま組織ドメインはAuthor Domainとなります。
4. Author Domainに対するDMARC結果を評価します。この結果は、BIMI DMARC Resultと定義します。
5. BIMI DMARC Resultがpassでない場合、受信者は追加の認証メソッドを適用しても良いです。例えばARC評価や、ローカルポリシー適用です。
受信者はこの場合、BIMI DMARC Resultがpassの場合と同様なものとして扱っても良いです(MAY)。
6. DMARC結果がpass以外、かつ追加の認証メソッドも成功しない場合、BIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)
7. Author Domain or Author Organizational DomainのDMARCポリシーがp=noneの場合もBIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)。
8. Author Domain、もしくはAuthor Organizational DomainのDMARCのサブドメインポリシーがあり、sp=noneの場合、BIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)。
9. Author Domain、もしくはAuthor Organizational DomainのDMARCポリシーがp=quarantineで、かつpctタグがある場合には、pct=100でないと、BIMI処理はそのメッセージに対して実行されてはいけません(MUST NOT)。

BIMIレコードの検索

(7.2. Assertion Record Discovery)

BIMIレコードの検索は、DMARCレコードの検索と似ています。
メールを受信する側のポリシーに基づく認証が失敗したメールに対しては、BIMIレコード検索を試みてはいけません(MUST NOT)。
以下の相反する要件とのバランスを取る必要があります。
- ワイルドカードサポート
- サブドメインポリシーオーバーライドの許可
- DNSクエリ負荷の制限
  そのために、Protocol Clientは以下の検索方法でBIMIレコードを検索しなければいけません(MUST)。
1. ヘッダFromのDNSドメインをAuthor Domainと定義します。
2. セレクタ名を決定します。BIMI Selectorヘッダあればそれ、無ければ”default”をセレクタ名とします。
3. DNS検索します(MUST)。レコードが無い場合もあります。
4. 取得したBIMIレコードがvタグから始まらない場合、無視します(MUST)。
5. レコードが無い場合、組織ドメインで再問合せします(MUST)。レコードが無い場合もあります。
6. 取得したBIMIレコードがvタグから始まらない場合、無視します(MUST)。
7. レコードが複数ある場合、あるいはレコードが無い場合、BIMIレコード検索は終了し、そのメッセージに対してBIMI認証は実行されてはいけません(MUST NOT)。
8. レコードが1つのみであれば、そのレコードをBIMI認証に使えます。

ロゴの検索

(7.3. Indicator Discovery.)

1. BIMIレコードにlタグが無い場合、ロゴの検索は失敗します。ロゴは表示されてはいけません(MUST NOT)。
2. a=タグがあり、かつ受信者がBIMIのエビデンス検証に対応している場合、後述のIndicator Discovery With Evidenceに進みます。
3. 受信者がBIMIのエビデンス検証に対応していない場合、もしくはa=タグが無い場合、後述のIndicator Discovery Without Evidenceに進みます。

エビデンスがある場合のロゴの検索

(7.4. Indicator Discovery With Evidence)

BIMI Evidence Documentの種類ごとに、追加の検索や検証の方法を指定できます(MAY)。詳細は別ドキュメントです。
以下、draft-brotman-ietf-bimi-guidance-06より、エビデンスとしてVMCを使用する場合のフローです。
- VMCの検証
  - 受信者はBIMIレコードで指定された場所からVMCを受信します。
  - VMCが信頼できるroot CAを使用しているか検証します。
  - 検証成功したら次へ進みます。
- VMCから画像の取得
  - 受信者はVMC内の画像を取得します。
  - 取得したSVG画像を検証します(後述の”ロゴの検証(7.6. Indicator Validation)”)。

エビデンスを使用しない場合のロゴの検索

(7.5. Indicator Discovery Without Evidence)

取得したBIMIレコードのlタグ、aタグの値が空の場合、そのドメインはBIMI対応しないことを明示的に示しています。この場合、MTAはAuthentication-Resultsヘッダに”bimi=declined”を追加すべきです(SHOULD)。
取得したBIMIレコードの、aタグの値が空、もしくはaタグのURIからエビデンス取得できない場合、以下の手順によりlタグで指定されたURIからロゴが取得されなければいけません(MUST)。
- 1. lタグのURIからSVGを取得します。
- 2. HTTPSのTLS証明書の検証に失敗したらロゴの検証は失敗となり、ロゴは表示させてはいけません(MUST NOT)。
- 3. 後述のIndicator Validationステップに進みます。
なお、IETF文書のこの章に記載は無いですが、エビデンスが無い場合のBIMI認証成否は、メール受信者側でエビデンスが無い場合のBIMI認証を行うポリシーかどうか、またその送信元ドメインを個別に信頼しているかどうかによると思われます。

ロゴの検証

(7.6. Indicator Validation)

1. 取得したロゴのファイルサイズを、推奨の最大サイズに照らしチェックします。受信者独自のサイズ制限を設定しても良いです(MAY)。
推奨の最大サイズは、おそらく SVG Tiny Portable/Secure draft-svg-tiny-ps-abrotman-04にある記載のことで、SVG(SVG Tiny PS)はできるだけ小さくすべきであり、非圧縮時の32KB以内であるべきとのことです(SHOULD)。
受信者は、ドキュメント全体を取得してからサイズをチェックするのではなく、受信制限としてサイズ制限を実装しても良いです(MAY)。
2. SVGファイルが存在しないか、有効でないSVGファイルやSVGZファイルである場合、ロゴの検証は失敗となり、表示してはいけません(MUST NOT)。
3. SVG validation stepsへ進みます。これは、このドキュメントと、別のSVGに関する文書に記載の内容です(詳細は未確認です)。
4. ロゴの検証が成功し、またそのロゴが信頼されたソースから取得されたものであれば、受信者側のポリシーに沿ってロゴを表示して良いです(MAY)。BIMI認証成功です。
- 以下、draft-brotman-ietf-bimi-guidance-06より、補足です。
  - メールスキャン
    - BIMI認証の成否に関わらず、マルウェア対策やスパム対策等のコンテンツに対するスキャンは必要です。
  - MUAによるロゴ表示
    - メールを受信したMUAはBIMI-*ヘッダをチェックします。
    - BIMI-Indicatorヘッダ(あれば)から画像を取得します。
    - ロゴを表示します。
    - BIMI認証成否に関わらず、メールスキャンによりフィッシングやマルウェアと判断されたメールは、MUAはロゴ表示すべきではありません(SHOULD NOT)。スパムであると判断されたメールの場合は、受信者はロゴを表示しなくても良いです(MAY)。
  - BIMI認証が失敗した場合
    - MTAはMUAに対してロゴ表示するよう指示してはいけません。
    - MUAは、イニシャルの画像や、不明な送信者用のデフォルト画像を表示しても良いです(MAY)。

ARヘッダに追加されるBIMI認証結果

(7.7. Affix BIMI Status to Authentication Results Header Field)

上記のBIMI認証後、MTAはAuthentication-Resultsに認証結果を追記します(SHOULD)。
内容は以下の通りです。
- bimiキー(必須)
  - BIMIの認証結果です。
  - 記載可能な値は前述の通りです。
- header.dキー(bimi=passの場合、必須)
  - 検証対象となったBIMIレコードのドメイン名です。
  - この値は、基本的にヘッダFromドメインです。BIMIレコード検索時、フォールバックしていたら組織ドメインとなります。
- header.selectorキー(bimi=passの場合、必須):
  - 検証対象となったBIMIレコードのセレクタ名です。
- policy.authorityキー(BIMI Evidence Documentがチェックされた場合、必須)
  - エビデンスの検証結果です。
  - エビデンスが提示され、かつチェックされ有効だった場合、”pass”を設定しないといけません(MUST)。検証に失敗したら”fail”に設定しないといけません(MUST)。
  - エビデンスが無い、もしくはMTAがチェックしなかった場合はnoneを設定すべきです(SHOULD)。
- policy.authority-uriキー(任意)
  - チェックされたエビデンスのURIです。
  - BIMIレコードのaタグに設定されていたURIです。

既に存在しているBIMI関連ヘッダの扱い

(7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers)

BIMIレコード検索に成否に関わらず、BIMI-Locationヘッダ、またはBIMI-Indicatorヘッダがメールに存在する場合、それらを削除するかヘッダ名を変更しないといけません(MUST)。
通常、BIMI認証を行うMTAはMDAの直前(あるいはMDAと同じ管理下)にあり、唯一BIMI-Location or BIMI-Indicator を指定してよい存在であるためです(送信元MTAや中継MTAではないということです)。
既に存在していたBIMI-LocationヘッダやBIMI-IndicatorをMUAにそのまま伝達することは、セキュリティリスクとなります。
メールがDKIM署名を含んでいた場合でも、BIMI-Locationヘッダを削除しても、DKIM署名は無効にならないはずです。BIMIの仕様に従えばBIMI-LocationヘッダはDKIM署名対象範囲に含まれないからです。またMTAがメールを受け取った際にDKIM検証は済んでいるはずです。
関連情報が、draft-brotman-ietf-bimi-guidance-06の5.2.1. BIMI processing requirementsにもあります(本記事でも前章で言及済み)。

BIMI-Locationヘッダの構成

(7.9. Construct BIMI-Location URI)

BIMIの検索や検証が失敗した場合、BIMI-Locationヘッダは追記されてはいけません(MUST NOT)。
エビデンスからロゴを取り出した場合、bimi-evidence-location(BIMIレコード中のaタグ)の値になり(SHOULD)、それ以外の場合は、bimi-location(BIMIレコード中のlタグ)の値となります(SHOULD)。
なお、aタグとlタグの両方がある場合、それらのロゴが一致することをMTAはチェックしなければいけません(MUST)

BIMI-Indicatorヘッダの構成

(7.10. Construct BIMI-Indicator header)

BIMIの検索や検証が失敗した場合、BIMI-Locationヘッダは追記されてはいけません(MUST NOT)。
このヘッダの文字数は多くなりますが、1行あたりの文字数の制限以内で折り返さなければいけません(MUST)。1行あたりの制限は、RFC5322の2.1.1. Line Length Limitsにある”CRLFを除いて、各行は998文字を超えてはならならず(MUST)、78文字を超えるべきではない(SHOULD)”のことです(RFC5321にも類似の記載あり)。

BIMIのセキュリティに関する考慮事項

(8. Security Considerations:an incomplete list of considerations)

いくつか備忘用に抜粋して記載します。

再配送(8.1. Indirect Mail Flows)
- 再配送は、メーリングリストや転送のことです。
- 再配送されると、再配送先には、既にBIMIヘッダが追加されたメールが届く可能性があります。
- 再配送先の受信者は、再配送したメールシステムを信頼しているなら既存のBIMIヘッダを使用しても良いです。あるいは、再配送先で再度BIMI認証を行い、BIMI-Locationヘッダを再作成しても良いです。
認証対象ドメインとロゴ配置先の不一致(8.5. Unaligned Indicators and asserting domains)
- ロゴの管理者が、ドメインの特定の場所(公開Webサーバ)にロゴを配置できるとは限らないので、BIMIの認証対象ドメインに配置することを必須とするのはハードルが高過ぎます。
- 認証対象ドメインの外にロゴを置くこと望ましいケースがあるかもしれません。
  - 例えば、正当な第三者がドメインのDNSやWebサーバにアクセスすることなく、セレクタを管理・設定できるようになります。ドメインの管理元に代わって正当な認証済みメールを送信できる誰かがいるケースです。
BIMI-Selectorヘッダが署名対象外の場合(8.6. Unsigned BIMI-Selector Header)
- 受信者は、BIMI-Locationヘッダを追加するかどうか決定する際に、DKIM署名の有無を考慮に入れることができます。
- DMARC認証成功が、DKIMでなくSPFの認証成功だけによる者である場合、BIMI-Selectorが改ざんされていないことを署名により担保できないためです(ARCも考慮するなら、ARCによる署名もあります)。
ロゴ中のCGIスクリプト(8.7. CGI scripts in Indicator payload)
- MTAとMVAは、インジケーターが適切ものであるかを積極的にチェックすべきです。
- また、MTAは適切なインジケーターをキャッシュし、それらをMUAに直接提供する場合があります。これにより、MTAではなくエンドユーザーに実行されるよう意図された悪意のある動的データを回避できます。

BIMI仕様の背景

備忘用に、An Overview of the Design of BIMI draft-bkl-bimi-overview-00の内容を一部記載しておきます。

4.2. S/MIME signatures
- 原則として、インジケータはS/MIMEによりアサートできる。実装や普及が難しいため基本的に使われない方法。
6. Validator options
- 検証者には色々な検証の選択肢がある。第三者による検証など。
7.1. Issues
- MUAがBIMI-LocationヘッダのURIを用いてロゴ取得すると、Web bug問題が生じる。
- MTAによるBIMI-Locationヘッダ追加で、この問題は回避できる。MTAはロゴをキャッシュしローカルURIをヘッダ(おそらくBIMI-Locationヘッダ)に挿入することもできる。MTAによるロゴ取得により、送信者にメールがそのドメイン(BIMI認証を行うシステム)に届いたことは分かるが、最終的な受信者は直接ロゴ取得しないので最終的な受信者の行動は把握されずに済む。
9.4. IMAP flags
- MDA(LMTPサーバ等)がメールに対し、そのBIMI-Locationヘッダが本物であることをマークするためのIMAPフラグを付与できる。
- 他のアプローチとして、MDAがDKIM署名を追加する方法。そのDKIM署名には、受信者ドメインのdタグを含み、新しいBIMI-Locationヘッダを署名範囲に含む。これはMUAがDKIM署名を検証するということ。なりすましに注意が必要。
- (個人メモ)メールストアとMUAが一体となったMBPでなく、クライアント端末上で動作するメーラの場合、既存のIMAPプロトコル内で実装できるBIMI認証結果等の伝達方法があると有用。POPも。