世界と日本のメール送信ドメイン認証

【IIJ 2017TECHアドベントカレンダー 12/20（水）の記事です】

ども、やまぐちです。昔はメール屋さんもやってました。廃業してもう何年も経つけどね。

先日は Alexa Top 1M の100万ドメインから DNSSEC の普及状況を調べてみたけど、せっかくなんで同じリストを使って今回はメールの送信ドメイン認証の普及状況を調べてみるよ。ついでのつもりで始めたらえらく時間がかかってすげー後悔したけどな。

ちなみに、.jp に対する定期調査は以前 WIDE プロジェクトがやってたけど、最近は更新がとまってる模様。もうやめちゃった？

いまどきのイケてる送信ドメイン認証

そもそもまず送信ドメイン認証が何なのかって、ってところから。みんな使ってるメール（あ、もうみんなメールやめて LINEですか）ってのは、もともとの規格では送信元アドレスはすげーかんたんに詐称できて、他人になりすましても見破られにくいものだった。それじゃ困るよねってことで、詐称を見破れるような仕組みが後から考えられて、それが送信ドメイン認証。あくまでなりすましを「見破る」ためのものであって、なりすましそのものを「防ぐ」ものではないことに注意。依然としてなりすましは可能。

で、いろいろ種類があるんだけど、それぞれお互いに矛盾するわけではないので、できればいくつか併用するのがよい。いまなら SPF、DKIM、DMARC の3点セットがおすすめ。

この記事では他に SenderID とか Domainkey とか DKIM ADSP とかいうキーワードも出てくるけど、ぶっちゃけ知らなくてもいいよ。

これらがそれぞれどんなものなのかをまじめに解説するととんでもなく長くなるので、詳細は他サイトを参照してくださいませ。以下軽く一言で。

• SPF/SenderID
  • 「あるドメインからのメールは特定のホストから送信される」という点に着目して、その特定ホストからのメールかどうかをチェックして送信元の偽装を防ごうというもの
  • SenderID (RFC4406, 4407) は名目上「SPF 2.0」ということになっているが、いろいろあって（いろいろの詳細は思い出さない）普及に失敗したので、無視してバージョン1の SPF (RFC7208) を使うべし
• DKIM/DomainKey
  • 他人が偽造できない電子署名をメールに付与しておけば詐称を防げるよね、というもの
  • 現行規格は DKIM (RFC6376) で、DomainKey (RFC4870) はその前身
    • ちなみに、RFC4870 はリリース後何年か経ってから Historic に変更されたのではなく、はじめから Historic としてリリースされた極めて珍しい RFC
• DKIM ADSP/DMARC
  • 送信元詐称と判定されたメールをどう扱ってほしいかを宣言するもの
  • DKIM ADSP (RFC5617) はその名のとおり DKIM のみ
  • DMARC (RFC7489) は DKIM/SPF に対応し、またレポート機能などがある
  • DMARC は直接的に ADSP の後継というわけではないが、実質的にはそう考えてまあ間違いではない

調査対象と判定基準

DNSSEC は DS レコードを調べただけなので簡単だったけど、送信ドメイン認証は調べなきゃいけないところがたくさんあってめんどくさい。まずは、調査方法をざっと箇条書きにするよ。

• 調査対象
  • Alexa Top 1M のリストされている100万ドメインを調査
    • リストに記載のないドメイン、記載があるドメインのサブドメインは調査していない
    • このリストは Web サイトのランクづけなので、メールの利用が多くても Web サイトがなかったりあっても閑散としていればリストから漏れている可能性がある
  • MX レコードが存在するドメインのみ抽出
    • MX が存在していなければ、仮に SPF や DKIM を設定していても数に計上されていない
• SPF/SenderID
  • TXT RR に設定されているもののみが対象
    • SPF RR は調査していない
    • 以前(RFC4408)は TXT と SPF のどちらを使ってもよかったが、RFC7208 で TXT に一本化された
  • 目視するだけでもかなりの設定ミスが発見されたが、数が多くてとても精査しきれないので、単純に /^v=spf1/ または /^spf2\.0\//という正規表現にマッチした TXT レコードが記述されていれば設定の意思ありとして計上
• DKIM/DKIM ADSP/Domainkey
  • (selector)._domainkey.example.com という TXT レコードに公開鍵が登録されるが、selector 部分は任意文字列で、実際に署名されたメールを見ないと不明
  • よって、以下の手順で DKIM/Domainkey を宣言していると推定
  1. _adsp._domainkey.example.com/IN/TXT が /^dkim=/ という正規表現にマッチすれば DKIM および DKIM ADSP を宣言と判定
  2. _domainkey.example.com/IN/TXT を問い合わせ、
     1. 応答が NOERROR であれば、(ランダム文字列).example.com/IN/TXT を問い合わせ、
        1. NOERROR であれば *.example.com のワイルドカードが設定されていると判定、3へ
        2. NXDOMAIN であれば *.example.com のワイルドカードは設定されていない = _domainkey.example.com は単独で設定されているとみなし、DKIM/Domainkey 宣言と判定
     2. 応答が NXDOMAIN であれば、DKIM/Domainkey 宣言なしと判定
  3. (ランダム文字列)._domaineky.example.com/IN/TXT を問い合わせ、
     1. NOERROR であればワイルドカード、DKIM/Domainkey 宣言なしと判定
     2. NXDOMAIN であればワイルドカードではない、DKIM/Domainkey 宣言と判定
  4. 以上のステップで NOERROR/NXDOMAIN 以外のステータス(SERVFAILなど)が返ってきたら宣言なしと判定
  • DKIM には「作成者署名」と「第三者署名」の区別があるが、今回の調査では区別していない
  • 大昔 DKIM 署名するテストをしたときの公開鍵が残ったままだけど現在はまったく署名していない、という場合でも DKIM 宣言ありと判定されてしまうが、どうしようもないのであきらめる
  • DKIM と Domainkey のどちらを使っているのかは判別できない(ADSP があれば DKIM だろうけど、通常は判定不能)
• DMARC
  • _dmarc.example.com に /^v=DMARC1/ という正規表現にマッチする TXT レコードがあれば対応と判断

あー、もー、めんどくせー。

MX の設定状況

Web でしか使っておらずメールはまったく使ってないドメインも多いはずなので、そういうものを除外するために調査対象は Top 1M 全ドメインではなく、「MX レコードを持っているドメイン」に限定した。MX はメールを受け取る際に参照されるレコードであり、送るだけならなくてもよいはずだが、MX がないドメインからのメールは受け取らない設定にしているメールサーバが多く、実質的には受信だけでなく送信にも必須なので、絞り込みとしては妥当なところだろう。なお、MX を設定していても一切メールを送受信していないドメインもあるだろうだが、調べようがないので考慮しない。また、MX のかわりに A/AAAA で代用できなくはないがこれも考慮しない。

top 1M に1ドメインでも含まれる TLD の総数は755、そのうち MX を持つドメインが100以上ランク入りしているのは 167 TLD。

「うちのドメインはメールを送らないよ/受け取らないよ」という意思を DNS の設定で表明することもできなくはないのだが^(*1)、上の表にはそのように表明しているドメインも計上している。

以下「全ドメイン」とか「jp ドメイン」とかの記述は、MX を持っているドメインだけを指すものとする。

SPF の宣言状況

SenderID はついでで調べただけなので気にしなくてよい。

MX を持つドメインが100以上あった TLD は167。そのうち .gdn(SPF宣言率3%) を除く166 TLD で SPF 宣言率は 35% を越えており、世界的に見ても非常によく普及している。日常的にメールを送ることのあるドメインで SPF を宣言しないのはもはやありえないといってよいだろう。

日本の場合、ガラケー全盛期の2006年から2008年ぐらいにかけて携帯キャリア各社が相次いで受信時の SPF 判定を実装し、送信側が SPF を宣言していないとケータイにメールが届かなくなる（かもしれない）ということで一気に普及が進んだという経緯がある（この時期の急激な普及状況は WIDE プロジェクトによる調査でも見て取れる）。しかし逆に言えば、携帯キャリアのそういった強い圧力があってなお普及率は世界平均を若干越える程度に過ぎない、という言い方もできるかもしれない。もし携帯キャリアが対応してなかったらもっとずっと低かったんじゃないかな。

普及率が高いだけあって、記述の間違い、もしくは間違いではないが好ましくないものも多い。数が多すぎてすべては精査できないので目についたもののみいくつか挙げてみる(こういったものも上の表ではすべて対応済みとカウントしている)。

• 複数の SPF レコード: 3万ドメイン超
  • 記述が長くなる場合でも、同一のラベルに複数の SPF を並べてはならず、ひとつにまとめなければならない。複数にわけるのであれば異なるラベルに SPF を記述した上で include: で読み込ませる
• +all: 1103ドメイン
  • 「うちのドメインからのメールは世界中のすべてのホストから送っていいよ」を意味するので送信ドメイン認証の意味がない
• ipv4、ipv6: 701ドメイン
  • IPアドレスの指定は ipv4、ipv6 ではなく ip4、ip6 が正しい
• v=spf2.0: 1329ドメイン
  • SenderID(spf2.0) は v= を書いてはいけない

DKIM/Domainkey の宣言状況

DKIM と Domainkey のどちらを使っているかは実際に署名されたメールを見ないとわからないので、この記事ではひとまとめに DKIM として扱う(Domainkey はかぎりなくゼロに近いはず)。ADSP は DKIM を補助する役割のものなので、表に示した割合は MX を持つドメイン数に対するものではなく、DKIM ドメイン数に対するもの。

DKIM は全体で 1/4 弱が宣言しており、世界的に見ればそこそこ普及していると言っていいのではないかと。100ドメイン以上ある 167TLD では、.af（アフガニスタン）が唯一半数を超え(63/118 = 53.4%)、以下 .ro(ルーマニア、1457/2937=49.6%)、.ir(イラン、5718/11593=49.3%)と続く。

そんな中、.jp は 167TLD のうち157番目（下から11番目）、ccTLD にかぎれば下から4番目と非常に存在感が薄い。.tokyo は 23/199 = 11.6% で .jp よりも高い割合だけど、とはいっても .jp よりちょっとはマシという程度でしかない (167TLD 中151番目)。SPF と違って携帯キャリアからの圧力がなかった DKIM は日本では誰も見向きもしなかったということですかね。

ちなみに .jp より低い ccTLD は .gg(英王室属領ガーンジー島、5.5%)、.cn(中国、1.4%)、.kr(韓国、1.4%)で、東アジアが圧倒的にダメすぎる。

この惨状にもかかわらず、DKIM 宣言ドメインに対する ADSP 宣言の割合は全体でも 2.3% でしかないのに、.jp ではなんと2割を越え、TLD ごとで見るとぶっちぎりのトップ。え、なにこれどういうこと？ …って、ふと思いついて弊社 SecureMX サービスのマニュアルを調べてみたら DKIM と ADSP をセットで DNS に登録しとけと書いてあったわ。あれ、もしかしてうちのせい？ なお、DKIM ADSP は冒頭で説明したとおりすでに歴史の遺物となっており、もはや推奨されない。宣言する率が高くても誇ることではない。

SPF は送信メールサーバのリストを DNS に列挙すれば完了だけど、DKIM はメール一通ごとに署名する必要がある。ということで、TLD ごとではなく、国内外で比較的よく使われている主要なメールサービスごとに DKIM 宣言の状況を調べてみた。ドメイン数は優先度のもっとも高い MX のホスト名で数えているが、事業者によってバリエーションが大きいのでもしかすると数え漏れがあるかもしれない(過大に計上してることはないはず)。

うーん、ひどい。海外大手メールサービス事業者はたいていどこも DKIM に対応していて、実際に DKIM 署名するかどうかはユーザが選べるようになっている。が、国内のメールサービス提供事業者は選択の余地なくそもそも DKIM に対応していないのがほとんど（対応してないのに割合がゼロでないのは、メルマガ配信など MX として使っていないサーバからメールを送るときに DKIM 署名することがあるため）。また、DKIM に対応している海外事業者を利用している場合でも、.jp ドメインは DKIM の機能を有効にしている割合が低い。つまり、メールサービスを提供する事業者も、それを利用するユーザも、DKIM のことなんかぜんぜん気にしていないってことだよね。なんだかなー。

DMARC の宣言状況

意外と普及してた。正直 5% も宣言してるとは思ってなかったよ。ぜんぜん普及してないと感じてたのは世界的なものではなく、単に日本がダメすぎただけみたい。167TLD の中では、.jp は下から数えて5番目の低い割合(それでも 1% を越えてることにむしろ驚いたよ)。ちなみに、.jp のすぐ下が .tokyo (2/199 = 1.0%) だった。

DMARC は世界的には急速に普及しつつあるけど、日本国内ではまったくといっていいほど話題になっておらず、このままではさらに差が大きくなっていくことは間違いない。ここで立ち止まっていていいんですかね。

DMARC のポリシーも調べてみた。

合計が 100% を越えるのは、なぜか複数の DMRAC レコードが存在してたり、ひとつの DMARC レコード内で複数のポリシーを宣言しているドメインがあるから(間違い)。ドメイン自身に対するポリシーは必ず宣言する必要があり、サブドメインに対するポリシーは任意。

まとめ

ということで、著名ドメインの送信ドメイン認証の普及状況を調べてみたよ。

国内のドメインは、SPF は比較的よく普及しているが、DKIM、DMARC は世界での普及と比べると悲惨な状況にあることがわかった。っていうか前から知ってたけど改めて残念さを再確認した。この前の DNSSEC の調査もそうだし、AAAA レコードの登録状況の調査^(*2)でも下位だし、とにかくこの手のことには日本は後進国だよね。もう少しがんばろうよ。

メールサービス提供事業者様へ。DKIM 署名および、SPF/DKIM/DMARC の検証機能を実装してください。

DNS ホスティングサービス提供事業者様へ。DKIM 公開鍵および DMARC ポリシーを登録するのに必要な “_”(アンダースコア)ではじまる TXT レコードを DNS に登録できるようにしてください。

メールサービスご利用の皆様へ。提供事業者に対応要望を出しましょう。すでに対応しているならば使いましょう。

なお、今回はどの程度メール送信ドメイン認証を宣言しているかどうかを調べただけだけど、国内のいくつかの事業者に実際に届いたメールに対して送信ドメイン認証の判定をした結果をとりまとめたものが総務省のサイトにあるので、そちらも参考にするといいよ。

http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.html#toukei

ところで Mailsploit について

こんな調査をやってたら、メールの送信者を偽装できる Mailsploit なんていう脆弱性が発見されちゃった。内容的にこの件に触れないわけいかないよなぁ。んもー、めんどくさい手間増やしてくれやがって。

まず、メールの From ヘッダは以下のような形式になっている。

From: display-name 

From ヘッダのうち、display-name や localpart の部分を細工することで、メールクライアントに表示される差出人を別のアドレスに偽装できてしまうという脆弱性が Mailsploit。ドメイン部分(example.com) は細工しない。

そして、送信ドメイン認証技術はいずれも display-name や localpart は一切関知しない。SPF はヘッダではなくエンベロープの MAIL FROM が検証対象であり、DKIM は DKIM-Signature ヘッダ内の d= (または i=）タグ、DMARC はヘッダ From を参照するがドメイン部だけで display-name や localpart は見ていない。

つまり、Mailsploit が細工する対象と、送信ドメイン認証技術が検証する対象は異なるので、送信ドメイン認証には一切影響がない。悪意ある人間が Mailsploit の脆弱性を利用して他人のドメインを詐称するメールを送ったとしても、送信ドメイン認証を pass させることはできない。ちゃんと偽装を見破ることができる。

しかしながら、他人のドメインを詐称することなく、正しく自分自身のドメインを名乗ってメールを送れば、当然検証は pass する。このようにして検証を pass させたメールをメールクライアントで表示させるときに、display-name や localpart を細工しておけば実際に検証に pass したドメインとは異なるドメインからのメールかのように見せかけることができる、というのが今回の脆弱性の問題点。

そもそも From ヘッダ（にかぎらずヘッダ全般）は自由に書けて、Mailsploit の脆弱性に頼らずとももっと簡単に詐称できる。そういう意味では、送信ドメインの検証をしていないのであれば、Mailsploit を気にしても仕方がない、といっていいかもしれない。