dk-milterの起動とsendmail MTAの設定
dk-milterを起動してみよう。起動時オプションについては表3にまとめた。
| オプション | 説明 | |
| -a | dk-filterの処理対象にしないホストの一覧ファイルを指定する | |
| -A | 障害発生時に自動的にフィルタをリスタートする | |
| -b | modes 動作モードを指定する 署名のみを実施 s 認証のみを実施 v 両方実施する sv |
|
| -c | 正規化方法を指定。「simple」と「nofws」のどちらかを指定する | |
| -C | 認証結果に従ってメールに対するアクションをresult=actionの形式で指定する resultには次の値を指定する badsignature（bad） 署名は存在したが認証できなかった dnserror（dns） DNSから公開鍵を取得できなかった internal（int） 何らかの内部エラーが発生した nosignature（no） 署名が存在しない signature-missing（miss） すべてのメッセージに署名をすると宣言したドメインからのメールに署名がない actionには次の値を指定する accept（a） 受信する discard（d） 受信するが廃棄する tempfail（t） 一時エラーを返す reject（r） 受信拒否する |
|
| -d | 署名対象の送信ドメインを指定する | |
| -D | "-d"で指定された送信ドメインのさらにサブドメインを送信ドメインとするメールに対しても署名を実施する | |
| -f | 起動後、デーモンとしてではなく、フォアグランドのプログラムとして動作する | |
| -h | dk-milterのバージョンなどを表示するヘッダをメッセージに追加する | |
| -H | 署名に含まれているヘッダのリストを署名ヘッダに追加する | |
| -i ilist | 署名を実施する対象になるメールを送信してくるホストのリストを含むファイルを指定する。省略時の値は「127.0.0.1」 | |
| -l | syslogを利用する | |
| -m mta | 署名を実施するMTAのポート名（DaemonPortOptionsに指定される）を指定する。対応するポートから受信したメールに対して署名する | |
| -o header | 署名対象から除外するヘッダを指定する | |
| -p | sendmail MTAとの通信に利用するソケットを指定する | |
| -P pidfile | プロセスIDを保存するファイルのファイル名 | |
| -s keyfile | 署名に利用するPEM形式の暗号鍵ファイルを指定する | |
| -S selector | DomainKeysの署名でのセレクタを指定する | |
| -T | DNSのタイムアウト時間を指定する。0を指定すると永久に待つ。デフォルトは5 | |
| -u userid | プロセスの実行UID | |
| -U popdb | Pop before SMTPで認証されたコネクションからのメールについて署名する場合に認証されたコネクションを保持するDBファイルを指定する。この機能はコンパイル時に有効にしておく必要がある | |
| -V | バージョン番号などを表示する | |
| 表3 dk-milterの起動オプション | ||
dk-milterはmilterなので起動してもsendmail MTAからアクセスがあるまで実際に署名や認証の処理を行わない。つまり、sendmail MTA側でdk-milterに接続する設定が必要である。ここでは、/var/run/dk-filter.sockというUNIXドメインソケットでsendmail MTAと通信するように起動する。
例のように「-H」オプションを利用すると、認証対象にしたヘッダが「h=」タグにリストされ電子署名の破壊を防ぐ可能性が高くなる。
# /usr/bin/dk-filter -h -H -l -p /var/run/dk-filter.sock -d sm-ex.co.jp -s /etc/mail/certs/k1.private -S k1
一方、sendmail MTAではm4ファイルに次の行を加えてsendmail.cfを作成する。その後、sendmail MTAを再起動すると署名と認証処理が開始される。
INPUT_MAIL_FILTER(`dk-filter', `S=local:/var/run/dk-filter.sock')dnl
認証結果
認証結果はSender IDなどと同じく「Authentication-Results:」ヘッダとして記録される。認証結果は「domainkeys=pass」のような形で表示される。
DomainKeysでは認証後のメールの扱いについて、認証に失敗したものはサイトポリシーを考慮して扱うとあるが、基本的に受信側のポリシーに任せられる。また、ドラフトではエンドユーザーに対して認証結果を「pass」か「fail」のどちらかで表示すべきとされている。
ただし、dk-milterの実装では、「From:」や「Sender:」ヘッダが存在しない場合には「permerror」という結果に、公開鍵が存在しない場合には「neutral」という結果が与えられるようになっている。また、「-C」オプションによって認証結果に従ったメールの処理（受信、廃棄、一時受信拒否など）がより細かく指定できるようになっている。
Authentication-Results: mx.sm-ex.co.jp from=xxxx@xxxxxx.co.jp; domainkeys=pass (testing)
送信ドメイン認証の今後
今日、GmailやYahoo!メールから送られたメールのヘッダを見ると、当然のことであるが「DomainKey-Signature:」ヘッダが付与されている。国内の大手ISPなどでもDomainKeysをサポートする予定が発表されているので、送受信ともにますます利用が拡大していくと考えられる。
しかし、メーリングリストにおける問題点などのように電子署名方式だけではカバーしにくい部分もあるため、Sender IDやClassic SPFと併用し、お互いの短所を補うような形式で利用するとより信頼性の高い運用ができるだろう。
さらに、メールに電子署名を行うDomainKeysはフィッシィング詐欺対策としての効果も見込まれるので、メールを実際のビジネスにおける不可欠なインフラとして利用しているような場合は特に導入する価値があるだろう。
Profile
末政 延浩
テクニカルディレクター
ISPや企業のメールシステムの構築およびコンサルティングに従事。インターネット電子メールシステムの安全性を高めるため送信ドメイン認証技術の利用の拡大を望む
Copyright © ITmedia, Inc. All Rights Reserved.