これまでの解説を踏まえ、今度は、企業のメールシステムに送信ドメイン認証技術の仕組みを導入する際の手順を解説していこう。
N+I NETWORK Guide 2005年7月号よりの転載です
|
企業のメールシステムで送信ドメイン認証技術を活用して、スパムや詐欺メールを排除するには具体的にどのようにすればよいだろうか。ここでは、企業のシステムに送信ドメイン認証の仕組みを導入する際の手順を解説する。
現時点で利用可能なDomainKeysとSender ID/SPFを既存のシステムに導入していく場合、次のような手順で実施する。
@送信ドメイン認証を利用したポリシーを決める
送信ドメイン認証により、エンベロープの送信者アドレス、またメールヘッダの送信者アドレスの正当性を確認できるので、それをどのように利用するかというポリシーを考える。
A自社でメールの送信に利用しているドメイン名やメールアカウントを把握する
自社から送信するすべてのメールについて送信ドメイン認証可能とする必要があるので、利用しているドメイン名やメールアカウントを把握し、そこから送信されるメールが送信ドメイン認証を扱うMTAを経由するようにする。
Bメールを送信する可能性のあるホストのリストを作成する
適切なSPFレコードを作成するため、ゲートウェイMTAなどのリストを作成する。
CSPFレコードを公開する
作成したリストからSPFレコードを作成し、DNSに公開する。
DゲートウェイMTAで外部ドメイン向けのメールを扱うメールサーバにおいて、DomainKeysの署名を開始する
EゲートウェイMTAで外部ドメインからのメールを受信するメールサーバにおいて、Sender IDとDomainKeysの認証を開始する
認証の結果を生かしたポリシーとして、現時点で妥当と考えるものを以下で説明する。また、詐欺メールを判断するフローを図13に示す。
●認証に成功したメール
送信者のドメインがホワイトリストに入っている場合、そのほかのスパム対策のフィルタを通さないでメールボックスに配送する。また、ブラックリストに入っている場合は、受信を拒否する。こうすることで、そのドメインから送られてくるメールがFPやFNになることはない。また、認証が成功していることをヘッダに記録する。
●認証に失敗したメール
認証に失敗したからといって、即座に受信を拒否すべきではない。というのも、送信ドメイン認証技術自体がまだ過渡期にあるので、さまざまな要因で正当なメールであっても認証に失敗するケースがあるからだ。ただし、スパムである可能性は高いので、スパムフィルタでチェックして配送する。また、認証に失敗したことをヘッダなどに記録して、受信者にわかるように表示する。エンドユーザーは、自分が使うMUAのメールフィルタ機能で好きなように認証情報を扱うことができる。
●認証しないメール
これはそもそも、認証情報を提供していないドメインから送られてきたメールである。これは今までどおり、コンテンツスキャンベースのスパムフィルタを経由させる必要がある。送信ドメイン認証を利用するサイトが広まっていけば、このカテゴリに入るメールは、よりスパムらしいと判断できるはずである。
DNSのMXレコードに登録しているメールサーバですべてのメールを扱っている場合は、そのサーバを基にSPFレコードを作成すればよいが、管理者が把握していないドメインが利用されていたり、想定外のホストで外部とメールをやり取りしている可能性があるので、認証できないドメインやホストがないよう十分にチェックする。
Copyright © ITmedia, Inc. All Rights Reserved.