milter managerを導入することによって得られる以下のメリットの理由を説明します。
milterに関する知識がない読者でも読み進められるようにmilterの説明からはじめます。
milterとはmail filterの略で、Sendmailが開発したメールフィルタプラグインの仕組みです。milterを使うことにより、Sendmail本体を変更せずに、迷惑メールフィルタやウィルスチェックなどの機能をSendmailに組み込むことができます。また、一度に複数の機能を組み込むことができるため、機能を組み合わせることで、より効果的なメールフィルタ機能を実現できます。
Sendmailとmilterの関係を図示して整理する前に、用語の整理をします。
「milter」という単語は、「メールフィルタプラグインの仕組み」という意味以外にも、「メールフィルタプラグイン」という意味でも使われます。ここでは、混乱を避けるために以下のように使い分けます。
milterはSendmailとは別プロセスで動作し、milterとSendmailは独自のプロトコルで通信を行います。このプロトコルのことを「milterプロトコル」と呼ぶこととします。また、Sendmailがmilterに接続し、milterプロトコルで通信を行い、milterとの接続を切断するまでを「milterセッション」と呼ぶこととします。
これらの用語を用いたSendmailとmilterの関係は以下の通りです。
Sendmailとmilterの関係
Sendmailがmilterシステムを提供してから、多くのmilterが開発されています。https://www.milter.org/というサイトでは登録されているmilterを探すことができます。2008年12月時点では62個のmilterが登録されています。milter.orgに登録されていないmilterも多くあり、実際には100以上のmilterが開発されていると思われます。例えば、以下のようなmilterです。
また、新しい迷惑メール対策をmilterとして実装する場合も多く、これからもmilterは増えていくと思われます。
もともと、milterシステムはSendmail専用の仕組みでしたが、Postfixもバージョン2.3からmilterシステムのサポートを始めました。これにより、SendmailでもPostfixでも利用可能なメールフィルタを作成することができるようになり、milterの再利用性が向上しました。
SendmailとPostfixとmilterの関係
SendmailとPostfixのようにmilterシステムをサポートしているMTAであれば、MTAによらずmilterを利用できますが、milterを登録する方法やmilterの設定方法はMTA毎に異なります。せっかくSendmailとPostfix間で同じmilterを利用できるようになったのですが、効率的・効果的にmilterを組み合わせるノウハウは共有できません。
迷惑メール対策手法は数多く考案されています。しかし、ある手法1つですべての迷惑メールに対応できるわけではないため、複数の手法を組み合わせて対応する必要があります。そして、多くの手法はなんらかの欠点を抱えています。例えば、誤検出はないが検出率が低い、検出率は高いが処理時間が長い、検出率は高いが負荷が大きいなどです。
現在のように様々な種類の迷惑メールが大量に送信されているインターネット上では、手法の長所を活かしつつ、欠点を補うように利用する必要があります。
手法は大きく接続ベース手法と内容ベース手法に分けられます。接続ベース手法は、メールの内容は使わず、接続元ホストや差出人、宛先などの情報で迷惑メールかどうかを判断する手法です。内容ベース手法はメールの内容を解析して迷惑メールかどうかを判断する手法です。
接続ベース手法は検出率もよく、内容ベース手法よりも負荷が軽いことが多いです。しかし、Gmailなどのような普通のメールサーバから送信されている迷惑メールの多くは検出することができません。しかし、内容ベース手法を用いることにより、接続ベース手法を回避した迷惑メールを検出することが可能です。
このような手法の特徴を反映して、2008年12月時点では以下のような迷惑メール対策が主流になっています。
接続ベース手法は、メールを再送させることにより迷惑メール送信者からきたメールかどうかを判断するGreylistingや、迷惑メール送信者データベースに載っているかどうかで判断するブラックリスト方式などがあります。商用製品のブラックリスト方式では独自のデータベースを利用することが多くあります。フリーソフトウェアでの実装ではDNSBLと呼ばれるDNSのインターフェイスを利用したデータベースを利用することが多いです。また、データベースを使用せず、数種類の正規表現で迷惑メール送信者を検出するS25R（SelectiveSMTP Rejection）という手法もあります。
GreylistingやDNSBLを用いる場合は、メールの再送やネットワーク通信が行われるため、負荷は高くないもののメールの遅延や処理時間の増加が起こりえます。そのため、明らかに怪しくない送信者やほとんど怪しくない送信者の場合はGreylistingやDNSBLを省略することにより、メールの遅延や処理時間の増加を抑えることができます。
S25Rは、負荷も軽く処理時間も短く検出率もよく優秀な方法なのですが、誤検出を救済する手段がない、ホワイトリストをメンテナンスする必要があるといった欠点があります。一方、Greylistingでは一見怪しい送信者でもメールを再送してくれば、自動的に一定期間ホワイトリストに登録するので、メンテナンスのコストはありません。
これらの手法の長所を活かしつつ、欠点を補いながら利用するためには以下のような利用方法があります。
この方法では、S25RとDNSBLで怪しいと判断された接続に対してのみGreylistingを適用します。そのため、迷惑メール送信者以外からのメールに対して再送要求をして配送遅延するという欠点が起きる確率を減らしています。また、S25Rで必要とされるホワイトリスト管理などのメンテナンスはGreylistingで自動的に行われるため、S25Rの欠点といえるメンテナンスコストを解消することもできます。
このように、それぞれの手法は組み合わせ方を工夫すれば、より効率的に利用することができます。
迷惑メール対策の手法はmilterとして実装されています。それでは、milterを効率的に組み合わせるためにはSendmail、Postfixにどのような設定を行えばよいでしょうか。
Sendmail、Postfixともに、milterを適用する設定を行うと、すべてのメールに対してmilterが適用されます。そのため、前述のように特定の条件のときのみmilterを適用するということはできません。FIXME
また、Sendmailではmilter毎に接続に失敗した時のアクションやタイムアウト時間の設定ができるのに対して、Postfixではmilter全体の設定となります。
milterはすでに多くの実装が開発されているという点、複数のMTAで迷惑メール対策手法の実装が共有できるという点で有用です。しかし、MTAでmilterの適用を柔軟に設定できないことやMTA間での設定方法の違いから、そのような利点を活かしきれていません。
そのようなmilterの利点をより活かすためのフリーソフトウェアがmilter managerです。
milter managerは複数のmilterを管理するmilterです。milter managerには複数のmilterを登録することができ、milter managerに対するmilterセッションは登録された複数のmilterに転送されます。milter managerに登録されたmilterのことを「子milter」と呼ぶこととします。
つまり、milter managerは1種のプロキシとして動作します。MTAから見ると、milter managerは1つのmilterです。一方、子milterから見ると、milter managerからはMTAのように見えます。
MTAとmilter managerと子milter
このような構成にすることで、各MTA毎に異なっていたmilter管理部分をmilter managerの層で行えます。milter managerは以下のようにmilter管理機能を強化する機能を提供します。
前者は「milter管理コストを減らすことができる」というメリットにつながり、後者は「milterを柔軟に組み合わせることができる」というメリットにつながります.
milter managerのこの2つの機能により、milterの利点をより活かすことができます。
milter managerはRubyインタプリタを内蔵しています。Rubyは読みやすい文法と柔軟性を兼ね備えた本物のプログラミング言語です。
設定ファイルはRubyプログラムとして処理されるため、既存のMTAに比べてより柔軟にmilterの設定を行うことができます。例えば、システムにインストールされているmilterを検出して、動的にmilterの設定を行うことができます。つまり、milter managerの設定を行わなくても、milterの設定を変更するだけで、milter manager側でそれを検出して対応できるということです。
現在のところ、Ubuntu上でパッケージからインストールしたmilter、FreeBSD上でportsからインストールしたmilterを使っている場合においては、設定ファイルを一切変更する必要はありません。milterをインストールすれば、milter managerが検出し、利用します。詳しくはインストールを見てください。
設定ファイルがRubyプログラムになるため、MTAでmilterを登録する場合よりも難しくなるのではないかという意見があります。前述の通り、Rubyは読みやすい文法を提供するプログラミング言語なので、通常に使用している限りは難しくなることはありません。FIXME
例えば、接続ソケットを指定する場合は以下のように設定しますが、この書式はPostfixの設定ファイルでの書式（「設定項目 = 値」）とほとんど変わりません。
manager.connection_spec = "inet:10025@localhost"
また、設定ファイルを直接編集しなくても設定を変更できるWebインターフェイスも提供するため、柔軟なだけではなく、より簡単に設定を行うことができます。（次のリリースから収録予定）
MTAの設定では、milterは適用するか適用しないかのどちらかの選択肢しかありません。特定の条件のみmilterを適用するということができません。
milter managerは処理の途中にいくつかチェックポイントを用意しています。このチェックポイントに必要な処理を組み込むことにより、特定の条件のときのみmilterを適用する、ということができます。
これにより、S25Rの結果から動的にmilterを適用するかどうかを判断することができます。
milter managerを間に入れることにより、多少、パフォーマンス面での影響があります。しかし、その影響はとても小さく、子milterの処理に比べればほとんどないといえます。そのため、miltermanagerがシステムのボトルネックになることはないでしょう。
また、milter managerに登録された子milterは特定の条件のときのみ実行することができます。つまり、必要の無い場合は子milterを実行しません。一方、MTAにmilterを直接登録すると、登録されたすべてのmilterが毎回実行されます。milterシステム全体の処理時間は、実行する総子milter数が減ることにより、milter manager導入前とほとんど同じ、あるいはより短くなります。