ページの先頭です

ページ内移動用のリンクです
  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review（IIR）
  5. Vol.23
  6. 2.メッセージングテクノロジー

Internet Infrastructure Review（IIR）Vol.23
2014年5月28日RSS

目次

2.3 メールの技術動向

ここでは、メールに関わる様々な技術動向について解説します。今回は、迷惑メール対策として期待されている送信ドメイン認証技術の導入状況について報告します。また、これらの技術は標準化され、同じ技術が広く使われることによって効果を上げます。その標準化の動向についても補足します。

2.3.1 送信ドメイン認証技術の普及状況

送信ドメイン認証技術は、既存のメール配送の仕組みであるSMTP（※4）に直接影響を与えることなく、導入ができるように作られました。メールを認証するのは、メールの受信側ですが、メールの送信側が送信ドメイン認証技術を導入しているメールのみが認証できます。つまり、メールの送信側と受信側それぞれの判断とタイミングで送信ドメイン認証技術を導入することはできますが、送受信の両方が導入して初めて認証結果を得ることができます。

送信ドメイン認証技術には、メールの送信元のIPアドレスを元に認証するSPF（※5）と、メールの本文から電子署名を作成し、それを検証することによって認証するDKIM（※6）があります。それぞれの技術について、送信側の導入状況を図-4、図-5に示します。これは、IIJの主要なメールサービスで、2014年1月〜3月の間に受信したメール数に対する受信認証結果の割合を調査したものです。

図-4 SPFによる認証結果の割合

図-5 DKIMによる認証結果の割合

メールの送信側としてSPFを導入するには、メールに利用する（あるいは利用しない）ドメインのDNS TXT資源レコードにSPFレコードを宣言（設定）します。一度SPFレコードを設定すれば、そのドメイン名を利用するメールサーバのIPアドレスに変更がなければ、何もしなくて良いのがSPFの大きな利点です。

この利点もあり、SPFの導入率は、図-4をみても分かるとおり、非常に高い割合になっています。送信側でSPFを導入している割合は、認証結果が「none」（認証できなかった）以外の割合となり、今回の調査期間では73.2%でした。認証結果「pass」（47.7%）は、正しく認証されたメールの割合を示します。「hardfail」（2.2%）と「softfail」（21.0%）は、認証が失敗した割合となり、これらはドメインが詐称されたか、メールが転送などにより配送経路が変わって認証できなかったことを示します。

一方DKIMは、送信するメールそれぞれに、メールの本文などから電子署名情報を作成し、それをメールのヘッダに挿入する追加処理が必要になります。そのため、送信用のメールサーバへの新たな機能追加が必要となり、署名を作成するための処理が新たに追加されることで、負荷が高くなる傾向もあるようです。つまり、SPFに比べて送信側での導入が簡単には行えない要因があり、そのため受信側も含めて導入があまり進まない傾向にあると考えられています。しかし、SPFの認証結果で触れたメールの配送経路の変更による認証失敗がほとんど発生しない、という大きな利点があります。また、メール本文の内容から電子署名が作成されるため、途中経路でのメール本文の改ざんも検知できるなど、SPFに比べてより堅牢な送信ドメイン認証技術と言われています。

今回の調査期間で、DKIMの認証結果から見た送信側の導入割合は、11.6%でした。この割合をもっと増やす施策が必要と考えます。

2.3.2 送信ドメイン認証技術の普及の推移

SPFの認証結果の割合の推移を図-6に、DKIMの認証結果の割合の推移を図-7に示します。

図-6 SPFによる認証結果割合の推移

図-7 DKIMによる認証結果割合の推移

SPFは、調査開始（2009年8月）以降、順調に導入割合を伸ばしています。2013年以降はあまり導入割合が伸びていませんが、それでも70%以上と高い導入率を維持しています。この期間、最大で約32.7%導入率が伸びました。DKIMの導入割合はSPFほど急速に増えていませんが、それでも割合は少しずつ増えてはいます。この期間で導入割合は約11.1%増加しました。

Gmailを提供しているGoogle社が、2013年12月に発表し たデータ（※7）によれば、Gmailが受け取ったspam（迷惑メール）でないメールの91.4%がSPFあるいはDKIMで認証可能であった、と報告しています。本レポートで示している送信ドメイン認証の結果割合は、受信できたメール全体を対象にしているので（迷惑メールも含んでいる）、Google社の報告とは、元になったデータの性質が異なっているので、単純には比較できませんが、かなり高い割合でした。

Google社の報告をより詳しく紹介すると、SPFの認証可能だったメールの割合は、89.1%で、DKIMでは76.9%でした。SPFとDKIMの両方が認証できた割合は74.7%ですが、SPFだけ、またはDKIMだけ、というドメインも存在するので、双方の和をとると、全体で91.4%になる、ということのようです。

Google社は、SPFとDKIMの両方の認証結果を利用する、DMARCを推進する企業の一つなので、このような高い導入割合を示し、既に世の中のメールは、DMARCの導入準備が整っている、ということを示していると考えられます。本文中でも、既に8万ドメインが、認証できなかったメールを拒否するポリシーをDMARCで表明しており、このポリシーに従い、毎週数億通のメールを拒否していると報告しています。DMARCでは、現在利用されているメーリングリストの配送方法と相性の悪い部分が仕様として残っているので、DMARCのポリシーとして受信拒否（reject）を宣言するには難しいケースもありますので、注意が必要です。

2.3.2 SPFの標準化動向

SPFは、実験的（Experimental）RFCとして標準化された技術です。現在、このSPFの改訂作業が行われています。そもそもSPFは、同時期（2006年4月）に同じくExperimentalRFCとして公開されたSender ID（※8）との統合を目指して、IETFのMARID WGで検討が重ねられていた技術です。Sender IDの特徴であるPRA（Purported Responsible Address）について、提案元の会社が知的所有権を主張したことなどから統合の議論が不調に終わってしまった、という経緯がありました。

しかし、既にデータを示してきたとおり、SPFが送信ドメイン認証技術として、広く普及していることから、標準化を目指してこれまでの経験も踏まえてまとめよう、ということでIETF spfbis WGが2011年11月から議論を重ねて来ました。SPFは、2014年4月にRFC7208として、標準化への提唱（Standard Track）として公開されました。今回は、このRFC7208と従来のRFC4408との違いについて解説します。

まず、議論の前提として、以下のような見解を示しています。

  • SPFは成功したがSender-IDはそうではない（なのでSender IDの取り込みはしない）
  • SPFの仕様改訂のポイントは、間違いの訂正、利用していない機能の削除、既に広く使われている拡張の追加など
  • SPF自体の拡張や使われている機能の削除はしない

よって、spfbis WGによるIDでは、それほど大きな変更が加えられませんでした。現在のIDで示されている主な変更点は以下です。

  1. SPFレコードは、DNS上のSPF RR type（99）ではなくTXT RR（16）を利用
  2. 認証結果を保存するメールヘッダは、"Received-SPF"と"Authentication-Results"を併用

これ以外については、細かな間違いの修正などです。結局、認証失敗時のメールの取り扱いについてRFCでは指針を示すことはせず、受信側で方針を決めて判断することになりました。比較的複雑な書式を記述できるSPFのマクロ機能は、それほど積極的に使っているドメインは少ないと思いますが、仕様として残すことになりました。

SPFの課題である、メールの転送についても、明確に対処方法は示さず、転送時にRFC5321.From（エンベロープFrom）を書き換えたり、転送先で受け取るようホワイトリスト的な設定をすることなどが示されただけでした。SPFのInternet-Draftは、21版まで改訂されており、実際に変更されたポイントの割にはかなりの時間を要しました。SPFは、送信側の導入が用意であることから普及率も高く、この標準化作業によって、SPFの認証結果の活用が進むことを期待します。

  • （※4）SMTP（Simple Mail Transfer Protocol）、何度か改訂され、最新版はRFC5321として公開されている。
  • （※5）SPF（Sender Policy Framework）、 ExperimentalというカテゴリのRFC4408として公開された後、RFC7208(Standards Track)として改訂された。
  • （※6）DKIM（DomainKeys Identified Mail）、RFC6376として公開後、STD76としてインターネット標準となった。
  • （※7）Internet-wide efforts to fight email phishing are working（http://googleonlinesecurity.blogspot.sg/2013/12/internet-wide-efforts-to-fight-email.htmlblank）。
  • （※8）Sender ID: RFC4406, RFC4407
2.メッセージングテクノロジー

ページの終わりです

ページの先頭へ戻る