エージェント評価では、問題のある電子メールについて特定のエンティティ(エージェント)の責任を確認することを目指します。コンテントに対する責任、または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において興味深い点を浮き彫りにします。すなわち、電子メールの処理にかかわるアイデンティティのほとんどは、「送信者」と呼ぶことができるという点です。このため、この用語はスパム対策の議論においてはほとんど意味がなくなっています。
アイデンティティのリストはデータベースに明示的に作成されるため、リストに含まれないアイデンティティが数多く存在したり、リストが不正確だったりする可能性はありますが、誤った陽性判定をほとんど起こさないことが可能です。それでも、アイデンティティに基づくフィルタリングには大きな課題がいくつかあります。
《PREV》 |