« 場の提供から個をつなくメディアとしてのインターネット技術 | メイン | SUNがSolarisのソースをオープン化 »

2004年06月03日

マイクロソフトのSPAM対策プラン

マイクロソフトのSPAM対策プランを紹介します。 新しい技術標準の確立などを含む長期的なフレームワークが Microsoft Coordinated Spam Reduction Initiative (CSRI) として本年2月14日に発表されていました。 最近、話題になっているCaller IDもCSRIの一部です。

1. Overviewの記述によると、フレームワーク全体としては、 STEP 1 メールフィルタエージェントの判定ロジックへの入力情報を増やす、  STEP 2 正当なメールであることを証明できるような手段を提供する、  STEP 3 FROMアドレス詐称を防止する手段(e.g. Caller ID)を実現する、の3ステップで構成されているようです。 以下に各ステップの詳細を説明しますが、多くのアイディアはマイクロソフトオリジナルではなく、かなり前から技術者の間で議論されているものです。 マイクロソフトとしては、 特定の技術を特に推進する意図はなく、適切にいろいろな手段を組み合わせてトータルソリューションを業界で確立していきたい、というスタンスのようです。

STEP 1 フィルタへの入力情報を増やす 
メールフィルタリングについては、フィルタリングアルゴリズム自体を規定するような標準を推進する意図はないが、フィルタへのインプット情報を増やすために必要な業界標準を確立してくことを提案しています。 

STEP 2 正当なメールであることを証明できるような手段を提供する 
このSTEP 2の実現方式として、おすみつき方式と発信者荷重方式の二つを提案しています。

大企業などの大きい組織によって運営されているネットワークについては、当該ネットワークがどういうポリシーで運営されているかを客観的な第3者機関がおすみつきを与えるおすみつき方式を提案しています。  (ちょうど、VeriSignがおすみつきのしくみを提案しています) つまり、このようなネットワークから発信されたメールについては、メールのドメイン名をもとにどのようなポリシーでメールが発信されているかを着側ドメインで確認でくるようにしよう、というわけです。  おすみつき文書の具体的データ形式として、マイクロソフトは ETP Certificate というのを提案しています。 ETPはドメインレベルでポリシーを証明したり、メールアドレスレベルでポリシーを証明したりできるようです。 (ドメインレベルになった場合には、Yahoo!のDomainKeyに相当する技術になります)

一方で、SOHOや個人などがおすみつきを受けることは難しいので、小規模なネットワークからメールが発信される場合には、発側メーラに高負荷処理を実行させる発信者荷重方式を提案しています。  Black Penny とも呼ばれていました。 これは、小規模なネットワークのメール中継装置はSPAM発信でもしない限り負荷が軽くすむはずなので、高負荷処理を実行することを条件とすることでSPAM発信を抑制しよう、という発想に基づいています。 具体的な負荷のかかる処理として、ハッシュ関数をf()とし、与えられた入力aについて、f(x)=aとなるような未知数xを求めさせる処理を提案しています。 (実際にはもう少し複雑になっています)

STEP 3 FROMアドレスの詐称を防止する手段を提供する 
各ドメインがOutgoing MTAのIPアドレスのリストを公開することとして、着側ドメインが発側ドメインのMTAのIPアドレスのリストをDNSで検索できるようにするという考え方です。

この具体的スペックの案としてマイクロソフトは Caller ID for E-mail というのを提案しています。 (最近、SPFという対案との調整に成功したそうです)。 この提案では各ドメインがメール中継網の運用ルールをep (E-mail Policy文書)というデータで公開します。 このepの中に、outgoing MTAのリストも記述します。 (もともとの提案では、epはXML形式のイメージでした)  あるドメインのepを別のドメインが簡単に検索できるようにするため、各ドメインは_epというサブドメインを定義し、このサブドメインに対応するTXTレコードとしてepをDNSに登録しておきます。

試しに、_ep.microsoft.comのTXTレコードをDNS lookupしてみてください。 下記のようなレコードが返ってきます。

_ep.microsoft.com  TXT  "213.199.128.160213.199.128.145207.46.71.29194.121.59.20157.60.216.10131.107.3.116131.107.3.117131.107.3.100"

上記の発側MTA確認は、メーリングリストやエイリアスサービスによって転送されたメールや"この記事を友達にメール"みたいなメール代理発信サーバによって発信されたメールに適用できないことが問題になります。 マイクロソフトは、メール代理発信サーバがメール発信する場合にはSenderヘッダをメールに付加、メーリングリストやエイリアスサービスがメールを中継する場合にはResent-fromヘッダをメールに付加すること、を提案しています。

だいたい、こんなところです。

投稿者 motlab : 2004年06月03日 23:33

トラックバック

このエントリーのトラックバックURL:
http://motlab.sakura.ne.jp/mt/mt-tb.cgi/25