ページの先頭です

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

Internet Infrastructure Review（IIR）Vol.27
2015年5月27日発行RSS

目次

2.3 メールの技術動向

ここでは、メールに関わる様々な技術動向について解説します。今回は、先日RFC化されたDMARCと、それを利用するための環境づくり、ドメインレピュテーションやフィードバックを含めたメールエコシステムについて解説します。

2.3.1 DMARCのRFC

DMARC（Domain-based Message Authentication,Reporting, and Conformance）については、これまでその成り立ちやInternet-Draft（以後ID）段階から、その仕様をIIRで説明してきました。2015年3月に、そのDMARCの基本部分はRFC7489として公開（※6）されました。当初、DMARCのIDは、標準化を目指したStandard Trackとして公開され、検討されてきましたが、最終的にはInformational RFCとなりました。IETFのDMARC WrokingGroup（以後WG）の動きを逐次把握していなかったので、どのような理由でInformationalに変わったのかをきちんと把握していませんが、2014年の4月にIDがInformationalに変更されたようです。

これまでも指摘されてきたことですが、DMARCには通常利用できていたいくつかのケースで、認証が失敗する問題があります。こうした問題点が標準化に際して影響した可能性は高く、IETFのDMARC WGでも、引き続き取り組むべき課題として挙げられています。この問題は、DMARCと、DMARCの認証の基盤として利用しているSPF及びDKIMとで、それぞれが認証する送信ドメインが異なっていることが原因となっています。これについては、2012年8月に発行した本レポートVol.16（※7）で既に説明しています。

2.3.2 DMARCの課題とレポーティング

現在IETFのDMARC WGで取り組むべき課題としてチャーターにも挙げられている問題は、メールの再配送（indirect mail flow）です。事例として挙げられているケースは以下のような機能を利用した場合で、メールの便利な使い方としてこれまで広く使われてきたものです。

  • メーリングリストサーバ
  • 自動転送機能
  • なんらかの理由でメッセージを改変するメールサーバ

いずれも、メールの最初の作成者と、そのメールを受け取る最終的な受信者からみた直近の送信者が異なったり、その間に介在する機能がメッセージを改変したりすることが根本的な原因となっています。実際、2014年4月に、米国Yahoo!がDMARCレコードのポリシーを"reject"に変更したため、Yahoo!を利用してメーリングリストに参加していた利用者のメールが、メーリングリストからの配送先でDMARCの認証に失敗し、DMARCレコードのポリシーに従ってreject（受信拒否）する事例が発生しました。一方で、DMARCレコードのポリシーを"reject"と宣言して以降、ドメインを詐称したメールに関連した問い合わせが激減してとても良かった、という米国大手銀行の担当者の話しも聞きました。

DMARCの目的は、こうした送信ドメインを詐称したメールを識別して、届かなくさせることですが、それを実現するためには、DMARCレコードのポリシーを"reject"に設定する必要があります。設定すると、前述の例のように大きな影響を及ぼすこともあります。しかしながら、DMARCにはポリシーを"reject"に設定するための移行的な位置づけとして、"none"や"quarantine"のようなポリシーも用意されています。ドメインの管理者は、こうした影響の少ないポリシーを設定しつつ、認証結果を送信側に報告するレポーティングの機能を活用することができます。ドメイン管理者は、このレポートを参照し、正規のメールが認証に失敗しているケースはないのか、"reject"とポリシーを変えた場合の影響はどの程度あるのか、詐称しているメールはどの程度流通しているのかなどを事前に確認することができます。こうしたレポーティングは、メールの受信側が受信したメールの送信ドメインを認証すると共に、認証が失敗したメールの情報をレポートとして送信ドメイン側へ通知することで実現されます。レポーティングは、受信側にとって新たな負荷となります。しかし、DMARCを普及させるためには、こうしたレポーティング機能を提供する、メール受信側が増えることが必要でしょう。

2.3.3 メール受信側のDMARCの利用

送信側からみれば、DMARCレコードを宣言することで、詐称されたメールが受信側に届かなくなるDMARCの利点は大きいと言えます。では、新たな認証機能の仕組みを追加し、更に認証が失敗した情報を送信側にレポーティングまでする受信側に、何かDMARCの利益があるのでしょうか。

これまで、SPFやDKIMなどの送信ドメイン認証技術は、送信者情報を認証（Authentication）する技術で、迷惑メールかどうかを判断するものではない、と何度か述べてきました。認証された送信ドメインは、詐称されていないことを示すだけですので、それが受け取るべきメールかどうかを判断するためには、認可（Authorization）の手続きが必要になります。メールの世界では、この認可の方法として、認証したドメインを元に、受け取るべきメールかどうかを評価するレピュテーションが必要になる、とずっと言われてきました。DMARCにより、SPF及びDKIMでそれぞれ認証したドメインと、最終的にDMARCとして認証するドメインの仕組みができましたので、ようやく統一した方法でドメインを取り出すことができるようになりました。つまり、いまこそ単一のドメインで、レピュテーションを利用して受け取るべきかどうかを判断する、認可の手続きができるようになった、と言えます。

メールの受信側がDMARCを導入する利点は、送信ドメイン認証によって送信元を明らかにし、その送信元（ドメイン）を評価することによって、評価の低い受け取るべきでない不要なメールの受信を減らせることです。メールの受信側は、不要なメールを受信しないことによって、通常行われる受信したメールに対するいくつかの処理、ウイルスチェックや迷惑メールフィルタの判定処理などを軽減できますし、メッセージスプールに保存しなくてもよいことになります。受信側のユーザにとっても、不要なメールを参照し削除するなどの手間を減らすことができますので、ユーザの満足度を上げることもできます。

2.3.4 ドメインレピュテーション

ドメインレピュテーションという言葉には、まだ明確な定義はありません。これまで受け取るべきでないドメインの集合を、ドメインブラックリストと表現する例はありましたし、その逆に受け取るべきドメインとしてホワイトリストと表現することもありました。一般的にドメインレピュテーションは、こうした悪と善の2値（いずれのドメインリストにも含まれていないものも考慮すれば3値）ではなく、その中間的な割合も含めて数値で示したもの、と考えられています。

例えば、これまで迷惑メールを送信したかどうかの明確な実績データのないドメインであっても、そのドメインが作成されてからの経過日数や、ドメインの管理元の素性などの情報から機械的に判断して、ある程度の傾向を数値の幅で表現することは可能でしょう。とはいえ、ドメインレピュテーションの精度を上げるためには、実際に受信したメールの認証結果と、受信者による迷惑メールかどうか（あるいは必要か不要か）の判断の情報がとても有益です。最近、DMARCレコードのレポーティングの宛先として、当該のドメイン名以外を指定しているレコードを見かけます。こうしたレポーティング先は、レポーティングメールを集約して、更に有益なレポートとしてまとめて提供する代わりに、DMARCの認証が失敗した事例を集めて、自社のドメインレピュテーションのデータとしても活用しているようです。このように、ドメインを管理する側とレポーティングを集約する事業者の間には、相互に有益な関係を構築することができますので、こうしたレポート分析とレピュテーションデータを提供する事業者が増えてくるかもしれません。

既に日本でも、受信者が受け取ったメールを迷惑メールとして申告するような仕組みの事例があります。例えば、一般財団法人日本データ通信協会の迷惑メール相談センターでは、メールの転送やWebからの入力によって、迷惑メールの情報を受け付けています。迷惑メール相談センターでは、こうした情報を元に違反行為があった場合に、総務省に報告するなどの処置を行っています。総務省では、集まった情報を元に送信者に対して警告を行ったり、行政措置を実施します（※8）。

迷惑メールとその明確な送信者情報（ドメイン）を、こうした仕組みで集めることができれば、よりドメインレピュテーションの精度を向上させることができます。これまで迷惑メールは、受信側に一方的に送りつけられ、受信側はそれらを個々の努力でなるべく排除しようとしてきました。しかし、DMARCが普及し、迷惑メールの送信者（ドメイン）の情報が広範囲に集約できて、ドメインレピュテーションがそのフィードバックとして提供できるようになれば、より積極的な形で不要な迷惑メールを排除することができるようになるかもしれません。

2.3.5 メールのエコシステム

図-2は、送信ドメイン認証を含めたDMARC認証、認証したドメインを評価するドメインレピュテーション、受け取ったメールを申告するフィードバックの関係を示した全体像（フレームワーク）です。これは、これまで述べてきた迷惑メール対策を含めた、より良いメールの利用環境を実現するために、それぞれの役割と持続可能な仕組みを含めたエコシステムとなっています。それぞの役割について簡単に述べます。

図-2 メールのエコシステム

まず、メールの受信時には、SPF及びDKIM、DMARCでドメイン認証を行います。この時点で、例えばもろもろの問題点が技術的に解決できて、DMARCの認証が失敗し送信側のポリシーが"reject"であった場合は、受け取りを拒否できるかもしれません（あくまで技術的な観点として）。次に、受信して認証したドメインを、ドメインレピュテーションを利用して評価します。認証したドメインがあらかじめホワイトリストに登録されている場合には、状況によってはその後の迷惑メールフィルタを通さずに、メール受信者に届けることができるようになります。迷惑メールフィルタの難しさは、迷惑メールの判定を難しくするような巧妙な迷惑メールをいかに排除するかですが、その一方で、受け取るべき通常のメールを迷惑メールと判断する誤判定（false positive）が発生しないような工夫が求められます。こうしたメールの内容からだけでは判断が難しいメールも、認証したドメイン名がホワイトリストに含まれていれば、容易に受信者に届けることができるようになります。

また、認証したドメインが明らかに迷惑メールを送るドメインであることが分かれば、迷惑メールフィルタを経由するまでもなく、簡単に排除できるようになります。このように、事前に判断できるケースが増えれば、迷惑メールフィルタの設備コストも抑えることができるようになるかもしれません。

以前、メール送信時にSMTP認証するIDとパスワードが悪用されて、正規のメール送信サーバが踏み台にされているケースがあることを報告しました。つまり、正当なメール配信の経路を通っているわけですから、このフレームワークであっても、そのメールの送信側がホワイトリストに登録されていれば、迷惑メールであってもメールが届いてしまうことになってしまいます。こうした場合、受信側がドメインレピュテーションを管理している送信側に、誤判定メールとして申告（フィードバック）することができれば、送信サーバが踏み台にされていることが検知できるようになります。送信側の事業者は、メール送信時のSMTP認証時の記録を参照すれば、そのメールが実際にどこから送信されているのか、物理的な送信者は誰であるのかを調べることができます。例えば、そのPCがマルウェアに感染しているかもしれませんし、その契約者が明示的に迷惑メールを送信しているかもしれませんが、いずれにしてもメール送信元を確認することができますので、対応が取れるようになります。

  1. （※6）Domain-based Message Authentication, Reporting, and Conformance（DMARC）（https://datatracker.ietf.org/doc/rfc7489/blank）。
  2. （※7）本レポートのVol.16（http://www.iij.ad.jp/dev/report/iir/016.htmlblank）の「メッセージングテクノロジー『送信ドメイン認証技術の普及と認証する識別子』」。
  3. （※8）総務省：迷惑メール対策（http://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/m_mail.htmlblank）。
2.メッセージングテクノロジー

ページの終わりです

ページの先頭へ戻る