チェック結果の扱い
認証結果をどのように扱うかについては少し注意する必要がある。現在は過渡的な状態であるのでSPFレコードを公開しないところが多いし、また、公開している場合も、「SPFにマッチしない場合もある」というような宣言（「~all」や「?all」など）をしている場合がある。それ故、SPFレコードにマッチしなかったら即座に受信を拒否するという対応はできないし、するべきではないだろう。
また、スパム送信者もSPFレコードを公開している場合がある。認証に成功したからといってスパムメールではないとは限らない。そもそも送信ドメイン認証の目的は送信元のドメインを特定できるような仕組みを提供することである。その仕組みを使って送信ドメインを確定した後、そのドメインについての評価を行い、メールの処理を決定する。
●ホワイトリストとブラックリスト
あるドメインから送られてきたメールを正当なものとして受信する場合、そのドメインをホワイトリストに追加する。ホワイトリストとはそうした正当なメール（または受信したい）メールを送ってくるドメインをリストにしたものである。これに対してブラックリストとは受信したくないメールを送信するドメインのリストである。
どちらも送信ドメイン認証が生まれるよりももっと前から存在する技術である。しかし、送信ドメインは詐称可能であるため効果的に運用できなかった。送信ドメイン認証によって認証されたドメインに対しては安心してホワイトリストやブラックリストを適用できる。
例えば、送信ドメイン認証に成功したメールが、ホワイトリストに記録されているドメインから送られてきたとする。それは、信用できる既知のドメインから送られてきたことになるので、スパムフィルタなどの処理をする必要がなくなる。
●レピュテーション（Reputation）システム
インターネット上には膨大な数のドメインがあるので、それらをいちいちホワイトリストやブラックリストに追加していくのは効率がよいとはいえない。そこで、それぞれのドメインの評判をデータベース化し公開するシステムが必要になる。それがレピュテーションシステムである。
レピュテーションシステムは、送信ドメイン認証の普及が進むにつれて、次に必要なものになるだろうと考えられている技術である。すでにいくつかレピュテーション情報を公開している組織もあり、また、特定のベンダがレピュテーションシステムを構築し商用製品などで利用可能なものがある。だが、レピュテーションの処理についての標準化は、いまのところ大きな流れとなっていない。
sid-milterを使って受信側システムを構築する
ここからは実際にオープンソースのsid-milterを利用して受信側での送信ドメイン認証を実施する手順を説明する。sid-milterはオープンソースのsendmailのプラグイン（Milter）として利用できるソフトウェアで、sendmail MTAにSender IDおよびClassic SPFの認証の機能を追加できる（図2）。
オープンソース版sendmail 8.13.0以降か商用版Sendmail 3.1.6以降で動作する。次のURLからダウンロードできる。原稿執筆時点（2005年11月14日）でsid-milterの最新版は0.2.9である。
●sid-milterのビルド
sid-milterは、sendmailのlibmilerを必要とする。sendmail MTAのソースをダウンロードし、devtools/Site/site.config.m4に、
APPENDDEF(`confENVDEF',`-DMILTER')
を追加する（そのほかのオプションなども必要に応じて編集する）。TOPのディレクトリで「./Build」を実行してから、さらにroot権限で「./Build install」を実施する。次にlibmilterディレクトリに移動して「./Build」を実施し、コンパイルに成功したらroot権限で「./Build install」を実施する。
そして、いよいよsid-milterのコンパイルだ。まず、前述のWebサイトからソースをダウンロードして展開する。次に、sid-milter/Makefile.m4を編集するのだが、ポイントとなるはlibmilterのヘッダやライブラリのパスの指定とlibar（リゾルバのライブラリ）の利用の設定である。Linuxなどではlinkエラーが出るケースが報告されているので、そのような場合ではlibarを利用しないようにMakefile.m4のlibarの記述をコメントアウトする。
sid-milter/Makefile.m4を書き換えたうえで「./Build」を実行する。正常に終了すれば、root権限で「./Build install」を実施する。sid-milterの実行ファイル名はsid-filterである。以下利用法を説明する場合はsid-filterと記述する。
●sendmailの設定
sid-filterをsendmail MTAと接続する設定をsendmail.cfにて行う。利用しているm4ファイルに例えば以下のように設定し、sendmail.cfを作成する。
INPUT_MAIL_FILTER(`sid-filter',`S=local:/var/run/sid-filter')dnl
●sid-filterの起動
sid-filterの起動パラメータを表1に示す。図1で示したサイト構成での利用を考えた場合、sid-filterを運用するのはゲートウェイMTA上である。ゲートウェイMTA上でsendmailとsid-filterを利用可能にしたうえでsid-filterを次のように起動してみる。内部ネットワークから送られてくるメールについては、認証しないよう設定する。
# sid-filter -p local:/var/run/sid-filter -a 192.168.1.0/24 -h -t
上記の設定ではsid-filterは試験モードで動作するため、送信ドメインの認証処理の結果によってメールを受信拒否することはない。ただし、認証の結果はヘッダに記録する。
| オプション | 値 | 説明 | |
|---|---|---|---|
| -a | ピアリスト | 認証対象にしないサーバ(例えば社内のサーバやネットワークなど）を指定する。ホスト名、ドメイン名やCIDR表記のIPアドレスを指定できる | |
| -A | 自動リスタート設定、なにか障害が発生しフィルタが停止すると、自動的に再起動する | ||
| -d | ドメイン名 | 認証対象にしないドメインを指定する。「,」で複数並べて指定できる | |
| -f | デーモンとして実行せず、フォアグランドで実行させる（デバッグ用など） | ||
| -h | sid-filterで処理したことを示すヘッダをメールに追加する。プログラム名やバージョンなどが含まれる | ||
| -l | syslogにログする | ||
| -p | ソケット指定 | milterがリスンするソケットポートを指定する。UNIXドメインソケットの場合は「local:/var/run/sid-filter」のように「local:」をつけて指定し、INETソケットの場合は「inet:9000@127.0.0.1」のように「inet:ポート番号@ホスト名（またはIPアドレス）」の形式で指定する。このオプションは必須である | |
| -P | pidファイル | sid-filterのプロセスIDを記録するファイルの名称を指定する | |
| -r | 処理レベル | 認証結果に対してsid-filterのアクションをレベルで指定する 0：すべてのメールを受信する 1：SenderIDとSPFの認証結果の両方が「fail」の場合メールを永続的に(5xxで)受信拒否する 2：SenderIDかSPFのどちらかの認証結果が「fail」の場合メールを永続的に(5xxで)受信拒否する 3：SenderIDかSPFのどちらかの認証結果が「pass」ではない場合メールを永続的に(5xxで)受信拒否する 4：SenderIDかSPFの両方の認証結果が「pass」ではない場合メールを永続的に(5xxで)受信拒否する |
|
| -t | 試験モード。(PRAが判断できない場合も含めて）メッセージを受信拒否しない | ||
| -T | 秒数 | DNSのタイムアウトを指定する。0の場合はタイムアウトしない。デフォルト値は5である。OSのリゾルバを利用した場合は、タイムアウトを指定できない | |
| -u | ユーザーID | 実行ユーザーID | |
| -V | バージョン番号などを表示する |
Copyright © ITmedia, Inc. All Rights Reserved.