IAjapanロゴ
有害情報対策ポータルサイト
−迷惑メール対策編−
■ トップ > メール管理者の皆様へ > スパム対策の取り組みにおける課題
サイト紹介 | 新着情報 | 一般利用者の皆様へ | メール管理者の皆様へ | 活動・関連情報
スパム対策の取り組みにおける課題
・スパム対策の取り組みにおける課題
・スパムの性質
・電子メールのアーキテクチャ
・スパムのアーキテクチャ
・スパムをコントロールするための実践的取り組み
・責任確認
・認証標準
・協力のサポート
・謝辞
■ 責任確認

エージェント評価では、問題のある電子メールについて特定のエンティティ(エージェント)の責任を確認することを目指します。コンテントに対する責任、またはMTSにメッセージを入れた責任を持つエージェントはどれか、また、それらは信頼できると評価されたのか、それとも問題ありと評価されたのか、などです。

責任確認可能なエンティティには2つの大きな分類があります。

コンテント・エージェントは、作成者(RFC 2822のFrom)および、RFC 2822のSenderフィールドに指定されている、個々のメッセージを送信する責任者から成ります。メッセージのコンテント・エージェントが有効と確認されたら、コンテントはおそらくそのエージェントの意図を反映しています。つまり、他のエンティティがコンテントに変更を加えた可能性が低いわけです。Notification Handlerアドレス(RFC 2821のMailFrom)は、SMTPプロトコルの中で登場しますが、送り手のエージェントに関連付けられているので、しばしば分析には有効と考えられています。残念ながら、このアドレスは多くの場合、Fromフィールドの作成者およびSenderフィールドの送信エージェントと明確な関係がないので、これをフィルタ処理に使用するのは問題かもしれません。ただしスパム発信者はしばしば、大量の配信の失敗を別のところに向けるために、偽のHandling Noticesアドレスを使用します。

運用エージェントはMTAまたは基本的なインターネット・アクセス・サービスを提供します。これらはしばしば、そのシステムが生み出す大量のトラフィックによる影響について責任を負います。これらのエージェントは、コンテントを作成しませんが、顧客に対して厳しい規則を適用し、トラフィックの中から違反のパターンを検出することは可能です。こうした運用者に対して推奨される[15]に示すようなやり方は、いくらかコンセンサスが得られ始めています。しかし、もっと必要です。

エージェントの評価は事前対応型または事後対応型があります。

  • 「認定」は、送信者による事前の登録を指します。送信者は、品質保証のコミットメント(約束)を引き出す登録先と協調します。したがって、送信者の信頼は、認定を行う側の信頼を継承します。
  • 「評判」は、送信者のこれまでの送信に対する事後の評価を指します。これについては、独立の第三者が送信者の履歴を評価します。

有効な責任所在を確立するために組み合わされる機能としては次があります。

  • 識別:アイデンティティ・ラベルがエンティティに対する一意の参照となります。
  • 認証:アイデンティティ・ラベルの使用の可否を確認します。
  • 許可:アイデンティティに対応するユーザが特定の機能を実行する権限を持っているかどうかを判定します。
  • 評価:許可を与えている機関または検証の対象となるエンティティ自身の信頼性または「品質」についての分析を取得します。

残念ながら、表1に示すように、電子メールの作成と伝送には多くのアイデンティティがかかわっています。

●表1 インターネット・メールのアイデンティティに対応する役割

タイプ
割り当て元
割り当て対象
MTA IPホスト・アドレス ネットワークレベル・サービス SMTPクライアント
EHLOドメイン名 RFC 2821 SMTP コマンド SMTPクライアント
MTAプロバイダのIPネットワーク・アドレス ネットワークレベル・サービス SMTPクライアントのサイト
Mail-Fromメール・アドレス RFC 2821 SMTPコマンド Handling notices
Fromメール・アドレス RFC 2822ヘッダ・フィールド 作成者
Senderメール・アドレス RFC 2822ヘッダ・フィールド 送信エージェント
受信ドメイン名 RFC 2822ヘッダ・フィールド 中継MTAサイト


SMTPクライアントは、SMTPサーバがメッセージを受け取るよう求められるのに対し、直前の中継点(ホップ)の運営者のエージェントです。電子メール運営者は、電子メール・サービスをホストしているIPアクセス・ネットワークの運営者と異なる場合があるので、使用するアイデンティティが異なることがあります。これは表1において興味深い点を浮き彫りにします。すなわち、電子メールの処理にかかわるアイデンティティのほとんどは、「送信者」と呼ぶことができるという点です。このため、この用語はスパム対策の議論においてはほとんど意味がなくなっています。

アイデンティティのリストはデータベースに明示的に作成されるため、リストに含まれないアイデンティティが数多く存在したり、リストが不正確だったりする可能性はありますが、誤った陽性判定をほとんど起こさないことが可能です。それでも、アイデンティティに基づくフィルタリングには大きな課題がいくつかあります。

  • どのアイデンティティを使用するべきか、また、それらはスパム送信の行動にどのように関係するか。表1の選択肢は限られていることに注目してください。また、作成者は不良コンテントを作成できますが、コンテントのRFC 2822 Fromフィールドに記載されているアイデンティティは、たとえそのフィールドが有効と確認されていたとしても、実際の作成者ではないかもしれません。メッセージは、乗っ取られたコンピュータから発信され、コンピュータの所有者の知らないうちに、そのコンピュータに関連付けられているアイデンティティが使われている可能性があるのです。また、メール送信ネットワークの運営者がコンテントの作成に一切かかわっていないとしても、集合的なトラフィックの問題については運営者に責任を負わせることは理にかなっているかもしれません。
  • アイデンティティの有効性をどう確認(認証)するか。どのエンティティが有効性の確認を行うのか。どう信頼を確立するのか。有効性確認の仕組み自体がだまされることはないか。
  • 特定のアイデンティティがスパム送信者であるか否かをどのように判定するのか。アイデンティティの品質を保証するのはどのエンティティか。また、保証を行うエンティティはどのように信頼を確立するのか。

 


[15] Hutzler, C., Crocker, D., Resnick, P., Sanderson, R., and E. Allman, “Email Submission: Access and Accountability,” Internet-Draft, draft-hutzlerspamops-05, October 2005.

《PREV》  
《NEXT》
IAjapanについて | 連絡先 | リンク・転載・引用・ロゴ使用について | プライバシーポリシー
 (c) 2001-2009 Internet Association Japan