送信ドメイン認証とは?

送信ドメイン認証とは、送信者のアドレスが正規なものであることを証明する技術です。正確に言うと、そのメールアドレスのドメインを見て、それがが正規なサーバーから発信されているか否かを検証します。これは多くのスパムが送信者を偽って送りつけられるため、こうした「なりすまし」を排除すればスパムが減るという考えに基づいて開発された技術です。今後、スパムの根本的な解決のために、この技術が普及することが期待されており、ここではその概要を説明します。

スパムは「なりすまし」ばかり

なりすましメールの仕組みまず、送信ドメイン技術の重要性を理解するために、いかに「なりすまし」が簡単かを理解することが必要です。フィッシング詐欺や迷惑メールのほとんどは「なりすまし」によって送られています。現在のメール送信技術では、送信元とされるFrom:アドレスを簡単に詐称することができるからです。試しに、自分のメールソフトの自アドレスの設定を、誰か他の人のアドレスに変えて、自分に送ってみてください。受け取ったメールは、まるでその人から送られたように見えるでしょう。一見して他人と見間違うような「なりすまし」行為は、このように実に簡単なのです。

ですから、スパムやフィッシング詐欺メールの送信元となっているアドレスは、ほとんど全く関係のない他人か、存在もしないアドレスからだと思って間違いありません。実際、@yahoo.co.jpの存在もしないアドレスから大量に送られている例をご覧になったことがあるでしょう。ですから、腹立たしい話ですが、「もう送るな!」と返信しても無駄です。そこで、このようなメールを将来的には排除する仕組みを作ろうと開発されたのが送信ドメイン認証技術です。

送信ドメイン認証の種類

送信ドメイン認証の技術は、大きく二種類に分けられます。一つは送信元IPアドレスを根拠に、正規のサーバーから送られたかどうかを検証する技術。もう一つは、送られたメールの中に電子署名を挿入し、その正当性を検証する技術。前者にはSPFSender IDという二つの技術があり、後者にはDomainKeysDKIMの二つがあります。今後普及して行くべき最新の技術はDKIMですが、その他の技術についても、概要、問題点などを含めて説明します。

  • SPF(Sender Policy Framework)
  • Sender ID
  • DomainKeys
  • DKIM(DomainKeys Identified Mail)

SPFとSender ID

SPFとSenderIDの仕組みSPFとSender IDの基本的な仕組みは同じです。送信元アドレスのドメインからDNSを引き、SPFレコードと呼ばれる情報から正規の送信元IPアドレスを調べます。それと、実際の送信元IPアドレスを照合するのです。両者の違いは、送られたメールのどこを見て送信元アドレスを特定するか、です。

SPFは単純にエンベロープに書かれたFromアドレス、つまり最初のSMTP通信でMAIL FROMの引数として与えられた値からドメインを認識し、そのDNSにSPFレコードを取りに行きます。これに対してSender IDでは、ヘッダーに記載された情報からPRAという「(ヘッダーを見る限り)この送信に最終的に責任があると読み取れるアドレス」(Purported Responsible Address)を割り出し、そのドメインのDNSからSPFレコードを取り出します。PRAはヘッダーのResent-Sender、Resent-From、Sender、Fromを順番に走査して抽出しますが、その詳細はRFC4407を参照してください。また、SPFとSender IDの違いについてはSPFプロジェクトのページで詳しく説明されているのでそちらもご覧ください

DKIMとDomainKeys

DKIMとDomainKeysの仕組みDKIMとDomainKeysも基本的には同じ仕組みのドメイン認証技術です。どちらもあらかじめ公開鍵をDNSサーバーに設置し、メールヘッダーに電子署名を付与して送信します。受け取ったメールサーバは、その電子署名の引数からドメインを取り出し、DNSに公開鍵を問い合わせ、取得した公開鍵を使って電子署名を検証します。

両者の違いは、検証しても認証に失敗した場合や、電子署名そのものがなかった場合の処理の方法です。DomainKeysでは、認証に失敗したり、電子署名がない場合、何もせずに受け取る仕様になっています。スパムに電子署名がついているはずもなく、実質的にスパムに対しては何もできません。

DomainKeysの問題点例えば、正規のYahoo!メールユーザーからのメールにははDomainKeysの電子署名がついているので、認証することができます。ところが、Yahoo!メールユーザーを詐称したスパムにはDomainKeysの電子署名がついていないので、認証できず、そのまま受け取ることになります。ですから、DomainKeysの仕様では、正規のメールが正規であるということがわかっても、そうでないものを排除する効果としては極めて限定的です。だから、それを補うDomainKeysの後継技術として、DKIMの仕様が策定されていったというわけです。DKIMはYahoo!、Cisco、PGP、Sendmailが共同提案し、2007年5月にRFC4871として承認されました。

DKIMへの対応

DKIMにおけるSSPの役割DomainKeysの後継技術であるDKIMは、電子署名のないメール、または電子署名に問題のあるメールを扱う手順を明確にSSP(Sender Signing Practice)に定義します。SSPというのは、DKIM検証の結果、そのメールをどう扱って欲しいかを記述した情報で、認証に失敗したり電子署名がない場合、メールを破棄するように指示することも可能です。その詳細はIETFのドラフト(ドキュメント草稿)に以下のように記述されています。重要なところなので和訳して引用します。

電子署名がない場合、Verifier(認証者)はRFC2822に定義されるところのFrom:アドレスに従い、そのドメインからのメールが署名されている「はず」かどうか、またどんな署名なのかを判定しなければ(MUST)ならない。特に、送信される全てのメールが署名されている「はず」なのかどうかの情報は重要である。それがなければ、電子署名のないメールも本物である可能性を残すことになり、せっかく DKIMの電子署名をしても効果は限定的になるからだ。この判定はSSPチェックにより行う。

少し分かりにくいかもしれないので簡単に説明すると、要するにDKIMでは電子署名がないメールに対し、そのFrom:アドレスのドメインのDNSから SSP(Sender Signing Practice)を参照しなければならない(MUST)ということです。その結果、もし全てのメールに署名しているドメインであることがわかれば、それ以外は偽装であるという判定ができるという仕組みです。これにより、DKIMに対応すれば自ドメインへのなりすましを排除できるようになるわけです。したがって、今後はDKIMに対応していくことは必須になってくるでしょう。

送信ドメイン認証の意義

各サーバー管理者が送信ドメイン認証の導入を進めることは非常に重要です。何故なら、送信ドメイン認証という技術は、送信側、受信側双方が対応しなければ完全な効果は得られないからです。比較的簡単な、SPFとSender IDの送信側の対応だけを済ませているところもありますが、それを認証する受信側の対応はまだまだです。両方同時に対応するサーバーが増えて行かないと、ネットワーク全体でスパムを排除するまでには至りません。、単にスパムをフィルタリングするだけのスパム対策から、根本的なスパム対策へ一歩進めるためにも、送信ドメイン認証への対応は重要になってくると思います。