スパム対策の取り組みにおける課題

Dave Crocker（Brandenburg InternetWorking社）著
原文：Challenges in Anti-Spam Efforts （The Internet Protocol Journal – Volume 8, Number 4）

• スパムの性質
• 電子メールのアーキテクチャ
• スパムのアーキテクチャ
• スパムをコントロールするための実践的取り組み
• 責任確認
• 認証標準
• 協力のサポート
• 謝辞

インターネットは私たちに１つの教訓を与えてくれると言われています。それは、「スケールの変化」です。インターネットはおそらく10億の利用者、数億のコンピュータ、数万数十万の独立のサービス運営者で構成されています。地球のほぼすべての国の中で、また国々の間で運用されています。そして個人や組織、あるいは政府のサービスに利用されています。そのため、数多くの異なる文化、数多くの異なるスタイルのコミュニケーション、そして数多くの異なる管理方法との親和性を持っていなければなりません。インターネットには、集中的に管理を行うところはなく、特に決まった予定に合わせることもなく運用されています。したがって、変化は漸進的かつ自発的なものとなります。つまり、どのような変化であるべきか合意が得られたときに変化が起きます。

1990年代の始めごろ、インターネットは小さな研究コミュニティからグローバルなマス・マーケットへと成長しました。小さな町が、大きく無秩序な都市へと変貌する様子を想像してみてください。大きな都市では、ほとんどの人は互いを知らず、これらの見知らぬ人々は種々雑多な価値観と行動規範を持っています。そのため、人々は互いにずっと慎重でなければなりません。つまり、問題は町の従来の運用方法にあるのではなく、変化する要求にあります。したがって、スパムは単に、インターネットの成功の不幸な（しかし、率直に言えば予想し得た）例なのであって、インターネットの失敗を示すものではありません。

本稿では、社会の多様性、電子メールの技術と運用の複雑さ、およびスパムをコントロール下に置くための具体的な取り組みが絡み合う、スパム問題のシステム・レベルでの複雑性を探求します。コントロールの方法論については、これまでのほとんどの取り組みは、スパムを受信しているサイトで使用される分析ツールに関するもので、メール・コンテント、関係するアドレス、またはトラフィックの流れを評価するものでした。最近の取り組みでは、個々のメッセージまたは集合的なメッセージ・トラフィックに対する責任を明らかにする責任アイデンティティの割り当てと評価に焦点を当てています。

スパムの性質

人々はスパムが深刻な問題だということには同意しますが、その定義について一致した意見を持つことは難しいようです。しかし、 UBE（Unsolicited Bulk E-mail：未承諾一括送信電子メール）とするのがおそらく最も便利でしょう。［1］スパム発信者は、大量のメッセージを、そのコンテントを要求していない多数の異なる受信者に送信します（興味深いことに、ほとんどのスパム発信者は、宛先にメッセージが届くかどうかを個別のレベルでは気にしていません。送信した内容が、十分な割合で宛先に届きさえすればよいのです）。

スパムは、インターネットの技術標準に準拠し、望まれている正当なメッセージと技術的にはまったく変わらない内容を持つことができます。したがって、標準に違反していたり他の異常な特性を持っていたりするスパムが今日一般的だったとしても、こうした異常に基づいて検出を行う取り組みでは長期的なメリットは得られません。スパム発信者は適応性が高く、有効性のある最も簡単な方法を採用するからです。しかし、スパムは常にわれわれの社会慣習に反します。したがって、スパムに対する、標準の策定などの長期的視野の予防的かつ技術的な対抗策は、こうしたことに対する社会的な決断を先導するのではなく、それらの決断に従うものでなければなりません。

他の社会的な問題と同様に、われわれはスパムを完全に排除することはできないにしても、おそらくコントロールはできるでしょう。これは、われわれが、許容できる水準にスパムを抑制する方法を追求しながら、社会的地平の一部として常にスパムが存在することに順応しなければならないことを意味します。スパムを検出して排除する取り組みは何年にもわたって行われてきました。有効かつ限定的な成果を示した技術もありますが、そのほとんどは短期的なものでした。言い換えれば、スパムをコントロールするためのこれまでの数多くの試みは、いずれもスパムを世界的に減らすには至っていないのです！　したがって、われわれは新しく提案されるどのようなスパム対策についても慎重にならざるを得ません。また、スパムをコントロールするためには、相補的な一連の技術と、スパム発信者がそれぞれの手法を継続的に適応させるのに合わせて、それらの技術を継続的に適応させていくことも必要になるでしょう。つまり、新しい対策を評価する際には、スパム問題解決の最終解決策（FUSSP：Final Ultimate Solution to Solve Spam）の候補としてではなく、その段階的な利点を考慮しなければならないことを意味します。

グローバルなインフラストラクチャを変えていくには長い時間がかかり非常にコストもかかります。提案される対策には複雑な技術を要するものもあれば、継続的に相当な管理作業を必要とするものもあります。中には、エンド・ユーザに対して重荷となるような条件を課すものさえあります。したがって、われわれが展開する仕組みは、スパム発信者がそれに適応を試みた後でも、確実に長期にわたって十分なメリットをもたらすものでなければなりません。また、開発コストがリーズナブルで、継続的な管理も限定的で、使用も簡単である必要があります。対策案の有効性を評価するに当たっては、スパムが問題となっていなかった場合でも、それが望ましい仕組みであるかどうかを考えるとよいでしょう。「望ましい」という答えであれば、その対策案は全般的な戦略的メリットがあるということであり、スパムへの対抗はその採用に緊急性を加えるだけのことです。

インターネットは、われわれ全員の相互のアクセスを格段に向上します。共同作業や、専門コミュニティの形成、個人的なやり取りにとってはすばらしいことです。しかし、われわれのプライバシーの侵害およびオンラインでのセキュリティに対する脅威の面では問題です。残念ながら、メリットとデメリットは表裏一体となっています。電子メールをコントロールするためのわれわれの取り組みは、その利点までも損じないように慎重に行う必要があります。さらに言えば、われわれの取り組みは、われわれがまだ思い至っていないような革新的なメリットが被る可能性のあるダメージを抑える必要もあります。

スパムの発信者は、メッセージが１つ増えてもほとんどコストがかかりません。電子メールを、手紙を送ったり電話をかけたりするのと同じように、メッセージごとに送信者に直接課金すればよいと考えるのは簡単です。コストがかかれば一括送信のような乱用に対する防壁となります。しかし現実には、電子メールは長い歴史を持つ別の種類のサービスであり、選択肢は異なるものとなります。電話や郵便は、高度に集中化された公的な運営機関を有し、その利用料金は直接の実際の経費をまかなうことをベースにしています。対照的に、電子メールは高度に分散化されたサービスです。公的な機関による仲介の必要がなく、やり取りを行う個人のそれぞれのシステムが直接互いに通信します。追加料金を課金するとしたら、それらも実際のサービスに基づくものでなければなりません。また何らかの「税」を課したとしても、それはそれでまた別の問題が生じます。たとえば、誰がそのお金を、何のために受け取るのでしょうか。

電子メールの自由度と、人間の新しいコミュニケーション手段をサポートする能力を維持するには、現在の自然発生的な電子メール交換のオープン・モデルを維持しなければなりません。したがって、今後インターネットのメールはおそらく２つの論理的なサブセットに分かれていくと考えられます。１つは、信頼できる責任確認が可能な参加者で構成され、もう１つにはその他の全員が含まれます。信頼できる参加者に対しては、チェックやフィルタリングを緩和できるかもしれません。それよりも重要なのはおそらく、問題が生じたときに、信頼できるアイデンティティからのメールは、自動的に拒否されずに通常通りに配信され、その間に発信元についての照会が行われることが考えられます。

電子メールのアーキテクチャ

インターネット・メールは単純なモデルに基づいています。つまり、ユーザの世界と伝送の世界を分けて考えます。誰もが誰にでもメッセージを送信できます。基本サービスには中心的な権威機関はなく、発信者、受信者および運営者による認証を必要としません（通常、電話および郵便サービスでは、一般に手紙の送り手や電話の発信者の認証を行わないことは注目に値します）。

図1に示すように、このモデルは次を区別するまでに成長しました。

• MUA（Mail User Agents）。エンド・ユーザを表します。
• MTS（Mail Transfer Service）。１つ以上のMTA（Mail Transfer Agents）から成り、SMTP（Simple Message Transfer Protocol）を使用します。［2、3］
• MSA（Message Submission Agent）。新規メールを送信します。［7］
• Notification HandlerまたはBounce Handlerは、失敗通知など、返された伝送レポートを処理するMUAです。Handlerのアドレスは、メッセージ送信時にMSAによって指定されます。［11］
• MDA（Message Delivery Agent）を使用したメール配信。ユーザ固有の配信動作指定を伴う場合があります。［8, 9］

図1　インターネット・メールのアーキテクチャ

電子メールの目的は、MUA間でメッセージをやり取りすることです。ユーザから見れば、電子メール・クライアント（MUA）がユーザの直接経験するすべてです。ネットワーク管理者にとっては、MTSソフトウェアが関心の範囲となります。

中核となる電子メール・メッセージ・オブジェクトも単純な枠組みを持っています。コンテントは次のものから成ります。

• 構造化されたテキスト形式のメタ情報。これはヘッダと呼ばれ、アドレス指定、発信日、一意のメッセージ識別子、コンテントに関する任意の形式の記述などのフィールドがあります。［4、5］
  • 任意の形式のASCIIテキスト行。これはボディ（本体）と呼ばれ、潜在的に複雑な構造化されたマルチメディアおよび複数文字セットの添付ファイルをサポートするまでに進化しました。［12］

図2に、ユーザからユーザへの単純な例を示します。メッセージが３つのアドレスに送信されます。アドレスの１つは特別なMUAで、別の２つの受信者にメールを再配送します。この図の目的は、ユーザからユーザへという電子メールの性質を強調するとともに、インターネット・メール・コンポーネントの集合的なやり取りが、非常に単純な使用においてさえももたらす複合的な爆発を検討するための基盤を提供することです。また、さらに別のアーキテクチャ要素も示します。

• メディエータ（Mediator）とは、メーリング・リストのようにメッセージを再配送するMUAのことです。［10］ メディエータは、作成者のアドレスを含め、元のメッセージの大部分または全部を維持する一方で、コンテントに大幅な変更を加えたり追加を行ったりできます。これはMTAにはできないことです。したがって、メディエータの役割は、コンテントに対するユーザ・レベルでの責任であり、伝送に関するMTSレベルの責任ではありません。

図2　複数の受信者がいる単純なシナリオ

スパムのアーキテクチャ

スパム発信者の中には合法的な事業を営みながら、スパム行為に対する公的な規制がないがために、マーケティングの取り組みが過剰に積極的になっているところもあります。国際的なレベルで取り組む必要があるという困難はありますが、法的な規制（法律または契約の両方）によってこうしたビジネスを抑制できるだろうという妥当な期待はあります。対照的に、悪意を持ったスパム発信者は、責任を負うことを積極的に避け、自分たちのトラフィックに対する防壁を迂回し、他人が所有するコンピュータを、その所有者に知られないうちに、同意のないままにスパム発信に加担させます。法的な詳細はさておき、後者のグループを分析するために使用すべき最良の社会モデルは「犯罪」です。多くの場合、その行動は特定の法律に違反することはありませんが、最も重要なのは、スパム発信者の振る舞いのスタイルが犯罪者のそれと同じだということです。

残念なことに、スパム発信の技術的世界と運用の世界も、スケールが拡大し洗練されてきました。スパム発信は、かつては一人の送信者と1台の送信コンピュータで行われていました。そのパフォーマンスは、使用するコンピュータの能力とインターネット接続の帯域幅の制約を受けていました。今日、悪意のあるスパム発信者は、図3に示すように、ゾンビと呼ばれる乗っ取られたシステムの大軍をコントロールします。ゾンビは、自分のシステムが乗っ取られていてスパム送信に使われていることを認識していない合法的なユーザが所有しています。

図3　悪意を持ったスパム発信者がコントロールするネットワーク

悪意を持ったスパム発信者のコミュニティは非常によく組織化されています。いまや巨大な地下経済を形成しています。加担者の中には、フィルタを突破する方法を開発することを得意としているものもいます。他の加担者はコンピュータを乗っ取って、それらをゾンビに変えていきます。また、ゾンビ集合をスパム送信の期間だけ使用できるように貸し出すものもいます。ゾンビ・システムの数は数千万台に達すると見られています。スパムが送られてくると、受信者はしばしば「クリック」してトランザクション・ウェブ・ページにアクセスします。ウェブのホスティングが、サーバ側の処理をわかりにくくするために、数段構えで提供されているため、責任を確認できる可能性がさらに減じられます。

一般に、スパム発信者は商品を売るという昔ながらの目標があります。しかし、政治的な動機や宗教的な動機、あるいは脅迫のような露骨な犯罪的意図を持っていることも考えられます。特定の宛先に大量のメッセージを送信できる能力は、ネットワークに対するサービス拒否攻撃（DoS攻撃：Denial of Service攻撃）を通じて組織を脅かすために使用できる道具をスパム発信者に与えます。

スパムをコントロールするための実践的取り組み

スパムが簡単に解決できる問題だと信じたい誘惑に駆られますが、歴史はわれわれに慎重であるように教えてくれています。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間の信頼の性質およびその信頼を適用する方法を変える必要があります。

責任確認

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

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

コンテント・エージェントは、作成者（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フィールドに記載されているアイデンティティは、たとえそのフィールドが有効と確認されていたとしても、実際の作成者ではないかもしれません。メッセージは、乗っ取られたコンピュータから発信され、コンピュータの所有者の知らないうちに、そのコンピュータに関連付けられているアイデンティティが使われている可能性があるのです。また、メール送信ネットワークの運営者がコンテントの作成に一切かかわっていないとしても、集合的なトラフィックの問題については運営者に責任を負わせることは理にかなっているかもしれません。
• アイデンティティの有効性をどう確認（認証）するか。どのエンティティが有効性の確認を行うのか。どう信頼を確立するのか。有効性確認の仕組み自体がだまされることはないか。
• 特定のアイデンティティがスパム送信者であるか否かをどのように判定するのか。アイデンティティの品質を保証するのはどのエンティティか。また、保証を行うエンティティはどのように信頼を確立するのか。

認証標準

責任を確認するには、対象となるエージェントのアイデンティティが正確で信頼のおけるものでなくてはなりません。したがって、アイデンティティの認証は、評価の取り組みにとっては必須条件です。ただし、認証だけでは正当な評価は保証されません。スパム送信者も自分のアイデンティティを登録して正当化できるからです。

初期のスパム対策のアイデンティティ方式では、フィルタを実行しているサーバに直接送信を行っているクライアントSMTP MTAのIPアドレスを使用します。アドレスは基盤となるネットワーク・サービスによって提供されるため、信頼されていました。しかし、スパム発信者はIPアドレス空間を盗むことに長けてきています。たとえば、割り当て済みでありながら未使用のIPアドレス・ブロックを使用する経路を通知するというような方法を使います。また、IPアドレスは、ホストがインターネットへの接続を変えるたびに変わり、作成者ではなく運営者に属します。このため、電子メールの評価時にはIPアドレスはあいまいで信頼できないものとなります。

最近では、より安定しており、ADMDの権限境界にもなじみやすい、ドメイン名の使用が中心となっています。中継されるメッセージの有効性確認にドメイン名を使用する取り組みには、大きく分けて２つの方向があります。１つは、アイデンティティを、メッセージを処理する経路上のシステムに関連付けます。こうした「パス登録」方式には、Sender Policy Framework、Sender-IDおよびCertified Server Validationがあります。もう一方の方式は、ドメイン名をメッセージ・オブジェクトに関連付けます。これには、Domain-Keys Identified MailおよびBounce-Address Tag Validationが含まれます。

Sender Policy Framework（SPF）［16］は、進化してきており、複数のアイデンティティに対応しようとしています。主にRFC 2821のMailFromコマンド内のドメイン名を使用します。その名前を、DNS（Domain Name System）に照会し、直前の中継点のMTAのIPアドレスがその名前で登録されているか確認します。経路上の任意のSMTPサーバがこの照会を行う可能性があるため、SPFでは、メッセージのすべての配送経路上のすべてのMTAがDNSに含まれている必要があります（しばしばこのモデルを単純化して境界MTAの間でのみ使用することがありますが、しかしこのような大幅な制約はSPFでは規定されていません。むしろ、このモデルは通常、一般化して使用するものと位置づけられています）。SPFのソフトウェア面のオーバーヘッドはとても小さいですが、経路の数が増加し経路が変化するにつれて管理面のオーバーヘッドは大きくなる可能性があります。加えて、送信SPFのDNS構成によっては、受信者ごとの照会の数が膨大なることもあります。最後に、RFC 2821 MailFromコマンドの役割は、Notification Handlerアドレスを指定することです。このアドレスは、他の送信元情報とまったく異なる可能性があるため、経路上のすべてのMTAを登録することが問題となります。そのため、SPFは、第三者の転送サービスを経由する場合などに、転送トラフィックに関して大きな管理上の問題を抱えています。

Sender-ID（SID）［17］では、SPFに似たモデルを使用しますが、RFC 2822のSenderフィールド（あるいは、SenderフィールドがなければRFC 2822のFromフィールド）にある送信元アドレスのドメイン名に基づきます。SIDとSPFはともに2004年にIETFでの標準化を目指しましたが、作業部会の取り組みは、参加者の大枠での統一的コンセンサスの欠如と知的所有権の主張をめぐる懸念に起因して、失敗に終わりました。

Certified Server Validation（CSV）［18］は、現在のクライアント／サーバSMTP中継点のみを対象とします。クライアントは、RFC 2821のEHLOコマンドの中に運営者のドメイン名を指定します。サーバはこの名前を使用してDNSに照会を行います。その後、SMTPクライアントのIPアドレスの有効性を確認し、メールを送信する権限がドメイン名管理者によってクライアントに与えられているかどうかを判断します。CSVでは、クライアントのドメイン名に関して評価サービスを照会する標準の仕組みも規定しています。

DomainKeys Identified Mail（DKIM）［19］では、伝送中のメッセージに適用される責任確認が可能なドメイン名を規定しています。公開鍵暗号を使用してメッセージにデジタル署名を加え、書名のドメイン名がRFC 2822のFromフィールドのドメイン名と異なる場合の指針を提供します。

DKIMドメイン名検証は、メッセージ・コンテントの長期的な保護を中心とする［20、21］などの強力な認証方式とは大きく異なる目標を持っています。またDKIMでは、そのパラメータ情報によってDKIMに対応していない受信者ユーザ・エージェントが影響を受けないように、メッセージ・ボディではなく、特別なRFC 2822ヘッダ・フィールドにパラメータ情報を置きます。公開鍵暗号の計算処理コストは比較的高いですが、電子メールの処理は一般に入出力に左右されるため、現実にはDKIMを使用しても、サーバの総合的なメッセージ処理能力に対して与えるインパクトは小さいようです。

Bounce Address Tag Validation（BATV）［22］では、バウンスなどの誤配送処理通知（misdirected handling notices）の問題に対応します。RFC 2821のMailFromバウンス・アドレスに作成者がデジタル署名を加えられるようにします。作成者のバウンス・エージェントが、バウンスになりすましたメッセージを受信したとき、エージェントはそのアドレスの有効性を検証できます。メーリング・リスト・ソフトウェアなどの電子メールの中継者がメールボックス部分の「中核」を知ることができるように、形式については標準化が必要です。署名セマンティックスの作成者が、署名セマンティックスの唯一の消費者なので、対称鍵に基づくものを含め、任意の署名アルゴリズムが使用できます。利便性を考慮し（および、存在証明として）、BATVの仕様にはすでに使用されているアルゴリズムの例が記載されています。

協力のサポート

スパム対策は、協調に基づく取り組みでなければなりません。それには、情報交換および調整を支援するツールや標準を使用すると有効です。そのためには、スパムにかかわる出来事の報告、特定のスパムの特性把握、およびスパム・コントロール・データの送信のための標準の方法があれば役に立ちます。その方向での取り組みはすでにいくつか進んでいます。［23］ スパムに対抗するには世界的な協調が必要です。そのために、異なる言語を話すネットワーク管理者同士のやり取りを手助けする各種サービスの支援を受けることになります。また、ホワイトリストとブラックリストの構文とセマンティックスについても標準があるべきでしょう。

謝辞

本稿のレビューを行っていただいた方々との異例の量の対話について、特に感謝をしたいと思います。そうした対話のおかげで、本稿は格段に明瞭かつ簡潔になりました。また、念のために触れておきますが、この主題について驚くほど多様な見方があることも浮き彫りになりました。実のところ、本稿に続くJohn Klensin氏の記事は、その対話の直接の結果です。