スパムが簡単に解決できる問題だと信じたい誘惑に駆られますが、歴史はわれわれに慎重であるように教えてくれています。http://craphound.com/spamsolutions.txt にあるウェブ・ページは、単純すぎる対策に対して、一般的な弱点のチェックリストを用意することで対策の有効性に挑むという不遜なアプローチをとっています。奇をてらっているように思えますが、このチェックリストは意外にも、各種対策案の迅速なスクリーニングに役立つのです。

スパム・コントロールの最も一般的な仕組みは局所的な仕組み、すなわち「フィルタ」です。［14］ メールを、条件に応じて通過させるところからこのように呼ばれています。フィルタは一般に受信者のネットワーク内（または管理ドメイン内。後述参照）で使用されます。しかし、これは経路上の、特にMSAを含め、任意の場所に置けます。受信側にあるフィルタは、インターネット上のスパムのトラフィックは減らせません。送信側にあれば可能です。フィルタは、疑いのあるメッセージの扱い方についていくつかの選択肢を持っています。次のことができます。

• メッセージに特別な注記を追加する
• 特別な格納場所に移す
• 伝送セッション中に受信を拒否してHandling Notification（RFC 2821 MailFrom）アドレスまたはクライアントSMTPに返す
• 単純に削除する
• SMTP伝送の速度を抑制するために「トラフィック・シェーピング」を適用してゆっくり受信する
  

難しいのは、フィルタがどのような基準を使用するべきかという問題です。その難しい答えは、「たくさん」です。広い範囲の変わり続ける多用な判断基準をサポートする必要性から、フィルタ処理エンジンは、スパムの検出と処理を行うモジュールのための拡張可能なプラットフォームへと進化しました。フィルタ処理のアルゴリズムの組み合わせと複雑さがますます高度になるにつれて、それらに伴うオーバーヘッドも大幅に増えてきました。

フィルタ技術は３つの基本的な基準に分類できますが、それぞれに複雑です。

• コンテント分析。語彙のベイズ統計分析とコンテントのハッシュ処理による大量複製の検出。
• 発信元エージェント評価。許可（ホワイトリスト）または拒否（ブラックリスト）をします。
• トラフィック分析。同じ作成者アドレスまたはIPホスト・アドレスからメッセージが送られてくる頻度など。
  

コンテント分析は常に部分的成功（そして部分的失敗）の問題となります。コンテント分析は通常は統計的で、語彙の基準を確立するために、学習用メッセージのデータベースに頼ります。スパム発信者は、最新の分析技術を迂回するテクニックを常に開発しています。さらに、同じ電子メール・サービスを利用する受信者でも、受け取りを許容するコンテントの統計パターンがそれぞれに大幅に異なることも考えられます。そのため、サービス・プロバイダによる粒度の高いフィルタ処理が課題となります。

個々のメッセージまたは集合的なトラフィックの流れを評価するこれらのツールは、一時的には高い有効性を持つことは明らかです。しかし、強化を続けたとしても長期的に効果のある道具にはなれません。とりわけ、スパムをその発生元で減らすことについては有効性がほとんど、あるいはまったくありません。こうした後付の分析ツールには、２つの本来的な欠陥があります。どちらの欠陥も、信頼できる正確で客観的なルールではなく、経験的なルールを使用することに関係します。１つめの欠陥は、「誤った陽性判定」です。これは、正当なメールが誤ってスパムとして判定されることを指します。たとえば、業務上の重要なやり取りが届かず、ジャンク・メールとして分類されるなど考えられます。この問題が生じるおそらく最もたちの悪い例としては、スパム発信者が、よく知られた正当な企業を装ってメールを送信するという例があります。これは「フィッシング」と呼ばれ、当該アドレスを持つすべてのメールが疑わしくなり、正当に送信された重要なメールが届かなくなるという結果となります。

経験則を使用する場合の２つめの問題は、スパム発信者とスパム対策者の「軍拡競争」になるという性質です。どちらも常に技術を適応させ、より多くのリソースを割きながら決して勝てないのです。スパム発信者のほうが積極的で、革新的で、組織的であったためにスパムに対抗している人々がこの戦争に負けていることも助けになりません。

別の取り組みでは、電子メールの送信者がそのメールの責任を負うべきであるという社会的な評価に基づいています。目標は、そうした責任を負うべきエージェントを特定し、当該エージェントを受け入れるかどうかを評価することです。このアプローチでは、インターネット・メールに３つの強化を施す必要があります。

• 個別の運営機関どうしでの境界に関する明確な認識
• メッセージに対応する責任アイデンティティを検証する手段
• 責任アイデンティティに関する評価情報を作成し共有する手段
  

電子メール運用者はしばしば公開のインターネットに面する「境界MTA」について言及しますが、統一的な権威の下で電子メールの構成要素の範囲を表す、認められている用語はありません。本稿では、これらの信頼の境界を示す用語として、OSI X.400の電子メールに関する取り組みに由来するADMD（Administrative Management Domain：公的管理ドメイン[*]）を提案します。これらは、［13］で論じているように、同一の管理ポリシーに従う運用コンポーネントの集合を区別します。

ADMDの例を図4に示します。図2のシナリオに基づいています。

●図4　個別のADMD（Administrative Management Domains）

このような比較的控えめなケースでも、暗示される責任とインタラクションの複雑さは驚くべきものです。話を簡単にするために、図の上部にあるADMDをユーザまたは付加価値サービスと見て、図の下部にあるADMDをさまざまな従来型のインターネット・サービス（アクセス）プロバイダだと考えてください。境界をまたいで別のADMDと線がつながっているエージェントが「境界」エージェントです。

インターネットの参加者とADMDの多様性が増した結果がスパムなどの乱用につながります。こうした乱用に対応するための先取りした取り組みでは、ADMD間の信頼の性質およびその信頼を適用する方法を変える必要があります。