このmilterは以降の処理を行わない。メールを受信拒否する。SMTPレベルでは500番台の受信拒否になる。メールを一時受信拒否する。SMTPレベルでは400番台の受信拒否になる。メールを受信するが、配送せずにそのまま廃棄する。このmilterは以降の処理を行わない。メールを受信するが、配送はしない。messageステージのときしか使えない。)以下のようなメッセージ変更機能があります。メールフィルターとしては十分な機能です。本文変更ヘッダー追加ヘッダー削除ヘッダー変更それでは、以下、実例を元に実際の動作を確認します。fromでaccept実例は5つ用意しましたが、ここでは1つだけ紹介します。他はスライドやUstreamの録画を観てください。fromステージでacceptアクションを返した場合です。Authをしている場合は何も処理をしないmilterが多くあります。その場合はこのような動作になります。fromステージでacceptアクションを返すmitlerはRubyで実装するとこのようになります。これはスライドのアーカイブの中のmilters/milter-accept.rbに入っています。TOコマンドを送ったらどうなるでしょうか。この場合、milterはacceptを返しているのでメールを受信します。TO以降のコマンドを送ってもmitler側では何も起こりません。それ以降のステージではメールサーバがmilterに通知しないからです。発表時には実際にSMTPを話しながら動作を確認しています。この様子はUstreamの録画を観てください。他の例もUstreamの録画やスライドページを見てください。managerが便利なところ例を使ってmilterの動作を確認した通り、milterを連携させることが難しいケースがあります。managerを使うことでそこを補うことができます。failを返した」という情報をmilter2で利用することができます。failはどのステージでも利用することができるので、もっと早い段階で情報を利用することができます。managerの利用例を1つ紹介します。他の利用例などはまた別の機会にでも紹介できるとよいですね。managerを使うことによってユーザ毎に迷惑メール対策方法を変えることができるシステムを構築することができます。MySQLにユーザ毎の設定を格納しておきます。managerが参照してmilterの挙動を動的に制御します。各milterがそれぞれMySQLの情報を参照するようなシステムにすることもできますが、そうすると、複数のmilterを使う場合に大変です。それぞれのmilterがMySQLに対応し、さらに、MySQL内の情報をどのように使うかを判断しなければいけません。managerを使うことにより、その部分を一括管理することができます。まとめ迷惑メールが多様化しているため、複数のmilterでそれに対応する必要があります。複数のmilterを利用した場合の挙動は少し複雑です。理解しがたいというものではなく、少し落ち着いて考えれば理解できるものなので、milterを利用する場合は一度くらいは落ち着いてmilterの挙動を確認しましょう。managerも一緒に導入するとより便利です。クリアコードではプログラミングが好きな開発者を2名募集中です。興味がある人は応募してみてください。よさそうな人を知っていたら教えてあげてください。クリアコードの開発者は全員オープンソースソフトウェアの開発に関わって磨いてきた技術力を持っています。オープンソースソフトウェアに関して技術的にお困りのことがあったらぜひご相談ください。milterに関することもOKです。その場だけで使う用のものや再配布用ではないものを抜いている。この「milter」はmilterの仕組みを使って実現されたメールフィルターそのもののこと。これもメールフィルターそのもののこと。milterの他のことも少し知らないとこれだけだとわからない。これもメールフィルターのこと。これ以降は注釈をつけませんがわかるはずです。SPFやGreylisting(グレイリスト)。SPFは迷惑メール対策にも使われることが多い。わかりやすさを重視したので、厳密には違う場合もあるので注意してください。managerで簡単迷惑メール対策お知らせです。managerを紹介します。managerと監視ソフトウェアZabbixがテーマです。同じ回で違う分野を扱うので、知識の幅が広がりやすいのがよいですね。「複数のmilterを同時に使ったときの挙動を理解できること」を目標に話す予定です。空いているようなので興味のある方は参加してみてください。FedoraやCentOSのRPMパッケージャーが書いた文章ではありません。FedoraやCentOSのRPMパッケージメンテナになりたい方はFedoraやCentOSが公式に配布している文書の方をお勧めします。FedoraProjectという文書があります。groongaを例にしてのRPM版のような内容です。5.4向けのRPMパッケージを作成し、それを提供するYumリポジトリを作成・公開する方法を紹介します。RPMパッケージの作成では、1つのspecファイルから複数のパッケージを作成します。この方法は、ライブラリを提供するソフトウェアの場合に多く用いられます。Yumリポジトリを登録するRPMも作成します。そのため、ユーザには以下のようにYumリポジトリを登録してもらうことになります。managerのリポジトリで公開されています。ここで紹介する方法でRPMパッケージ・Yumリポジトリを作成・公開する場合は参考にしてください。それでは、まずはパッケージの作り方です。パッケージの作り方RPMパッケージを作るためには.specを作ります。ここでは、複数のパッケージを生成する.specを作成するので、まず、どれをどのパッケージにいれるかを検討します。managerはmilterプロトコルを実装したライブラリ、それを利用したmilter管理アプリケーション、ユーティリティツールで構成されています。この場合、以下のように複数のパッケージに分解することが多いようです。ライブラリを使用しているソフトウェアを実行するために必要なファイルを提供するパッケージ。/usr/lib/libXXX.soなどを提供する。ライブラリを使用しているソフトウェアをビルドするために必要なファイルを提供するパッケージ。/usr/include/XXX/*.hなどを提供することが多い。libXXXに依存する。(ライブラリではなく)コマンドを提供するパッケージ。libXXXに依存する。managerの場合は以下のパッケージを作成することとします。/usr/lib/libmilter-client.soなどを提供する。/usr/include/milter-manager/milter/client.hなどを提供。libmilterとABI互換の/usr/lib/libmilter.soを提供する。libmilterとAPI互換の/usr/include/milter-manager/libmilter/*.hを提供する。milter-managerコマンドを提供する。managerの統計情報を収集するmunin-nodeのプラグインを提供する。複数のパッケージを作成する.specは以下のような内容になります。簡単ですね、とは言えないくらいの長さです*1。Environment/Daemons」など。「/usr/share/doc/rpm/GROUPS」に一覧がある。必要な分だけ書く%description詳細なパッケージの説明。複数行になってもOK。(「-n」の意味は「%package」と同じ)詳細なサブパッケージの説明。複数行になってもOK。-)(メイン)パッケージに含めるファイルを指定。-)サブパッケージに含めるファイルを指定。サブパッケージ名がなくなるだけで、基本的な記述は変わりません。managerの場合は以下のような.specになっています。%preやpostなどが増えていますが、これらは、それぞれインストール前・インストール後に実行するシェルスクリプトを指定しているだけです。長いので、詳細に興味がない場合は読み飛ばしてください。GNU/Linux上でCentOS用のRPMパッケージをビルドすることは茨の道です。そこで、CentOS用のchroot環境を作って、そこでビルドすることにします。することで、CentOSの実機がなくてもビルドできる上に、きれいな環境でビルドすることもできます。GNU/LinuxやUbuntuのchroot環境を作るにはdebootstrapが便利です。CentOSやFedoraのchroot環境を作るにはrinseが便利です。i386用のchroot環境を構築するには以下のようにします。...の前にあるRPMパッケージで利用するプラットフォームを指定している箇所はrinseのバグを回避するためです*2。GNU/Linux環境でi386のCentOS環境を作成することができません。/etc/fstabへの追記は、再起動する度にmountしなおすのが面倒だからです。この作業はbuild-in-chroot.shの中で自動化されています。chrootCentOSのchroot環境ができたら、その環境にビルド専用アカウントを作成し、そのユーザでビルドします。ここで紹介する作業はbuild-rpm.shの中で自動化されています。ここでは、その中の一部を説明します。ビルド用ユーザが存在しない場合はユーザを作成します。$USER_NAMEfi次に、そのビルド用ユーザが実行するビルドスクリプトを作成します。.tar.gzや.specなどのビルドに必要なファイルはchroot環境の/tmp/以下(/var/lib/chroot/centos-i386/tmp/以下)に事前にコピーしておきます。それぞれの処理内容はコメントとして説明しています。RPMパッケージのビルドは~/rpm/以下で行う。RPMパッケージ作成に必要なディレクトリを作成。同様のことができるよう。ソースと.specを配置。RPMパッケージ作成。rpm/SPECS/milter-manager.specEOFこのビルドスクリプトをビルド用ユーザで実行します。$BUILD_SCRIPTビルドが成功するとビルド用ユーザの~/rpm/RPMS/i386/以下にRPMパッケージができます*3。RPMパッケージができたら、それらに署名をします。署名RPMでは、パッケージに署名することによりパッケージ作成者のなりすましを防止することができます。署名の検証を無効にすることもできるので、署名なしのRPMパッケージでもYumリポジトリで公開・インストールすることはできますが、よほどの理由がない場合は署名をするべきでしょう。パッケージへの署名はパッケージ作成時にも作成後にも行うことができます。パッケージ作成後に行う場合はrpmコマンドの--resignオプションを使います。署名する鍵は_gpg_nameで指定します。XXX.rpmこれをそれぞれの.rpmに対して行います。RPMパッケージに署名したら、署名済みRPM使ってYumリポジトリを作ります。managerは安定版と開発版の2つのリリースラインがあります。そのため、以下のようなディレクトリ構成でYumリポジトリも2つ作ります。下の図のdevelopmentとstableがそれぞれYumリポジトリになります。x86_64ディレクトリを持ち、その下にビルドしたRPMパッケージを配置します。x86_64のそれぞれのディレクトリに対してcreaterepoコマンドを実行します。この作業はupdate-repository.shで自動化されています。$dirdonecreaterepoコマンドを実行するとそれぞれのディレクトリの下にrepodataというディレクトリが作成され、パッケージの情報が格納されます。これでYumリポジトリは完成です。HTTPでアクセスできるところにアップロードしてください。http://milter-manager.sourceforge.net/centos/以下でアクセスできるところにアップロードしたとすると、Yumのリポジトリ指定は以下のようになります。CentOS-$releaseverbaseurl=http://milter-manager.sourceforge.net/centos/$releasever/stable/$basearch/gpgcheck=1enabled=1gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-milter-managergpgkeyはRPMに署名した時に使ったキーの公開鍵が入ったファイルを指定します。公開鍵は以下のコマンドで出力できます。<kou@clear-code.com>"これを/etc/pki/rpm-gpg/RPM-GPG-KEY-milter-managerに置くことになります。Yumリポジトリを登録するためには以下の作業が必要になります。公開鍵の配置2段階にわかれているので面倒ですね。Yumリポジトリ登録の手間を軽減するために、「Yumリポジトリを登録するRPMパッケージ」を作りましょう。Yumリポジトリ登録RPMの作成ここで作成する「Yumリポジトリを登録するRPMパッケージ」はbuild-repository-rpm.shで自動化されています。Yumリポジトリ登録に必要なものは「リポジトリを指定するファイル」と「RPMパッケージを署名している公開鍵」の2つです。それらをアーカイブした.tar.gzがソースのパッケージを作成します。RPM-GPG-KEY-milter-manager.specはこのようになります。package.大事な部分はBuildArchitecturesと%postの部分です。このYumリポジトリ登録RPMはプラットフォームに関係なく使えるのでnoarchを指定しています。%postではRPMにも公開鍵を登録しています。GNU/Linux上でも作成できます。作成方法はCentOS上での方法と同じです。~/rpm/SPECS/milter-manager-repository.specこれで、~/rpm/RPMS/noarch/以下に.rpmができ、~/rpm/SRPMS/以下に.src.rpmができます。ここで作成したRPMが冒頭で紹介したRPMです。このRPMを使うことで以下のようにパッケージをインストールできるのでしたね。milter-managerYumリポジトリの公開ここまできたら、後はアクセスできる場所にアップロードするだけです。SourceForge.netではrsyncでアップロードできます。今回はhttp://milter-manager.sourceforge.net/centos/以下で公開したいので以下のようなコマンドになります。ktou,milter-manager@web.sourceforge.net:/home/groups/m/mi/milter-manager/htdocs/centosrsyncではパスの最後の「/」の有無に注意してください。まとめ以上がRPMパッケージの作成と作成したRPMパッケージをYumリポジトリで公開する手順です。managerのリポジトリで公開しています。読んでみてわかる通り、手順が多く、バージョンが上がる毎に手動で作業するのは大変です。簡単にバージョンアップに対応できるよう、自動化しておきましょう。Fedoraにはrpmdevtoolsパッケージに含まれているrpmdev-newspecで雛形を作れるようです。このバグを修正するパッチは作者に送りましたが、まだ取り込まれていません。src.rpmは~/rpm/SRPMS/以下にできます。4.0とGFDLのデュアルライセンスで自由に利用できます。クリアコードはプログラミングが楽しいソフトウェア開発者を1名募集しています。クリアコードは「クリアコードをいい感じにする人」を1名募集しています。クリアコードはフリーソフトウェア開発で培った技術力を提供しています。Thunderbird)とRubyとGroonga(全文検索)に関連した開発を得意としています。