Security&Trust トレンド解説

Sender IDはスパム対策の切り札となるか!?

鈴木淳也(Junya Suzuki)
2004/9/25


  インターネットの利用が進むとともに、「スパムメール」あるいは「迷惑メール」と呼ばれるジャンクメールの問題が大きくなってきている。スパムメールの数はここ数年で急上昇し、あるデータによれば、インターネット上を流れるメールの7割近くがスパムメールだともいわれている。スパムメールの存在は単に迷惑なだけでなく、ビジネス場面における業務効率を落とし、限られた資源であるインターネットの帯域を浪費することにもつながっている。ITベンダやISP各社はこれら問題に対抗すべく、「アンチスパム」を念頭に各種製品やソリューションの開発に日々労力を費やしている。

  そうした中、現在IETF(Internet Engineering Task Force)のMARIDワーキンググループ(MTA Authorization Records in DNS WG)で標準化されている「Sender ID」と呼ばれる技術に注目が集まっている。Sender IDとは、米Pobox.comの共同設立者で同社CTOのMeng Wong氏が提案している「Sender Policy Framework(SPF)」と、米Microsoftが提案している「Caller ID for E-mail」という技術をミックスさせたスパム防止技術の1つだ。

  Sender IDは発信者がメール送信に利用しているメールサーバを特定し、送信元アドレス(「From:」フィールドの値)で示されるドメインと同じ場所から送信されているかどうかを確認するものだ。これにより受信側のメールサーバは、届いたメールがスパムメールかどうかを判断するのが容易になる。例えば、メール転送制限をかけていないセキュリティの甘いメールサーバを踏み台に、「〜@yahoo.com」といったドメイン名にメールアドレスを偽装して大量にスパムをばらまいていたスパム業者は、今後こういった偽装が難しくなる。こういったドメイン偽装のことを「ドメインスプーフィング(Domain Spoofing)」と呼ぶ。

 Sender IDでできること、できないこと

  Sender IDの仕組みは比較的シンプルだ(図1)。SPF Recordと呼ばれるテキストファイル一覧を用意し、そこに「あるメールアドレス(ドメイン名)の送信元として適切なメールサーバのIPアドレス一覧」を書き込んでおく。メールの送信先サーバはメールを受け取った段階で、そのメールに書かれた送信元アドレスのドメイン名に対してDNS経由でSPF Recordを参照しにいく。もし当該のメールを送信してきたサーバのIPアドレスがSPF Record内に記載されていれば、そのメールはSender IDによって認証されたメールとなる。一方で、もしSPF Record内に記載がなければ、そのメールは認証されないメールと判断される。認証されていないメールは、送信元を偽っている可能性があり、これを受信前にスパムメールとして一括処理することも可能だ。このSPFの仕組みのメリットは、メールが最終目的地のメールサーバへと到達していない段階で認証を行い、場合によってはそれを排除することができる点である。

図1 Sender IDの仕組み拡大画像

  SPF自体はシンプルな仕組みながら、送信元詐称を検出するには非常に効果が高い。そしてMicrosoftが提案するCaller ID for E-mailでは、各種の機能追加でその信頼性をさらにアップさせようとしている。例えば、従来のSPF Recordではテキストベースで情報を格納していたが、Caller ID for E-mailではXMLベースでの格納となっており、さらに複雑な処理が可能となっている。テキスト版SPF Recordとの下位互換性も持つため、既存システムをそのまま継続して利用することも可能だ。

 また、SPFでは「エンベロープ」【注1】を処理するレベルで認証を行っていたが、Caller ID for E-mailではメール本体にPRA(Purported Responsible Address)と呼ばれる情報をメール本体に書き込むことができる。PRAには、直前にメール中継を行ったMTAなどの情報が格納される。これにより、さらに細かい検証が可能である。

【注1】
メール本体とエンベロープの関係を理解するには、下記の記事を参照してほしい。

連載:インターネット・プロトコル詳説(5)
SMTP(Simple Mail Transfer Protocol)〜前編
http://www.atmarkit.co.jp/fnetwork/rensai/netpro05/netpro01.html

 Sender ID技術により、送られてきたメールのメールアドレスと送信元サーバが一致するかが検証され、一致していた場合は認証されたメールとして、それ以外は未認証メールとして処理される。受け取り手がその情報を知ることができれば、未認証メールをスパムメールの疑いがあるとしてあらかじめ分けて処理することが可能になる。これにより実現されるのは、次のことだ。

Sender IDでできること

  • メール送信元を偽装するスパム業者のメールを受信前に見分けられる
  • 受信前検証により、早期にスパムを排除してネットワークリソースの減少を避けられる

 スパム業者がメールを偽装するケースは次のようなものだ。例えば、メールの送信元をブランド的に認知されたドメイン名(例えば「microsoft.com」)にし、IDやパスワードなどの登録情報の再登録を促すメールを装って送信し、個人情報を盗み出そうとする「フィッシング詐欺」と呼ばれる手口が挙げられる。また、受信側のスパムメールフィルタに引っ掛からないように、「aol.com」のようなユーザーが普通に使うアドレスを送信元として(ドメインスプーフィング)、それとは全然関係のないサーバ経由でメールを大量送信するケースもある。Sender IDを使えばこれらの手口に対して防御が可能になる。

  しかしながら、Sender IDも万能ではない。

Sender IDでできないこと

  • ドメインを偽装しないスパム業者のメールは排除できない
  • SPFに対応していないドメインから送信されるメールは、すべて未認証になる
  • メールに記載された送信元アドレス以外のサーバから送信したメールが未認証になる

 例えばスパム業者が正規に独自のドメイン名を取得し、そこからメールを送信した場合、そのメールはSender IDのルールにはのっとっているため、スパムメールとして一律に排除することはできない。その場合、スパム送信元となるドメイン名をリスト化し、ブラックリストとして排除対象に登録しておく必要が出てくる。だがスパム業者が新たにドメインを取得すれば、そのリストも意味がなくなる。Sender IDが広がることで、こうした“捨てドメイン”の利用が増加し、これを助ける業者なども登場してくることが予想されるだろう。つまり、イタチゴッコの状態となるのだ。

 また、認証できないメールはSender IDで処理することが不可能なため、ある意味ですべて未認証として処理されると考えられる。例えば、旅先などでメールを送受信する場合、メール送信にいつものSMTPサーバが使えず、現地のISPが提供するメールサーバを利用するケースがある。この場合、いつもと同じメールアドレスをそのまま利用しようとすると、結果的に送信元アドレスを偽装することになるだろう。このメールも未認証扱いとなるはずだ。

 Sender IDで可能なのは、あくまで送信元を偽装しているかどうかの検証であり、それ以上の検証、例えば内容がスパムかどうかを判断するには、別のアプリケーションが必要になる。つまりスパム対策において万能な手段なのではなく、あくまでスパム送信のいくつかの手段を封じるものであることに注意したい。

1/2


Index
Sender IDはスパム対策の切り札となるか!?
Page1
Sender IDでできること、できないこと
  Page2
Sender IDの利用に「待った」をかけるオープンソースコミュニティ
ライセンス形態維持にこだわるMicrosoft
Sender IDの今後


Security&Trust記事一覧


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間