DKIM.JP

　　送信ドメイン認証『DKIM』のススメ

リンク 連絡先 導入支援 FAQ 技術情報 一般情報

「なりすましメール」の脅威

フィッシング詐欺や迷惑メールのほとんどは「なりすまし」によって送られています。現在のメール送信技術では、送信元とされるFrom:アドレスを簡単に詐称することができるからです。これらの悪意のメールが、その身元を隠そうと他人または架空のアドレスを詐称するのは当然かも知れませんが、「なりすまし」にメールアドレスやドメインを勝手に使われる側は堪ったものではありません。一般ユーザは詐称を見抜けませんから、結果的に全く身に覚えのないことで信用を貶めることになるのです。

想像してみて下さい。もしあなたがメールマガジンを発行していて、そのユーザーにあなたのアドレスを詐称した迷惑メールが届いたら？もしあなたがネットショップを運営していて、あなたのアドレスから（実際にはそうではなくても、ユーザーにはそう見える）フィッシング詐欺メールが送られたとしたら？こんなことはすでに現実に起きているのです。

「なりすまし」を防ぐ送信ドメイン認証技術

このような「なりすましメール」を根本的に解決する技術として開発されたのが「送信ドメイン認証」技術です。「送信ドメイン認証」技術とは、正規のドメインの所有者からのメールを識別する技術のことです。これには大きく分けると送信元IPアドレスを使う技術と、電子署名を使う技術があり、前者にはSPF(Sender Policy Framework)とSender ID、後者にはDomainKeysとDKIM(DomainKeys Identified Mail)があります。まずはこれらの概要から説明しましょう。

Sender IDとSPF

SPFとSender IDの基本的な仕組みは同じです。送信元ドメインのDNSから正規の送信元ホスト情報を取得し、それと実際の送信元IPアドレスを照合して検証します。前者はマイクロソフトによって提唱された技術、後者はPobox.comのMeng Wong氏が提唱した技術で、その違いは送信元のドメインをどう認識するかにあります。SPFはシンプルにエンベロープに書かれたFromアドレス、つまり最初のSMTP通信でMAIL FROMの引数として与えられた値からドメインを認識し、そのDNSにSPFレコードを取りに行きます。（SPFレコードというのは、そのドメインからのメールの送信元となりうるサーバーの情報です。）これに対し、Sender IDではヘッダーに記載された情報からPRAという「（ヘッダーを見る限りこの送信に最終的に）責任があると読み取れるアドレス」（Purported Responsible Address）を割り出し、そのドメインのDNSからSPFレコードを取り出します。取得したSPFレコードのサーバー名と実際の送信元IPアドレスを照合し、一致すれば認証するという仕組みです。PRAはヘッダーのResent-Sender、Resent-From、Sender、Fromを順番に走査して抽出しますが、その詳細はRFC4407を参照してください。また、SPFとSender IDの違いについてはSPFプロジェクトのページで詳しく説明されているのでそちらもご覧ください。

・Sender IDとSPFの違いについての解説　http://www.openspf.org/SPF_vs_Sender_ID

・PRAを割り出すアルゴリズムが書かれているRFC4407　http://www.ietf.org/rfc/rfc4407.txt

DomainKeysとDKIM

DomainKeysとDKIMも基本的には同じ仕組みのドメイン認証です。どちらもあらかじめ公開鍵をDNSに設置し、メールヘッダーに電子署名を付与して送信します。受け取ったメールサーバは、基本的にはその電子署名の引数からドメインを取り出し、DNSに公開鍵を問い合わせ、取得した公開鍵で電子署名を検証、認証ができればメールを受け取ります。認証に失敗した場合は、SSP(Site Signing Policy)という運用方針を記述した情報を取りに行き、それに従って処理します。実はDomainKeysとDKIMの最大の違いは、このSSPに関するものなのですが、それについては後述します。ちなみにDKIMはYahoo!、Cisco、PGP、Sendmailが共同提案し、2007年5月にRFC4871として承認されました。DKIMはDomainKeysの後継技術とされており、互いに干渉しないので並行して運用できるものの互換性はなく、将来的には全てDKIMに移行するでしょう。

・DKIMの仕様について書かれたRFC4871　http://www.ietf.org/rfc/rfc4871.txt



『DKIM』に対応すべき理由

本サイトは『DKIM』の啓蒙を主旨としています。それは今後『DKIM』の普及が電子メールの健全な利用に不可欠になると考えているからです。しかし『DKIM』が万能なわけではなく、それだけに対応しておけば完璧というのではありません。あくまでも「合わせ技一本」の重要な「技あり技術」、つまり他の技術と合わせても必ず押さえておくべき技術として、他の技術の問題点も指摘しつつ説明したいと思います。

結論として、送信側のドメイン認証はDKIMに対応しつつSPFとSender IDの対応 （この二つは上述の通り単にDNSにSPFレコードを書き込むだけと簡単ですから）、 受信の際に検証できるドメイン認証としてDKIM、DomainKeys、SPF、Sender ID 全てに対応するのがよいでしょう。

送信ドメイン認証の可能性と対応の意義

送信ドメイン認証技術は現在問題になっている「なりすまし」によるスパムメールやフィッシング詐欺メールを根本的に解決し、さらに「なりすまし」以外のスパムメールやフィッシング詐欺メールの排除にも大きく貢献する可能性を秘めています。それには二つのステージを通過する必要があります。一つはこの技術が十分に普及し、送信側と受信側とも多くのドメインが対応するステージ。もう一つは対応済みとそうでないドメインの二極化が進み、ドメインの選別に入るステージ。



最初のステージは「なりすましメール」を根本的に解決するステージです。送信ドメイン認証技術はどれも、送信側と受信側の双方が対応しないと効果が限定的であるため、積極的な対応が望まれます。普及が進めば進むほど効果が大きくなるため、ある時点を過ぎると一気に広がるのではないかと思います。そのある時点というのが、次のステージで起こることとの流れが見えた時点でということかもしれません。



次のステージのドメインの選別という考えは、送信ドメイン認証技術は「なりすまし」による迷惑メールは防ぐことはできても、ドメインを詐称しない迷惑メールに対しては無力であるということから来ています。このため、スパムメールやフィッシング詐欺メールの根絶には、最終的にレピュテーションによるドメインの選別が必要と考えられています。これはスパム履歴や送信ドメイン認証への対応状況などからドメインの評価を行い、その情報を共有することによってスパム対策に役立てようという考えです。やり方は違いますが、この情報の共有によるスパム対策という考えをすでに実践し、高い効果を上げている例があります。



Cloudmark社のAuthorityというスパムフィルターがまさにそれで、世界中の120万を超えるユーザーからのサンプル提供でスパムエンジンを更新し、圧倒的な検知率をたたき出しています。また、まだドメインレピュテーションという形ではありませんが、フリーのスパムフィルターとして非常に普及しているApacheのSpamAssassinが、SPFチェックの結果を判定の要素に加えられるようになりました。このように送信ドメイン認証の検証結果や対応状況がいずれ重要な情報として共有される時が来るでしょう。その時に悪いレピュテーションとならないよう、早めの対応が望まれます。



ただ、そればかりを気にして対応するよりも、もっとポジティブに考えてみてはいかがでしょう？送信ドメイン認証に対応するということは、その普及の一翼を担うことによりインターネット全体に貢献できます。このページもそのためにあるわけで、何とか技術の啓蒙と普及を後押しできるよう願っています。また、こうした技術にいち早く対応することにより、先進性のアピールにもなります。DKIM電子署名のついたあなたからのメールを受け取った人は、それだけ真剣にこの問題に取り組んでいることと、それだけの技術力があることを認識するでしょう。簡単に言ってしまうと、それだけきちんとした組織であるということをアピールする意義は大きいと思います。



仮に現在送信ドメイン認証に対応していなくても、このページに辿り着いたということはご興味をいただいたということでしょう。せっかくですから対応をご検討ください。



・導入支援はこちら→http://www.dkim.jp/helpservice.html









© 2008 株式会社インフォマニア. Template design by Arcsin