ドコモで 2021 年 5 月中旬から提供されるという「ドコモメール公式アカウント」について軽く考えてみました．

本稿はあくまでいち学部生の浅はかな考察であり，何らかの組織の意見を代表するものでもないですし，考えの深さはその程度です．

筆者のバックグラウンド

本サイトではあまり紹介していないのですが，私はいくつかのメールサーバの運用に携わっており，特に不正メールの取り扱いに関して興味をもっています．

特にお金をもらって運用や研究をしているわけではないのですが，大きなお友達の皆さんと情報交換をして日々勉強しています．

ドコモメール公式アカウント

公式サイトによると

「ドコモメール公式アカウント」とは、ドコモメールのフィッシング詐欺メール※1 対策を目的に、ドコモおよびお申込み企業さま・団体さまの公式アカウントから送信されたメールに、ドコモメール上で公式アカウントのマークを表示する機能です。 お客さまは一目で公式アカウントからのメールであることがわかるので、あんしんしてメールの内容をご確認になれます。

という機能らしいです．

対象のメールにはドコモメールのアプリ上で緑色のチェックマークが表示されることになっています．

まずは，フィッシング・スミッシングが横行する世の中で，エンドユーザの利用者をそれなりに抱えているキャリアメール事業者でわかりやすい取り組みを始めたことは評価できると思います． しかし，サービス開始前時点で個人的に問題点がいくつかあるような気がします．

問題点 1: SPF 至上主義

このマークの付与基準ですが，予め申請があった企業・組織のドメイン名からのメールについて，SPF の判定に基づいて付与するようです． そもそも SPF は送信元 IP アドレスだけに基づいて判定を行うフレームワークであり，不正メールの発見に役立つものではありますが，単体では不十分です．

特に，SPF の判定結果は PASS/FAIL のバイナリではなく，ドメイン名管理者が DNS で明示するポリシに基づき複数の判定が可能ですが，今回はそれがどのように扱われるか不明です． 例えば，組織 A の管理者はメールフローの刷新統合中であり，SPF の否定条件に ?all を用いているとします． はたまた組織 B では綺麗なメールフローのデプロイが完了しており，SPF の否定条件に -all を用いてポリシに適合しない送信元 IP アドレスを明確に否定しているとします． この場合でも PASS となるようなメールが到着した場合，ドコモメールでは一律にチェックマークを表示し，ユーザに同程度の信頼を強制することになります． これは PASS 以外のメールが到着した場合の「信頼しないこと」の裏返しであり，SPF ポリシを考えた人の意図に反することになります．

問題点 2: 転送・メーリスなど SPF の問題点をそのまま引き継いでいる

SPF はとても有用な枠組みですが，得意なことと不得意なことがあります． 現在の世界のメール事情的には，それを踏まえて SPF を含めた複数の枠組みや判定基準で不正メールを発見しています． ドコモメール公式アカウントでは，そのような SPF の問題点をカバーすることなくそのまま引き継いでしまいます．

少なくともドコモが認識している点を挙げると，転送やメーリスで組織外のメールサーバを経由した際に，ドコモのメールサーバ視点では意図しない IP アドレスのサーバから受信することとなり，SPF では誤判定が発生します．

問題点 3: マークの表示が申請制

SPF の判定自体は申請などしなくても当然勝手にできるわけで，申請した企業に限定してマークを表示しているのはなぜなのでしょうか． そもそも，SPF だけではなく DKIM や DMARC など多くの枠組みは正規送信側の申請に基づいて受信側の判定実施有無を変えるような枠組みではなく，判定を導入している多くの受信サーバでは勝手に判定を行っています． また，各ポリシを制定し DNS 上で公表する正規送信側も，勝手に判定される前提でそのポリシを定めています．

また，受け取ったユーザ側としてもどのようにメールを扱っていいか疑問です． 送信元に関係なく，マークのないメールを受け取ったユーザは毎回，このリストを訪れて送信元とされている対象がマークの判定対象にあるかどうかを確認し，その上でマークの有無によって信頼するかどうか判定しなければなりません． はたしてこの手法は現実的なのでしょうか．

もしかしたら，類似ドメイン名への対抗が難しいという現状の送信ドメイン名認証技術への打開策として正規ドメイン名の申請制が取られているのかも知れませんが，だとしたら後述のとおりなおさらマークの表示方法に疑問が出ます．

問題点 4: マークがなかったらどうする?

仮に受信者が，対応組織を名乗っているけどマークがついていないメールを受信したとしましょう． まず，この場合でも前述のとおり組織の管理者が ~all のポリシを使用している可能性を考えると，マークがついていないだけで意図した相手でないと言い切っていいということにはなりません．

たとえば，ここに DMARC やその他の枠組みによる指標を取り入れ，明確に PASS/FAIL を表示すれば，組織の管理者の意図に沿って的確に「正常なメール」「不正なメール」と見分けることができます (そもそも不正なメールは通さなければいいのですが)． なお，それらの枠組みを用いたからと言って必ず組織の管理者が意図をはっきりさせたポリシを提示するとは限りませんが，少なくとも SPF では受信したメールの取り扱いについてポリシでは明示できません．

また，マークが表示できない場合に何も表示しないのも疑問です．急いでなにかするように指示するフィッシングメールを受け取った利用者は，「そういえばドコモではチェックマークを使った仕組みを導入していたけど，このメールにはチェックマークがない」と思い出せるでしょうか?

もしこの判定に自信があるならば (私はこの判定条件に自信は持てないですが)，チェックマークの有無ではなく，チェックマークかバツマークの表示，のような形式が良いのではないでしょうか． ユーザが「信頼していいかどうかわからない」ときに「信頼する」に傾くのではなく，「信頼しない」に傾くような設計にすべきです．

とりあえず紹介を見てパッと思いついたところをいくつか挙げてみました．今後修正があれば適宜筆を入れます．

キャリアメールの方々には，コンシューマー向けメールサービスの先駆者として，ぜひ 2021 年にどのような運用・トラストモデルが必要とされているのか，真剣に考えていただきたいものです (どこぞからの運用圧力には頭が上がりません)． そして，ユーザに信頼すべきかどうかの判定を押し付けるのではなく，受信メールサーバの管理者でそれを考えてユーザにより良い体験をもたらす仕組みはいくつもありますので，ぜひ参考にして頂ければと思います．

付録: 利用組織の SPF/DKIM/DMARC 対応状況

対応組織がリストアップされていたので，それぞれのドメイン名で SPF/DKIM/DMARC を利用しているか調べてみました． ドメイン名は web サイトを参考に組織で利用している大元のドメイン名 (PSL+1) などで調査しています． そのため，この調査で非対応だからといって必ずしも実際のメールフローで非対応というわけではありません． もし実際に送信しているドメイン名と異なるなどあればご連絡頂ければ幸いです (調べ直します)．

調査は DNS を用いてポリシの公表状況を検索しました． 調査方法と表の見方は次のとおりです． なお，以下に定義していない DNS 応答が返ってきた場合は注釈によって詳細を記述しています．．

SPF

以下のコマンドを発行し，ポリシを検索する． dig TXT [調査ドメイン名] @[反復検索で得られた権威サーバ] +norec DNS 応答が NXDOMAIN ないし NODATA の場合，対応していないと判定し×をつける． DNS 応答が NOERROR の場合は，RFC に基づき，all mechanism についている qualifier によって以下のように判定する．

DKIM

以下のコマンドを発行し，selector のサブドメインの存在を検索する． dig TXT _domainkey.[調査ドメイン名] @[反復検索で得られた権威サーバ] +norec DNS 応答が NXDOMAIN の場合，RFC に基づきサブドメインにいかなる selector も存在せず，よって公開鍵が公表されていないと判定し×をつける． DNS 応答が NODATA の場合，上記の理由でサブドメインに何らかの selector が存在し，よって公開鍵が公表されている可能性が高いと判定し○をつける． DNS 応答が NOERROR の場合で t=y が指定されている場合，testing と表に記述する．

DMARC

以下のコマンドを発行し，ポリシを検索する． dig TXT _dmarc.[調査ドメイン名] @[反復検索で得られた権威サーバ] +norec DNS 応答が NXDOMAIN の場合，対応していないと判定し×をつける． DNS 応答が NOERROR の場合は，その p タグを表に記述する．また，sp タグで p タグと異なるポリシが記述されている場合や pct タグで 100 以外の値が記述されている場合は，それもあわせて表に記述する．

調査結果

※1: NODATA 応答．明らかに使っていなさそうなドメイン名をクエリしても NXDOMAIN ではなく NODATA．どなたか DNS 詳しい方教えてください．

※2: ※1 の都合上，この結果はあまり信頼できません．

※3: 当該ドメイン名は対応組織ではないファイナンシャルグループのドメイン名ですが，DMARC の fall back などの都合を鑑みて調査しています．

※調査の過程で各社の何らかの設定等に不備が発見されることがあった場合，見つけた範囲内ですべて当該事業者に報告と対処依頼を行っています．

余談ですが，既に RFC や現実のインターネットメールで多く取り入れられている枠組みに対応する気を見せず，顧客に月一で「フィッシングにご注意を！」とメールを送るのは，やるべき仕事を放棄して騙される責任をユーザに押し付けているように見えてしまいます．あくまで個人の感想ですが． 今回調査した範囲では既に頑張って対応を進めていたり，多少なりとも改善に向けて努力する意思の見えるポリシがいくつか見えたので，日本を導く企業の皆様にはぜひ先頭に立ってフィッシング撲滅，ひいては顧客の保護にご尽力いただきたいです．