Exchange Server 2007

Sender ID を使ったスパムやフィッシングと戦い

Craig Spiezle and Alexander Nikolayev

概要:

• Sender ID の基本
• Exchange Server での Sender ID の構成
• 認証の利点

スパムの脅威の増大への対応策として、多くの ID テクノロジやフィルタ テクノロジが開発されました。これらのテクノロジは、効果を上げるために、各電子メール メッセージに関する特定の質問に依存しています。たとえば、だれが電子メールを送信したのかという質問があります。

残念ながら、メッセージの送信者を問う基本的な質問に必ずしも簡単に答えられるわけではありません。通常、電子メールは、送信者や送信者の代わりに動作するコンピュータの認証を行わずに、インターネット経由で送信されます。実際、他人のふりをしながら電子メール メッセージを送信することは簡単で、スプーフィングされたメッセージを自動的に検出する方法はありません。

電子メールの送受信に使用される簡易メール転送プロトコル (SMTP) は、電子メール メッセージの送信者を確認するように設計されていません。この技術的な抜け穴を利用して、任意の名前やアドレスが送信者として挿入される可能性があります。コンテンツ フィルタやスパム対策はヘッダー情報のみに依存するため、この場合にメッセージの実際の送信元が、メッセージの送信元とされている場所かどうかを確認することができません。

電子メールの認証は、特にこの抜け穴に対処します。認証により、送信側と受信側の両方の電子メール システムで、メッセージが送信元とされているドメインから送信されていることを確認します。これにより、組織は迷惑メールのフィルタ処理を効率的かつ簡単に行えるようになります。さらに、電子メールで指定されている受信者には正当な電子メールが届くことが保証されます。

現在、電子メールの認証に使用できる無償の方法が 2 つあります。1 つは Sender ID Framework (SIDF)、もう 1 つは DomainKeys Identified Mail (DKIM) です。SIDF は、Sender Policy Framework (SPF) と Microsoft Caller ID for E-Mail を融合して作成されたインターネット プロトコル (IP) を基盤としたソリューションです。2006 年 4 月に、インターネット技術標準化委員会 (IETF) は、Sender ID 仕様を RFC 4405 ～ 4408 として発行しました。マイクロソフトを含む、業界やビジネスの関係者が合同で、ビジネスや技術的価値、安定性、完成度、展開しやすさ、送受信のパフォーマンスへの最小限の影響、ISP や企業環境の電子メール エコシステムとの相互運用性などの要因に基づいて SIDF の展開を推奨しています。

DKIM は、Yahoo! の DomainKeys と Cisco Systems Inc. の Identified Internet Mail (IIM) を融合したものです。2006 年 1 月に、IETF は DKIM ワーキング グループの作成を承認しました。仕様については IETF で調査中です。

スパムに対抗できる完璧な解決策はありませんが、SIDF は、スプーフィングされたドメインに対処するための、業界にとって重要な第一歩となるものです。そのため、SIDF は、スパムやフィッシングの攻撃を軽減し、オンラインの信頼と信用を高める重要な要素といえます。世界中の組織は、急速に SIDF を採用しつつあります。現在、SPF レコードを公開している企業やドメイン所有者が 550 万を超え、SIDF で保護されているユーザーが 6 億を超えています。現時点では、世界中で毎日送信されている電子メールのうち、3 分の 1 を超える電子メールが認証されていて、SIDF に準拠しています。

SIDF の開発と世界規模での採用は、多くの組織や企業が貢献しサポートしなければ実現しないでしょう。現在は、AOL、Authentication and Online Trust Alliance (AOTA)、Bell Canada、E-Mail Senders Provider Coalition (ESPC)、CipherTrust、Cisco Systems、IronPort Systems、MarkMonitor、Port25 Solutions Inc、Sendmail、Symantec、TRUSTe、VeriSign などの企業に支えられています。

Sender ID について

業界の一部の調査では、フィッシング詐欺の 95% 以上がスプーフィングされたドメインによるもので、送信者の電子メール アドレスをスプーフィングしたことを示しています。SIDF がスパム対策処理に関して大きな効果を得られるのはこの点です。SIDF は、それ自体がスパムの問題を解決するのではなく、スパムやフィッシングの攻撃の影響を最小限に抑えるのに大きく貢献します。SIDF は迷惑メールの送信を妨げることはしません。ただし、迷惑メールをより簡単に検出することができます。このフレームワークは、電子メールの送信者が自分のドメイン名、評価、ブランドを保護する際に役立ちます。これは、送信者の評価や電子メールの動作に基づいてフィルタ処理上の決定を行うための堅牢な基盤となります。

Sender ID は、各電子メール メッセージが送信元とされているインターネット ドメインから発信されていることを確認しようとします。この処理は、電子メールの送信元サーバーのアドレスを、ドメイン所有者が電子メールの送信を承認したサーバーの登録済み一覧と照合することによって実行されます。メッセージがユーザーの受信ボックスに配信される前に、インターネット サービス プロバイダ (ISP) または受信者のメール サーバーによって自動的に検証が実行されます。

Sender ID またはその他の認証メカニズムはコンテンツ フィルタ システムに代わるものではないことに注意してください。SIDF と DKIM はどちらも実際のメッセージのコンテンツをスキャンしません。代わりに、認証では、メッセージに示された送信者と実際の送信元が同じかどうかを検証した結果が受信メール システムに通知されます。スパムやフィッシングの悪用が行われている多くの状況では、示されている送信元ドメインと実際の送信元ドメインが異なるため、この方法を使用すると、これらのメッセージを自動的に識別し、受信用メール ストリームから切り離すことができます。

SIDF 内の SPF レコードは、ドメインに関連付けられたすべての発信メール サーバーの単純なテキスト レコードを、各 IP アドレスと共に提供します。組織は SPF レコードをその DNS サーバー ゾーン ファイルに公開します。その後、このファイルは、受信者のメール サーバーで確認されます。SPF レコードの設定は、短時間で簡単に行うことができ、料金はかかりません。Sender ID Framework SPF Record Wizard では、ドメインのメール サーバーを調査し、投稿できるようにカスタマイズされたレコードを作成するための段階的なプロセスを提供します (SPF レコードの公開の詳細については、https://www.microsoft.com/japan/mscorp/safety/technologies/senderid/default.mspx を参照してください。このウィザードには、https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ (英語) から直接アクセスできます)。

受信側の SMTP メール サーバーは、SPF レコードが存在するため、DNS 内のドメインのゾーン ファイルに ping を実行します。送信側サーバーの IP アドレスは、検出後に、一覧に示された IP アドレスと照合されます。一致する IP アドレスがあれば、メッセージは本物と確認されます。一方、送信者のドメインの SPF レコードがメッセージの送信元の IP アドレスと一致しない場合、照合は失敗し、結果として、負のスコアが迷惑メール フォルダに配置される可能性があります。図 1 はこのプロセスを示しています。

図 1** 受信メッセージの SPF レコードの確認 **(画像を拡大するには、ここをクリックします)

メッセージが迷惑メールと判断されたら、受信側メール サーバーは、SIDF を使用することで、過去の動作、送信者の評価、メッセージのコンテンツ、および必要に応じて定義された他の条件に基づいてメッセージを分析できます。この機能により、追加の保護機能が提供されます。たとえば、スパムの発信者は、類似するドメインや公開された SPF レコードを登録し、ユーザーや受信側ネットワークをだましてメールが正当な送信者から送信されていると思い込ませることができます。その場合、電子メール メッセージが認証チェックに合格する可能性があるとしても、送信者の評価がスパムの発信者であれば、メッセージを十分にブロック、破棄、または削除できます。

Sender ID の展開オプション

SIDF を使用した送信電子メールの認証は、インフラストラクチャの変更やソフトウェアの更新を必要とせず、クライアント ソフトウェアやサーバー ソフトウェアに固有ではありません。ただし、自社や従業員を保護するために受信の認証を組み込む組織は、受信用システムやメッセージ転送エージェント (MTA) を更新し、SIDF をサポートするソフトウェアや機器を展開する必要があります。主要な市販およびオープン ソースの MTA やスパム対策ベンダ (Microsoft® Exchange Server や Exchange Hosted Filtering を含む) の大半は統合ソリューションを提供します。

マイクロソフトは、マイクロソフトのメッセージング製品すべてに SIDF を統合しました。このようなメッセージング製品には、Microsoft Exchange Server 2003 Service Pack 2 (SP2)、Exchange Server 2007、Microsoft Exchange Hosted Filtering、Microsoft Windows Live™ Mail、MSN® Hotmail®、Outlook® Express、および Office Outlook のメッセージング/コラボレーション クライアントがあります。

ただし、マイクロソフトでもスパムの受信が免除されることはありません。マイクロソフトで毎日受信するトラフィックは平均で約 1500 万のメッセージです。また、最近のスパムの攻撃では、その量の 2 ～ 4 倍ものトラフィックを受信することがわかりました。このような環境で、スパムをうまく防ぐ方法は、使用可能なテクノロジを慎重に実装することにあります。

マイクロソフトは、社内の Exchange Server スパム対策ソリューションを Exchange Server 2003 の Sender ID フィルタや Exchange Server 2007 の Sender ID エージェントに基づいて実行しています。Exchange Server のどちらのバージョンでも、Sender ID の状態は、対応する DNS サーバーにある Sender ID レコードの評価に基づいています。実際のドメインを特定するには、次の優先順位で RFC 2822 メッセージ ヘッダーを調査します。

1. Resent-Sender
2. Resent-From
3. Sender
4. From

送信者のドメイン (または、電子メール システムが他のメール サーバーの代わりにメールを合法的に転送できるため、最近メッセージをメッセージング ストリームに挿入するエンティティ) は、定義された順序で記載されているヘッダーの最初の定義を探すことによって特定されます。これらのヘッダーが検出されない場合、SIDF は、SMTP RFC 2821 MAIL FROM 句を使用します。

Sender ID の構成

Exchange Server 2007 では、エッジ トランスポートの役割がインストールされていないサーバーで Sender ID エージェントを有効にできます。Sender ID エージェントが有効な場合、受信コネクタ経由で送信されるメッセージをフィルタ処理します。つまり、(外部ソースから) 受信するすべての非認証のトラフィックは、Sender ID の処理対象となります。Exchange Server 2003 では、Sender ID の状態が EXCH50 BLOB 内のサーバー間で保持されます。Exchange Server 2007 では、これはメッセージ メタデータにも追加されました。最終的な送信先では、どちらも今後クライアントが使用するために MAPI プロパティに変換されます。

Exchange Server 2003 の [メッセージの配信プロパティ] で使用できる Sender ID フィルタの構成では、Exchange Server の失敗した検証への対処方法を指定するだけです。

Exchange Server 2007 で Sender ID を有効にするには、図 2 に示すように、エッジ トランスポートの役割が構成されたサーバーの Exchange 管理コンソールを開き、[スパム対策] タブをクリックし、[Sender ID] を選択して、[Actions (アクション)] 作業ウィンドウの [Enable (有効)] または [Disable (無効)] をクリックし、Sender ID エージェントのオンとオフを切り替えます。さらに、図 3 に示すように、Exchange 管理シェルを使用して、Sender ID を有効または無効にできます。

図 2** Exchange Server 2007 の Exchange 管理コンソールでの Sender ID エージェントの制御 **(画像を拡大するには、ここをクリックします)

図 3** Exchange 管理シェルを使用して Sender ID を有効にする **(画像を拡大するには、ここをクリックします)

[Sender ID のプロパティ] ダイアログ ボックスでは、エージェントの状態 (有効または無効) を反映します。[アクション] タブには、Exchange Server 2003 で使用できるのと良く似たオプションがあります (図 4 参照)。

図 4** Exchange Server 2007 の [Sender ID のプロパティ] ダイアログの [アクション] **(画像を拡大するには、ここをクリックします)

Sender ID の実装と機能に関しては、Exchange Server 2003 と Exchange Server 2007 に重要な相違はありません。Sender ID フィルタ (Exchange Server 2003) と Sender ID エージェント (Exchange Server 2007) の両方で、展開と検証に同じ基本アルゴリズムが使用されています。考えられるアクションの範囲も同じです。[メッセージの削除] (自動削除)、[メッセージを拒否する] (500 レベルの SMTP プロトコルの応答)、[Sender ID の結果をメッセージにスタンプして処理を続行する] というアクションがあります。この最後のオプションは、Exchange Server の両方のバージョンの既定のアクションです。

Exchange Server 2007 では、状態コードの FAIL も TempError も、[メッセージを拒否する] アクションをトリガできます (Exchange Server 2003 では、このアクションをトリガできるのは、状態コード FAIL だけです)。Sender ID エージェントは、状態コードが TempError のメッセージで [メッセージを拒否する] アクションをトリガするように明示的に構成されている必要があります。既定では、これらのメッセージはシステムに受信され、Sender ID の結果をスタンプされた後、処理されるためです。

この構成オプションは、グラフィカル ユーザー インターフェイスでは提供されていないため、Exchange 管理シェルを使用して、TempError 状態コード用に Sender ID のアクションを構成する必要があります。たとえば、Sender ID エージェントが状態コード TempError のメッセージを拒否するように設定するには、次の Sender ID エージェントのコマンドレットを実行します。

Set-SenderIDConfig -TempErrorAction Reject

Exchange Server 2007 での Sender ID の状態の結果および考えられるアクションの範囲は、Exchange Server 2003 の Sender ID フィルタの範囲に類似しています。これについては、図 5 を参照してください。

Figure 5 Exchange Server 2007 の Sender ID の状態とアクション

Exchange は (構成されている場合) Sender ID の検証に失敗したメッセージのみを削除します。他の結果では、メッセージの削除はトリガされません。結果の状態が Neutral、None、SoftFail、TempError、または PermError の受信メッセージは、適切にスタンプされ、さらにスパム対策を検証するために渡されます。メッセージの形式がまったくもって不適切で、FROM IP アドレスが存在しないときには、Sender ID の状態をメッセージにスタンプすることができない場合があります。この状況では、メッセージは破棄も拒否もされません。むしろ、メッセージは、Sender ID の状態が設定されていないと以降の処理のために渡され、認識を高めるために適切なイベントがログに記録されます。

Exchange Server 2007 では、Sender ID の検証から除外する送信者ドメインや Exchange Server 受信者を簡単に定義できます。繰り返しますが、この構成オプションは、Exchange 管理シェルからしか利用できません。たとえば、ドメイン contoso.com を Sender ID フィルタから除外するには、次のコマンドを実行します。

Set-SenderIDConfig -BypassedSenderDomains contoso.com

同様に、指定した Exchange Server 受信者に送信されたメッセージを Sender ID フィルタから除外するには、次のコマンドを実行します。

Set-SenderIDConfig -BypassedRecipients user@contoso.com

Exchange Server 2007 では、Exchange 管理シェルのコマンドレットで設定されていてもグラフィカル ユーザー インターフェイスから使用できない Sender ID の構成値は、図 6 に示すように、Exchange 管理シェルで Get-SenderIDConfig コマンドを実行して簡単に取得することができます。

図 6** Sender ID の構成のコマンドレット **(画像を拡大するには、ここをクリックします)

Exchange 管理シェルは、IP アドレスと対応するドメイン名を迅速に手動で検証する際に使用できます。Sender ID の状態を確認するには、次のコマンドを実行します。

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

ドメインが存在しない場合、結果は図 7 のようになります。

図 7** アドレスの Sender ID の状態の確認 **(画像を拡大するには、ここをクリックします)

Sender ID の利点

電子メール メッセージを認証したりユーザーが受信するスパムの量を削減する場合の明白な利点とは別に、プロトコルとしての SIDF には他の利点があります。マイクロソフトは、SIDF の開発時に、パフォーマンス、コスト、展開とスケーラビリティ、相互運用性など、いくつかの主要な目標に注目しました。

SIDF は、最初に、電子メールの送信者を認証し、送信者の評価スコアの適用を許可します。その結果、スパムやスプーフィングされた電子メール メッセージを大幅に削減し、既知の送信者や信頼された送信者からの正当な電子メール配信の確実性が高まる可能性があります。SPF レコードは無償で作成できるので、SIDF に準拠する組織であれば簡単に作成できます。新しい標準の規定に準拠したい組織はそうできます。SIDF を使用すると、SPF レコードを公開するのと同じくらい簡単に準拠できます。

SIDF は、可能な限り既存のソフトウェア内で動作するように開発されました。これは、さまざまな電子メール アーキテクチャやクライアントとサーバーのソフトウェアで使用できます。認証サービスでは、効果を上げるために、小規模なホーム メール サーバーと同様、大規模な ISP のニーズに簡単に応じることができるようにする必要があります。SIDF は、1 台から数千台もの電子メール サーバーに加え、電子メール サーバーを別の組織にアウトソーシングする人々もサポートできます。

2007 年 4 月 18 ～ 19 日に、マイクロソフトと 30 を超える組織やパートナーから成る業界団体は、マサチューセッツ州のボストンで、Authentication & Online Identity Summit を開催します。この 2 日間のプログラムでは、ケース スタディを調査して Sender ID のテクニカル レビューを行い、電子メールの認証のビジネス価値について詳しく説明します。詳細については、http://aotalliance.org/summit2007 (英語) を参照してください。さらに、ツールやリソースなどの情報については、https://www.microsoft.com/japan/mscorp/safety/technologies/senderid/default.mspx や https://www.microsoft.com/japan/exchange/default.mspx を参照してください。

Craig Spiezle は、マイクロソフトの Windows Live Safety のテクノロジ戦略と計画の責任者です。Craig は、電子メール認証のプロダクト マネージャとして、Sender ID を業界に導入する際の原動力となりました。1992 年にマイクロソフトに入社した後、国際マーケティング、製品サポート戦略、OEM、新興市場の開発など、複数の管理職に就きました。

Alexander Nikolayev は、マイクロソフトのプログラム マネージャであり、サーバー側プロトコル、トランスポート コア、Exchange Server および Windows Server のスパム対策コンポーネントの責任者です。彼は、メアリー大学から MBA を取得しました。Exchange チームのブログ (blogs.technet.com/exchange) (英語) で彼の投稿を参照してください。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.