クリアコードはプログラミングが好きなソフトウェア開発者を2名募集しています。
クリアコードはフリーソフトウェア開発で培った技術力を提供しています。特にMozilla製品（Mozilla FirefoxとMozilla Thunderbird）とRubyに関連した開発を得意としています。
注: FedoraやCentOSのRPMパッケージャーが書いた文章ではありません。FedoraやCentOSのRPMパッケージメンテナになりたい方はFedoraやCentOSが公式に配布している文書の方をお勧めします。例えば、How to create an RPM package - FedoraProjectという文書があります。
Debianパッケージの作り方と公開方法: groongaを例にしてのRPM版のような内容です。
ここでは、迷惑メール対策ソフトウェアmilter managerを例にしてDebian GNU/Linux上でCentOS 5.4向けのRPMパッケージを作成し、それを提供するYumリポジトリを作成・公開する方法を紹介します。RPMパッケージの作成では、1つのspecファイルから複数のパッケージを作成します。この方法は、ライブラリを提供するソフトウェアの場合に多く用いられます。
また、Yumリポジトリを登録するRPMも作成します。そのため、ユーザには以下のようにYumリポジトリを登録してもらうことになります。
Yumリポジトリを登録:
% sudo rpm -Uvh http://milter-manager.sourceforge.net/centos/5/milter-manager-repository-1.0.0-0.noarch.rpm
インストール:
% sudo yum install -y milter-manager
ここで紹介する方法を自動化するスクリプト群はmilter managerのリポジトリで公開されています。ここで紹介する方法でRPMパッケージ・Yumリポジトリを作成・公開する場合は参考にしてください。
それでは、まずはパッケージの作り方です。
RPMパッケージを作るためには.specを作ります。ここでは、複数のパッケージを生成する.specを作成するので、まず、どれをどのパッケージにいれるかを検討します。
milter managerはmilterプロトコルを実装したライブラリ、それを利用したmilter管理アプリケーション、ユーティリティツールで構成されています。この場合、以下のように複数のパッケージに分解することが多いようです。
milter managerの場合は以下のパッケージを作成することとします。
複数のパッケージを作成する.specは以下のような内容になります。簡単ですね、とは言えないくらいの長さです*1。
Summary: 簡単な説明
Name: （メイン）パッケージ名（「milter-manager」など）
Version: バージョン番号（「1.5.0」など）
Release: リリースバージョン（最初は「0{?dist}」にしておけばよい）
License: ライセンス（「GPLv3+」など）
URL: ソフトウェアのサイトのURL
（「http://milter-manager.sourceforge.net/」など）
Group: （メイン）パッケージが属するグループ
（「System Environment/Daemons」など。
「/usr/share/doc/rpm/GROUPS」に一覧がある。）
Source: ソースのアーカイブのURL
（「http://downloads.sourceforge.net/milter-manager/milter-manager-1.5.0.tar.gz」など）
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)
（常に↑でOK）
BuildRequires: ビルドに必要なパッケージ
BuildRequires: 必要な分だけ書く
Requires: 動作に必要なパッケージ
Requires: 必要な分だけ書く
%description
詳細なパッケージの説明。複数行になってもOK。
% package -n サブパッケージ名
（「-n」をつけないと「『パッケージ名』-『サブパッケージ名』」
というパッケージ名になるので、「libXXX」というパッケージ名を
つけるときは「-n」をつけないといけない）
Summary: サブパッケージの簡単な説明
Group: サブパッケージの属するグループ
% description -n サブパッケージ名
（「-n」の意味は「%package」と同じ）
詳細なサブパッケージの説明。複数行になってもOK。
%prep
%setup -q
%build
%configure オプション
（「--with-default-effective-user=milter-manager」など）
make %{?_smp_mflags}
% install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}
%clean
rm -rf %{buildroot}
%files
%defattr(-, root, root, -)
（メイン）パッケージに含めるファイルを指定。
%files -n サブパッケージ名
%defattr(-, root, root, -)
サブパッケージに含めるファイルを指定。
%changelog
* 日付 名前 <メールアドレス>
- (バージョン番号-リリース番号)
- new upstream release
1つの.specで1つのパッケージを作る場合は%package -n サブパッケージ名、%description -n サブパッケージ名、%files -n サブパッケージ名がなくなるだけで、基本的な記述は変わりません。
milter managerの場合は以下のような.specになっています。%preやpostなどが増えていますが、これらは、それぞれインストール前・インストール後に実行するシェルスクリプトを指定しているだけです。
そこそこ長いので、詳細に興味がない場合は読み飛ばしてください。
Summary: A milter to use milters effectively
Name: milter-manager
Version: 1.5.0
Release: 11%{?dist}
License: GPLv3+, LGPL3+, AGPL3+, GFDL, Public Domain
URL: http://milter-manager.sourceforge.net/
Group: System Environment/Daemons
Source: http://downloads.sourceforge.net/milter-manager/milter-manager-1.5.0.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)
BuildRequires: intltool
BuildRequires: gettext
BuildRequires: gcc
BuildRequires: make
BuildRequires: glib2-devel
BuildRequires: ruby
BuildRequires: ruby-devel
Requires: glib2
Requires: ruby
Requires: libmilter-toolkit = %{version}-%{release}
Requires(pre): /usr/bin/getent, /usr/sbin/useradd
Requires(pre): /usr/bin/id, /usr/sbin/groupadd
Requires(post): /sbin/chkconfig
Requires(preun): /sbin/service, /sbin/chkconfig
Requires(postun): /sbin/service, /sbin/chkconfig, /usr/sbin/userdel
%description
milter manager administrates milters instead of MTA to reduce milter
administration cost and combine milters flexibly.
%package -n libmilter-toolkit
Summary: A milter protocol library
Group: System Environment/Libraries
%description -n libmilter-toolkit
Both of client-side and server-side milter protocol are implemented.
This package contains the library files required for running services
built using libmilter-toolkit.
%package -n libmilter-toolkit-devel
Summary: Development files for libmilter-toolkit
Group: Development/Libraries
Requires: libmilter-toolkit = %{version}-%{release}
%description -n libmilter-toolkit-devel
This package contains the headers, and other support files
required for developing applications against libmilter-toolkit.
%package -n libmilter-compatible
Summary: libmilter API and ABI compatible milter library
Group: System Environment/Libraries
Requires: libmilter-toolkit = %{version}-%{release}
%description -n libmilter-compatible
A libmilter API and ABI compatible library based on libmilter-toolkit.
This package contains the library files required for running services
built using Sendmail libmilter or libmilter-compatible.
%package -n libmilter-compatible-devel
Summary: Development files for libmilter-compatible
Group: Development/Libraries
Requires: libmilter-compatible = %{version}-%{release}
Requires: libmilter-toolkit-devel = %{version}-%{release}
%description -n libmilter-compatible-devel
This package contains the headers, and other support files
required for developing applications against libmilter-compatible.
%package -n milter-manager-munin-plugin
Summary: Munin plugin for milter manager
Group: System Environment/Libraries
Requires: milter-manager = %{version}-%{release}
Requires: munin-node
%description -n milter-manager-munin-plugin
This package contains the munin plugin for munin-node.
%prep
%setup -q
%build
%configure \
--with-default-effective-user=milter-manager \
--with-default-effective-group=milter-manager \
--with-default-socket-group=smmsp \
--with-default-pid-file=/var/run/milter-manager/milter-manager.pid \
--with-default-connection-spec=unix:/var/run/milter-manager/milter-manager.sock
make %{?_smp_mflags}
%install
rm -rf %{buildroot}
make install DESTDIR=%{buildroot}
mkdir -p %{buildroot}%{_initrddir}
install -m 755 data/init.d/redhat/milter-manager %{buildroot}%{_initrddir}/milter-manager
mkdir -p %{buildroot}%{_sysconfdir}/sysconfig
install -m 644 data/init.d/redhat/sysconfig/milter-manager %{buildroot}%{_sysconfdir}/sysconfig/milter-manager
mkdir -p %{buildroot}%{_sysconfdir}/cron.d
install -m 600 data/cron.d/redhat/milter-manager-log %{buildroot}%{_sysconfdir}/cron.d/milter-manager-log
mkdir -p %{buildroot}%{_localstatedir}/run/milter-manager/
mkdir -p %{buildroot}%{_sysconfdir}/httpd/conf.d/
cat <<EOC > %{buildroot}%{_sysconfdir}/httpd/conf.d/milter-manager-log.conf
Alias /milter-manager-log/ /var/lib/milter-manager/public_html/log/
EOC
mv %{buildroot}%{_datadir}/milter-manager/munin/ %{buildroot}%{_datadir}/
mkdir -p %{buildroot}%{_sysconfdir}/munin/plugin-conf.d/
cat <<EOC > %{buildroot}%{_sysconfdir}/munin/plugin-conf.d/milter-manager
[milter_manager_*]
user milter-manager
env.logdir /var/lib/milter-manager/public_html/log
EOC
%clean
rm -rf %{buildroot}
%pre
if ! /usr/bin/getent group milter-manager &>/dev/null; then
/usr/sbin/groupadd -r milter-manager || \
%logmsg "Unexpected error adding group \"milter-manager\". Aborting installation."
fi
if ! /usr/bin/id milter-manager &>/dev/null; then
/usr/sbin/useradd -r -s /sbin/nologin -c 'milter manager' \
-d %{_localstatedir}/lib/milter-manager --create-home \
-g milter-manager milter-manager || \
%logmsg "Unexpected error adding user \"milter-manager\". Aborting installation."
fi
%post
/sbin/chkconfig --add milter-manager
/bin/mkdir -p /var/run/milter-manager
/bin/chown -R milter-manager:milter-manager /var/run/milter-manager
%post -n milter-manager-munin-plugin
/usr/sbin/munin-node-configure --shell | \
grep -e '\(milter_manager_\|\(postfix\|sendmail\)_processes\)' | \
sh
[ -f /var/lock/subsys/munin-node ] && \
/sbin/service munin-node restart > /dev/null 2>&1
:
%preun
if [ $1 -eq 0 ] ; then
/sbin/service milter-manager stop > /dev/null 2>&1
/sbin/chkconfig --del milter-manager
fi
%postun
if [ $1 -ge 1 ] ; then
/sbin/service milter-manager condrestart > /dev/null 2>&1
fi
if [ $1 -eq 0 ]; then
/usr/sbin/userdel -r milter-manager || \
%logmsg "User \"milter-manager\" could not be deleted."
fi
%postun -n milter-manager-munin-plugin
if [ $1 -eq 0 ]; then
rm %{_sysconfdir}/munin/plugins/milter_manager_* > /dev/null 2>&1
rm %{_sysconfdir}/munin/plugins/postfix_processes > /dev/null 2>&1
rm %{_sysconfdir}/munin/plugins/sendmail_processes > /dev/null 2>&1
[ -f /var/lock/subsys/munin-node ] && \
/sbin/service munin-node restart > /dev/null 2>&1
:
fi
%files
%defattr(-, root, root, -)
%doc ChangeLog ChangeLog.toolkit README README.ja NEWS NEWS.ja TODO
%doc %{_datadir}/milter-manager/license/
%doc %{_datadir}/gtk-doc/html/milter-manager/
%{_bindir}/milter-manager-log-analyzer
%{_sbindir}/milter-manager
%{_includedir}/milter-manager/milter/manager.h
%{_includedir}/milter-manager/milter/manager/
%{_libdir}/libmilter-manager.*
%{_libdir}/milter-manager/binding/
%{_libdir}/milter-manager/module/
%{_libdir}/pkgconfig/milter-manager.pc
%{_mandir}/man1/milter-manager.*
%{_mandir}/man1/milter-manager-log-analyzer.*
%{_mandir}/ja/man1/milter-manager.*
%{_mandir}/ja/man1/milter-manager-log-analyzer.*
%{_initrddir}/milter-manager
%{_datadir}/milter-manager/admin/
%{_sysconfdir}/milter-manager/cron.d/
%{_sysconfdir}/milter-manager/init.d/
%{_sysconfdir}/milter-manager/rc.d/
%{_sysconfdir}/cron.d/
%config %{_sysconfdir}/sysconfig/milter-manager
%config %{_sysconfdir}/milter-manager/milter-manager.conf
%config %{_sysconfdir}/milter-manager/defaults/
%config %{_sysconfdir}/milter-manager/applicable-conditions/
%config %{_sysconfdir}/httpd/conf.d/milter-manager-log.conf
%defattr(-, milter-manager, milter-manager, 0755)
%dir %{_localstatedir}/run/milter-manager/
%files -n libmilter-toolkit
%defattr(-,root,root)
%doc ChangeLog ChangeLog.toolkit README README.ja NEWS NEWS.ja TODO
%doc %{_datadir}/milter-manager/license/
%{_bindir}/milter-test-client
%{_bindir}/milter-test-server
%{_bindir}/milter-performance-check
%{_libdir}/libmilter-core.so.*
%{_libdir}/libmilter-client.so.*
%{_libdir}/libmilter-server.so.*
%{_mandir}/man1/milter-test-client.*
%{_mandir}/man1/milter-test-server.*
%{_mandir}/man1/milter-performance-check.*
%{_mandir}/ja/man1/milter-test-client.*
%{_mandir}/ja/man1/milter-test-server.*
%{_mandir}/ja/man1/milter-performance-check.*
%files -n libmilter-toolkit-devel
%defattr(-,root,root)
%doc ChangeLog ChangeLog.toolkit README README.ja NEWS NEWS.ja TODO
%doc %{_datadir}/milter-manager/license/
%doc %{_datadir}/gtk-doc/html/milter-manager/
%{_includedir}/milter-manager/milter/core.h
%{_includedir}/milter-manager/milter/core/
%{_includedir}/milter-manager/milter/client.h
%{_includedir}/milter-manager/milter/client/
%{_includedir}/milter-manager/milter/server.h
%{_includedir}/milter-manager/milter/server/
%{_libdir}/libmilter-core.so
%{_libdir}/libmilter-core.la
%{_libdir}/libmilter-client.so
%{_libdir}/libmilter-client.la
%{_libdir}/libmilter-server.so
%{_libdir}/libmilter-server.la
%{_libdir}/pkgconfig/milter-core.pc
%{_libdir}/pkgconfig/milter-client.pc
%{_libdir}/pkgconfig/milter-server.pc
%files -n libmilter-compatible
%defattr(-,root,root)
%doc ChangeLog ChangeLog.toolkit README README.ja NEWS NEWS.ja TODO
%doc %{_datadir}/milter-manager/license/
%{_libdir}/milter-manager/libmilter.so.*
%files -n libmilter-compatible-devel
%defattr(-,root,root)
%doc ChangeLog ChangeLog.toolkit README README.ja NEWS NEWS.ja TODO
%doc %{_datadir}/milter-manager/license/
%doc %{_datadir}/gtk-doc/html/milter-manager/
%{_includedir}/milter-manager/libmilter/
%{_libdir}/milter-manager/libmilter.so
%{_libdir}/milter-manager/libmilter.la
%{_libdir}/pkgconfig/libmilter.pc
%files -n milter-manager-munin-plugin
%defattr(-,root,root)
%doc ChangeLog ChangeLog.toolkit README README.ja NEWS NEWS.ja TODO
%doc %{_datadir}/milter-manager/license/
%{_datadir}/munin/
%config %{_sysconfdir}/munin/plugin-conf.d/
%changelog
* Thu Feb 17 2010 Kouhei Sutou <kou@clear-code.com>
- (1.5.0-11)
- new upstream release
* Thu Oct 29 2009 Kouhei Sutou <kou@clear-code.com>
- (1.4.1-0)
- new upstream release
* Thu Oct 13 2009 Kouhei Sutou <kou@clear-code.com>
- (1.4.0-0)
- new upstream release
* Wed Sep 16 2009 Kouhei Sutou <kou@clear-code.com>
- (1.3.1-0)
- new upstream release
* Wed Aug 12 2009 Kouhei Sutou <kou@clear-code.com>
- (1.3.0-0)
- new upstream release
* Fri Jul 17 2009 Kouhei Sutou <kou@clear-code.com>
- (1.2.0-0)
- new upstream release
* Fri Jul 03 2009 Kouhei Sutou <kou@clear-code.com>
- (1.1.1-0)
- new upstream release
* Tue Jun 02 2009 Kouhei Sutou <kou@clear-code.com>
- (1.1.0-0)
- initial 1.1.x development seriese release
* Thu Apr 16 2009 Kouhei Sutou <kou@clear-code.com>
- (1.0.0-1)
- initial stable release
Debian GNU/Linux上でCentOS用のRPMパッケージをビルドすることは茨の道です。そこで、CentOS用のchroot環境を作って、そこでビルドすることにします。こうすることで、CentOSの実機がなくてもビルドできる上に、きれいな環境でビルドすることもできます。
Debian GNU/LinuxやUbuntuのchroot環境を作るにはdebootstrapが便利です。CentOSやFedoraのchroot環境を作るにはrinseが便利です。
/var/lib/chroot/centos-i386/以下にCentOS 5.4 i386用のchroot環境を構築するには以下のようにします。
% sudo aptitude install -y rinse % sudo mkdir -p /var/lib/chroot/centos-i386/etc/rpm/ % sudo sh -c "echo i386-centos-linux > /var/lib/chroot/centos-i386/etc/rpm/platform" % sudo rinse --arch i386 --distribution centos-5 --directory /var/lib/chroot/centos-i386/
/etc/fstabに以下を追記:
/dev /var/lib/chroot/centos-i386/dev none bind 0 0 devpts-chroot /var/lib/chroot/centos-i386/dev/pts devpts defaults 0 0 proc-chroot /var/lib/chroot/centos-i386/proc proc defaults 0 0
本質的な部分はsudo rinse ...だけです。sudo rinse ...の前にあるRPMパッケージで利用するプラットフォームを指定している箇所はrinseのバグを回避するためです*2。これがないとamd64のDebian GNU/Linux環境でi386のCentOS環境を作成することができません。
/etc/fstabへの追記は、再起動する度にmountしなおすのが面倒だからです。
この作業はbuild-in-chroot.shの中で自動化されています。
CentOSのchroot環境ができたら、その環境にビルド専用アカウントを作成し、そのユーザでビルドします。ここで紹介する作業はbuild-rpm.shの中で自動化されています。ここでは、その中の一部を説明します。
まず、ビルド用ユーザが存在しない場合はユーザを作成します。
USER_NAME=milter-manager-build if ! id $USER_NAME >/dev/null 2>&1; then useradd -m $USER_NAME fi
次に、そのビルド用ユーザが実行するビルドスクリプトを作成します。.tar.gzや.specなどのビルドに必要なファイルはchroot環境の/tmp/以下（/var/lib/chroot/centos-i386/tmp/以下）に事前にコピーしておきます。それぞれの処理内容はコメントとして説明しています。
BUILD_SCRIPT=/tmp/build-milter-manager.sh VERSION=`cat /tmp/milter-manager-version` cat <<EOF > $BUILD_SCRIPT #!/bin/sh # RPMパッケージのビルドは~/rpm/以下で行う。 if [ ! -f ~/.rpmmacros ]; then cat <<EOM > ~/.rpmmacros %_topdir \$HOME/rpm EOM fi # RPMパッケージ作成に必要なディレクトリを作成。 # rpmdevtoolsパッケージに含まれているrpmdev-setuptreeコマンド # でも同様のことができるよう。 mkdir -p rpm/SOURCES mkdir -p rpm/SPECS mkdir -p rpm/BUILD mkdir -p rpm/RPMS mkdir -p rpm/SRPMS # ソースと.specを配置。 cp /tmp/milter-manager-$VERSION.tar.gz rpm/SOURCES/ cp /tmp/milter-manager.spec rpm/SPECS/ # RPMパッケージ作成。 rpmbuild -ba rpm/SPECS/milter-manager.spec EOF
このビルドスクリプトをビルド用ユーザで実行します。
chmod +x $BUILD_SCRIPT su - $USER_NAME $BUILD_SCRIPT
ビルドが成功するとビルド用ユーザの~/rpm/RPMS/i386/以下にRPMパッケージができます*3。
RPMパッケージができたら、それらに署名をします。
RPMでは、パッケージに署名することによりパッケージ作成者のなりすましを防止することができます。署名の検証を無効にすることもできるので、署名なしのRPMパッケージでもYumリポジトリで公開・インストールすることはできますが、よほどの理由がない場合は署名をするべきでしょう。
パッケージへの署名はパッケージ作成時にも作成後にも行うことができます。パッケージ作成後に行う場合はrpmコマンドの--resignオプションを使います。署名する鍵は_gpg_nameで指定します。
% rpm -D "_gpg_name Kouhei Sutou <kou@clear-code.com>" --resign XXX.rpm
これをそれぞれの.rpmに対して行います。
RPMパッケージに署名したら、署名済みRPM使ってYumリポジトリを作ります。
milter managerは安定版と開発版の2つのリリースラインがあります。そのため、以下のようなディレクトリ構成でYumリポジトリも2つ作ります。下の図のdevelopmentとstableがそれぞれYumリポジトリになります。各YumリポジトリはSRPMS, i386, x86_64ディレクトリを持ち、その下にビルドしたRPMパッケージを配置します。
.
+--- centos/
+--- 5/
+--- development
| +--- SRPMS/
| | +--- milter-manager-1.5.0-0.src.rpm
| | +--- ...
| +--- i386/
| | +--- CentOS/
| | +--- milter-manager-1.5.0-0.i386.rpm
| | +--- ...
| +--- x86_64/
| +--- CentOS/
| +--- milter-manager-1.5.0-0.x86_64.rpm
| +--- ...
+--- stable
+--- SRPMS/
| +--- milter-manager-1.4.1-0.src.rpm
| +--- ...
+--- i386/
| +--- CentOS/
| +--- milter-manager-1.4.1-0.i386.rpm
| +--- ...
+--- x86_64/
+--- CentOS/
+--- milter-manager-1.4.1-0.x86_64.rpm
+--- ...
このように.rpmを配置したらSRPMS, i386, x86_64のそれぞれのディレクトリに対してcreaterepoコマンドを実行します。この作業はupdate-repository.shで自動化されています。
for dir in centos/5/*/*; do createrepo $dir done
createrepoコマンドを実行するとそれぞれのディレクトリの下にrepodataというディレクトリが作成され、パッケージの情報が格納されます。
これでYumリポジトリは完成です。HTTPでアクセスできるところにアップロードしてください。
http://milter-manager.sourceforge.net/centos/以下でアクセスできるところにアップロードしたとすると、Yumのリポジトリ指定は以下のようになります。
/etc/yum.repos.d/milter-manager.repo:
[milter-manager] name=milter manager for CentOS-$releasever baseurl=http://milter-manager.sourceforge.net/centos/$releasever/stable/$basearch/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-milter-manager
gpgkeyはRPMに署名した時に使ったキーの公開鍵が入ったファイルを指定します。公開鍵は以下のコマンドで出力できます。
% gpg --export --armor "Kouhei Sutou <kou@clear-code.com>"
これを/etc/pki/rpm-gpg/RPM-GPG-KEY-milter-managerに置くことになります。
つまり、Yumリポジトリを登録するためには以下の作業が必要になります。
2段階にわかれているので面倒ですね。Yumリポジトリ登録の手間を軽減するために、「Yumリポジトリを登録するRPMパッケージ」を作りましょう。
ここで作成する「Yumリポジトリを登録するRPMパッケージ」はbuild-repository-rpm.shで自動化されています。
Yumリポジトリ登録に必要なものは「リポジトリを指定するファイル」と「RPMパッケージを署名している公開鍵」の2つです。それらをアーカイブした.tar.gzがソースのパッケージを作成します。
% tar cvzf milter-manager-repository.tar.gz milter-manager.repo RPM-GPG-KEY-milter-manager
.specはこのようになります。
Summary: milter manager RPM repository configuration
Name: milter-manager-repository
Version: 1.0.0
Release: 0
License: GPLv3+
URL: http://milter-manager.sourceforge.net/
Source: milter-manager-repository.tar.gz
Group: System Environment/Base
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)
BuildArchitectures: noarch
%description
milter manager RPM repository configuration.
%prep
%setup -c
%build
%install
%{__rm} -rf %{buildroot}
%{__install} -Dp -m0644 RPM-GPG-KEY-milter-manager %{buildroot}%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-milter-manager
%{__install} -Dp -m0644 milter-manager.repo %{buildroot}%{_sysconfdir}/yum.repos.d/milter-manager.repo
%clean
%{__rm} -rf %{buildroot}
%post
rpm -q gpg-pubkey-1c837f31-4a2b9c3f &>/dev/null || \
rpm --import %{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-milter-manager
%files
%defattr(-, root, root, 0755)
%doc *
%pubkey RPM-GPG-KEY-milter-manager
%dir %{_sysconfdir}/yum.repos.d/
%config(noreplace) %{_sysconfdir}/yum.repos.d/milter-manager.repo
%dir %{_sysconfdir}/pki/rpm-gpg/
%{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-milter-manager
%changelog
* Sat Feb 06 2010 Kouhei Sutou <kou@clear-code.com>
- (1.0.0-0)
- Initial package.
大事な部分はBuildArchitecturesと%postの部分です。
このYumリポジトリ登録RPMはプラットフォームに関係なく使えるのでnoarchを指定しています。
%postではRPMにも公開鍵を登録しています。
%post
rpm -q gpg-pubkey-1c837f31-4a2b9c3f &>/dev/null || \
rpm --import %{_sysconfdir}/pki/rpm-gpg/RPM-GPG-KEY-milter-manager
このYumリポジトリ登録RPMはDebian GNU/Linux上でも作成できます。作成方法はCentOS上での方法と同じです。
% echo "%_topdir $HOME/rpm" > ~/.rpmmacros
% mkdir -p ~/rpm/{SOURCES,SPECS,BUILD,RPMS,SRPMS}
% cp milter-manager-repository.tar.gz ~/rpm/SOURCES/
% cp milter-manager-repository.spec ~/rpm/SPECS/
% rpmbuild -ba ~/rpm/SPECS/milter-manager-repository.spec
これで、~/rpm/RPMS/noarch/以下に.rpmができ、~/rpm/SRPMS/以下に.src.rpmができます。
ここで作成したRPMが冒頭で紹介したRPMです。このRPMを使うことで以下のようにパッケージをインストールできるのでしたね。
% sudo rpm -Uvh http://milter-manager.sourceforge.net/centos/5/milter-manager-repository-1.0.0-0.noarch.rpm % sudo yum install -y milter-manager
ここまできたら、後はアクセスできる場所にアップロードするだけです。SourceForge.netではrsyncでアップロードできます。今回はhttp://milter-manager.sourceforge.net/centos/以下で公開したいので以下のようなコマンドになります。
% rsync -avz --exclude .gitignore centos/ \
ktou,milter-manager@web.sourceforge.net:/home/groups/m/mi/milter-manager/htdocs/centos
rsyncではパスの最後の「/」の有無に注意してください。
以上がRPMパッケージの作成と作成したRPMパッケージをYumリポジトリで公開する手順です。これら一連の手順を自動化したものはmilter managerのリポジトリで公開しています。読んでみてわかる通り、手順が多く、バージョンが上がる毎に手動で作業するのは大変です。簡単にバージョンアップに対応できるよう、自動化しておきましょう。
先日、LOCAL DEVELOPER DAY '10 WinterでRubyでmilterを作る方法について話してきました。どのタイミングでどのmilterプロトコルのコマンドが発行されるかについても説明しているので、Rubyではなく（libmilterを使って）Cでmilterを実装する場合にも参考になる部分があるはずです。むしろ、Rubyとmilterの組み合わせについて話している部分は薄めです。これは、Rubyそのものとmilterの仕組みを理解していればRubyとmilterを組み合わせることは容易だからです。
少しgroongaについてもふれています。
それでは、ダイジェストで資料の内容を紹介します。完全版はリンク先を見てください。資料のPDF・ソースもリンク先にあります。
具体的にRubyでmilterを作る話に入る前に、まず、前提となる知識を確認します。
はじめにメールフィルタ、次にメールフィルタの仕組みの1つであるmilterについて簡単に説明します。その後、一度milterから離れてSMTPについて説明します。これはmilterの動作を理解するためにはSMTPの動作も知っておく必要があるからです。SMTPの動作を確認したらそれをふまえてmilterの具体的な動作を説明します。
ここまできたらRubyでmilterを作るための下準備は整っているはずです。実際に1つRubyでmilterを作ってみます。
説明の途中にいくつか確認ポイントがあります。それぞれの技術は他の技術をベースになりたっているので、ベースとなっている技術をおさえていくことが、理解してしっくりくるためのコツです。
それぞれの確認ポイントをゴールとして最終的な「Rubyでmilterを作れる」ようになるゴールまでたどりついてください。
メールシステムとは外部とユーザ間でメールを配信するシステムです。すべてのメールシステムではそのままメールをやりとりするのではなく、メールを配信するまでのあいだに、メールに対してなんらかの処理を実行します。つまり、すべてのメールシステムにはメールフィルタ機能が備わっています。
メールシステムでメールフィルタを実現する方法はいくつかありますが、その1つがMTA（メールサーバ）のプラグインとして実現する方法です。この方法のメリットはMTAを変更せずにメールフィルタ機能を変更できることです。milterはこのタイプで動作するメールフィルタです。
メールフィルタはメールシステムが持っている必須機能の1つです。その実現方法としてMTAのプラグインとして実現する方法があり、milterもその方法で実現されているメールフィルタです。
それでは、milterの概要について説明します。
milterの名前の由来は「mail filter」です。milterは汎用的なメールフィルタの仕組みのため、同じメールフィルタを異なるMTAと一緒に使うことができます。
Sendmailを用いているメールシステムではmilterを利用していることが多く、milterをサポートした商用のメールフィルタも多く存在します。最近ではPostfixのmilterサポートがリリース毎に改善されていっているため、Postfixを用いたメールシステムでもmilterを利用するケースが徐々に増えています。
「milter」は文脈によって異なるものを指すことがあります。そこで、ここでは混乱を避けるために異なる名前で呼ぶことにします。
まず、メールフィルタそのものを「milter」と呼びます。
メールフィルタとMTAは別プロセスで動作するため、プロセス間通信でフィルタ対象のメールやフィルタ結果などをやりとりする必要があります。そのやりとりのきまりを「milterプロトコル」と呼びます。
そして、「milter」と「milterプロトコル」をサポートしたMTAを含んだメールフィルタの仕組み全体を「milterシステム」と呼びます。
「milter」といった場合は「メールフィルタそのもの（ここでいうmilter）」という意味で使う場合と、「メールフィルタの仕組み（ここでいうmilterシステム）」という意味で使われる場合が多いです。「milter」という単語が使われている場合はどちらの意味かを判断できるようになってください。
milterプロトコルはSMTPと密接に関連したプロトコルです。そのため、milterプロトコルについて説明する前に、SMTPについて確認します。
SMTPは以下の4つのコマンドが基本となるシンプルなプロトコルです。
まず、「HELO」で接続したSMTPクライアントの情報を伝えます。以下の例ではSMTPサーバ（MTA）からのメッセージは先頭に「<」をつけて示します。SMTPクライアントのメッセージは先頭に「>」をつけて示します。
% telnet localhost smtp < 220 note-pc.example.com ESMTP Postfix (Ubuntu) > HELO localhost.example.com < 250 note-pc.example.com
挨拶が済んだらSMTPセッションのスタートです。1つのSMTPのセッションで複数のメールを送ることができます。「MAIL FROM」、「RCPT TO」、「DATA」で1つのメールを送ります。
まず、「MAIL FROM」で送信者を伝えます。
> MAIL FROM: <kou@example.com> < 250 2.1.0 Ok
次に、「RCPT TO」で宛先を伝えます。
> RCPT TO: <info@example.com> < 250 2.1.5 Ok
同じメールを複数の宛先に送ることもできます。その場合は「RCPT TO」を複数回実行します。
最後に「DATA」でメールの内容を伝えます。メールの最後は「.」だけの行になります。
> DATA < 354 End data with <CR><LF>.<CR><LF> > Subject: Hello > From: <kou@example.com> > To: <info@example.com> > > This is a test mail! > . < 250 2.0.0 Ok: queued as 054C624FB
これで、1通のメールを送信できました。続けてメールを送信する場合はまた「MAIL FROM」から始めます。
SMTPセッションを終了する場合は「QUIT」です。
> QUIT < 221 2.0.0 Bye
これで1つのSMTPセッションが終了しました。
milterプロトコルはSMTPと密接に関わっています。それでは、milterプロトコルの詳細を説明します。
milterプロトコルにもSMTPと同じようにコマンドがあります。そして、そのコマンドはSMTPのコマンドと対応したものになっています。まずSMTPのコマンドを説明したのはそのためです。
例えば、SMTPで「HELO」というコマンドが実行された場合、「HELO」に対応する「helo」というmilterプロトコルのコマンドが発行されます。このとき、SMTPクライアントが指定したHELOコマンドの引数がmilterに渡されます。
MTAはmilterにコマンドを送った後、milterからの返答があるまでSMTPクライアントには返答しません。つまり、milterが「helo」でrejectを返すことで、SMTPクライアントの「HELO」コマンドへの返答をrejectとすることができます。これにより、MTAがSMTPレベルでできることとほとんど同じことをmilterで実現できます。
mitlerプロトコルのコマンドはほとんどSMTPのコマンドに対応していますが、milterプロトコルのコマンドの方がより細かくなっています。例と一緒にコマンドの対応を説明します。
SMTPでの最初のコマンドは「HELO」ですが、milterプロトコルでは「helo」よりも前にコマンドが発行されます。それが、SMTPクライアントがSMTPサーバに接続したときに発行される「connect」コマンドです。
「connect」コマンド以外はSMTPのコマンドとmilterプロトコルのコマンドは1対1で対応します。「envfrom」の「env」は「envelope」の略で、「封筒」という意味です。「envfrom」で「差出人」という意味、「envrcpt」で「宛先」という意味です。「rcpt」は「recipient」の略で「受信者」という意味です。
SMTPでは1つのメールを複数の宛先に送信できます。この場合、複数回「RCPT TO」を指定します。STMPで複数回「RCPT TO」が指定されるので、milterプロトコルでも「envrcpt」コマンドが複数回発行されます。
SMTPの「DATA」コマンドはmilterプロトコルではより細かいコマンドに分解されています。
まず、「DATA」コマンド時にはmilterプロトコルの「data」コマンドがすぐに発行されます*1。その後、SMTPクライアントはメール本体を送信しますが、「header」などのイベントはすぐには発生しません。SMTPクライアントがデータの終了を示す「.」のみの行を入力するまでは何も起きません。「.」のみの行が入力されると、MTA側でメール本文をパースして「header」、「eoh」（end of header: ヘッダーの終わり）、「body」、「eom」（end of message: メッセージの終わり）コマンドを発行します。もちろん、ヘッダーもパースしてあるので、MTAは「ヘッダー名」と「ヘッダー値」と分解した状態で情報を渡します。
このようにmilterプロトコルはSMTPと密接に関わっています。milterプロトコルのコマンドがわかれば、自分が必要な機能を持つmilterを実現するためにはどのコマンドを利用すればよいかを考えることができるでしょう。
説明用のサンプルとしてメール検索を実現するmilterを作成します。今回はSubject、From、Toと本文のみを扱うことにします。
メール検索を実現するために、全文検索エンジンとしてgroongaを、milterライブラリとしてmilter managerのRubyバインディングを使います。
groongaは全文検索のためのインデックス作成機能だけではなく、データストアの機能も持っています。groongaのデータストアはカラム指向で、リレーショナルデータベースとは違い、レコード（行）毎にデータをまとめて持つのではなく、カラム（列）毎にデータをまとめて持っています。
このようにデータを持つと、同じカラムの複数の値へのアクセスを高速に行うことができます。このため、カラムの値を使った集計処理を高速に実行できます。集計処理とは、例えば、SQLでいうGROUP BYのような処理です。
集計処理を用いると絞り込み検索をしやすいユーザーインターフェイスを提供することができます。例えば、ショッピングサイトで商品に複数のタグがついているとします。このとき、同じタグがついている商品が何項目あるかを表示してリンクにします。1つも商品が属していないタグは表示しないようにすれば、ユーザは無駄な絞り込み操作を行わずにすみます。
全商品（123件） タグ スポーツ（58件）← リンクにする 映画（45件） ← リンクにする 食べ物（36件） ← リンクにする 旅行（0件） ← 表示しない
この状態で「スポーツ」をクリックしたとします。
全商品（123件） > スポーツ（58件） タグ スポーツ ← 選択済みなので表示しない 映画（26件） ← リンクにする 食べ物（0件） ← 表示しない 旅行（0件） ← 表示しない
このように、絞り込んだ後にがっかりするような操作を示さないことにより、絞り込み検索をしやすいユーザインターフェイスを作ることができます。がっかりするような操作かどうかを判断するために、同じ値を持つレコードの個数を数える、といった集計処理をしています。
groongaはキー管理のためのデータ構造としてハッシュテーブルとバイナリパトリシアトライを採用しています。バイナリパトリシアトライはパトリシアトライの一種です。
ここにB+木とパトリシアトライの説明を書く予定でしたが、もう、だいぶ長くなっているので省略します。また別の機会があれば紹介します。
パトリシアトライを利用すると効率よく最長一致検索を実現できます。これを試してみるためのサンプルアプリケーションを用意しました。
リンク先ではキーワードを変えて試すことができます。
最長一致機能を利用してキーワード検出している部分のソースは以下の通りです。
target_text = "..." keywords = request["keywords"].split words = Groonga::PatriciaTrie.create(:key_type => "ShortText", :key_normalize => true) keywords.each do |keyword| words.add(keyword) end tagged_text = words.tag_keys(target_text) do |record, word| "<span class='keyword'>#{word}</span>" end
まず、パトリシアトライを作り、キーワードを登録します。Groonga::PatriciaTrieにはtag_keysという便利メソッドがあり、これを使うと「最長一致検索」→「キーワードにタグ付け」をより簡潔に記述することができます。
全体のソースはリンク先にあるソース一式の中に含まれています。
groongaのRubyバインディングであるRuby/groongaはスキーマ定義のためのDSLを提供しています。
メールを保存するMessagesテーブルにはsubject、from、to、bodyカラムを定義しています。今回は簡単のため、宛先は1つのみ扱うことにしています。
次に、高速に全文検索を行うために索引を作成します。Termsテーブルのキーに単語（ここではbigramを利用しているので1文字か2文字の文字列）、カラムにその単語が出現するMessagesレコードのID（とN-gramなので単語の出現位置）を保持します。
subjectカラムとbodyカラムでそれぞれに対して索引を作成しています。こうすることにより、「どこかに○○が含まれているメールを検索」といった検索だけではなく、「Subjectに○○が含まれているメールを検索」、「本文に○○が含まれているメールを検索」というような細かい検索ができるようになります。細かい検索が必要ない場合はMessagesテーブルに検索対象をすべて入れたカラムを1つ作り、そのカラムに対して索引を作成してもよいでしょう。
Groonga::Schema.define do |schema| schema.create_table("Messages") do |table| ... table.text("text") end schema.create_table("Terms", :type => :patricia_trie, :default_tokenizer => "TokenBigram", :key_normalize => true) do |table| table.index("text") end end messages = Groonga["Messages"] from = "kou@clear-code.com" to = "info@clear-code.com" body = "Hello Ruby and milter!" text = "#{from} #{to} #{body}" # <- textに検索対象をまとめる messages.add(:from => from :to => to, :body => body, :text => text) query = "Ruby" messages.select do |record| record["text"].match(query) # <- textカラムで全文検索 end
データの保存・検索の仕組みはできたので、あとは、groongaのデータベースにメールを登録するだけです。
milter managerのRubyバインディングのAPIでは、ユーザがmilterプロトコルのコマンドに対応するメソッドを定義し、ライブラリ側がそのメソッドを呼び出します。今回必要な情報はヘッダーと本文にあります。そのため、今回のmilterは以下のようになります*2。
class ArchiveMilter < Milter::ClientSession def initialize @messages = Groonga["Messages"] @values = {} @encoding = nil @body = "" end def header(context, name, value) case name when /\A(Subject|From|To)\z/i key = $1.to_s.downcase utf8_value = NKF.nkf("-w", value) @values[key] = utf8_value when /\AContent-Transfer-Encoding\z/i @encoding = value end end def body(context, chunk) @body << chunk end def end_of_message(context) nkf_option = "-w" nkf_option << " -MB" if @encoding == "base64" @values["body"] = NKF.nkf(nkf_option, @body) @messages.add(@values) end end
このように、Rubyでmilterを作るときは必要な処理の部分だけを記述するだけですみます。つまり、やりたいことを実現するためにどういうデータが必要で、どのタイミングでそのデータを手に入れられるかがわかれば、Rubyでmilterを作ることは簡単だということです。
登録したメールは以下のように検索・表示することができます。
query = "Ruby" # <- 検索キーワード messages = Groonga["Messages"] result = messages.select do |record| record["subject"].match(query) | record["body"].match(query) end result.sort([["_score", :desc]]).each do |message| puts "-" * 78 puts "score: #{message.score}" puts "Subject: #{message.subject}" puts "From: #{message.from}" puts "To: #{message.to}" puts puts message.body puts "-" * 78 end
Rubyでmilterを作る方法について説明しました。そのために必要な技術として、milterプロトコルの具体的な動作も説明しました。ここで説明されている内容を理解していれば、より詳細なmilter関連情報も理解しやすくなるでしょう。英語ですが、milterに関する情報はmilter.orgにまとまっています。より詳しい情報を知りたい場合はチェックするとよいでしょう。
札幌はやはりやさいい雰囲気に包まれていました。札幌Ruby会議02とは少し違う雰囲気でしたが、似ているとは感じました。
一度、札幌の人たちに会いに行ってみてはいかがでしょうか。
2010-02-14 - iakioの日記 - postgresqlグループ
「C言語でPostgreSQLを拡張する」というタイトルで石田さんが淡々とライブコーディングされていました。会場とやりとりをしながらコーディングする様子を見ていると、札幌っぽい雰囲気を感じることができるでしょう。
先日、milter managerを用いたメールフィルタリングについて話してきました。milter managerというより、milter managerがベースにしているmilterという技術についての説明の方に重点をおいています。これは、日本でのmilter情報が不足しているのを少しでも解消したいということからです。
milterはPostfixも積極的にサポートを強化している有用な技術の1つです。メールに関わっている方はその仕組みや動作について把握しておいて損はないはずです。
それでは、コメント付きでとばしとばし資料の内容を紹介します。完全版はリンク先を見てください。資料のPDF・ソースもリンク先にあります。
milterについて説明する前に、まず、より一般的なメールフィルタについてまとめておきます。その後、メールフィルタの仕組みの1つであるmilterについて説明し、最後にmilter managerも利用したmilterの使い方について説明します。
外部から届いたメールをユーザに配信するのがメールシステムです。メールシステム内部では単純に届いたメールをそのままユーザに配信するのではなく、なんらかの処理をしてから配信します。そのため、ユーザには加工されたメールが配信されます。例えば、Receivedというメールヘッダを追加したりします。
つまり、メールシステムの中にはメールフィルタの機能が内臓されています。それでは、メールフィルタについてもう少し詳しくみていきます。
メールフィルタの実現方法にはいくつかありますが、大きく以下の3種類に分けられます。
それぞれの方法について図で説明します。
MTAに組み込む方法では、MTA内にメールフィルタの機能を内蔵させます。MTA単体で実現できます。
例えば、Postfixではaccess(5)やcidr_table(5)を用いてフィルタを適用することができます。
MTAのプラグインとしてフィルタを実現する方法では、MTAと別のプロセスにメールを通すことによりフィルタリングします。この別のプロセスがフィルタプラグインです。milterもこのタイプのメールフィルタの仕組みです。
MTAとプラグインのやりとり方法はMTA独自のことがほとんどです。SendmailやPostfixなど複数のMTAで動くmilterの方が珍しいといえます。milterが複数のMTAでサポートされているのは、既に多くの有用なmilterが存在しているからと思われます。
複数のMTAでメールシステムを構築することもできます。フィルタMTAを挿入する方法では、外部からのメールをユーザに配信するまでの間に、フィルタリングをするMTAにメールをリレーすることで、メールフィルタリングを実現します。MTA間のやりとりにはSMTPを使うので、どのMTAでも実現できる方法です。
アプライアンス製品などはこの方法でメールフィルタ機能を提供することが多いです。
それでは、それぞれのメールフィルタの実現方法による違いです。それぞれ特徴があるので、必要とされている機能や導入した後のメンテナンスなども考慮して、メールシステム毎に適した方法を選択することが重要です。
MTAに組み込む方法の利点はお手軽であるということです。組み込まれている機能はMTA毎に違いますが、組み込まれた機能で十分な場合はこの方法を利用するとよいでしょう。機能を追加する場合は、パッチを当てたり、バージョンアップをしたりすることになります。機能を追加する場合はメンテナンスのことをよく考えてください。
MTAのプラグインとしてメールフィルタを利用する方法の利点は、柔軟性です。多くの場合、プラグインではMTA本体が実現していることのほとんどすべてを実現できます。そのため、必要な機能をMTA本体を変更せずに追加することができます。MTA組み込み方法よりは導入が面倒ですが、システムや世間の変化にあわせたメールシステムを構築する場合は、機能追加や複数の機能を組み合わせられるこの方法を利用するとよいでしょう。
フィルタMTAを挿入する方法の利点は、どのMTAでも利用できることです。フィルタMTAを挿入する場合は、MTAが数珠つなぎになります。そのため、MTAを挿入・削除するたびに複数のMTAのリレー設定を変更する必要があり、面倒です。もし、必要な機能をすべて満たしたフィルタMTAを1つ導入するのであれば、この方法がよいでしょう。複数のフィルタMTAを導入する場合は導入・メンテナンスのことをよく考えてください。
以上のことをふまえると、以下のポイントをメールフィルタの実現方法を選択するために使えます。
メールフィルタは迷惑メール対策に利用されることが多いです。その観点から考えるとどの方法がよいでしょうか。
迷惑メールの配信方法は多様化しているため、1つの対策で完璧に防ぐことはできません。複数の手法を組み合わせて対応する必要があります。
また、これからも新しい手法で迷惑メールは送られ続けるでしょう。そうなった場合でも新しい対策を適用できることが求められます。
よって、迷惑メール対策には、複数の機能を組み合わせることが容易で、新しく機能を追加できるプラグインタイプの方法が適しているといえます。プラグインタイプの中でも、複数のMTAで利用でき、すでに多くの実装が存在するmilterがオススメです。ということで、milterの説明に入ります。
「milter」といっても文脈によっては微妙に異なるものを指すことがあります。「広義の○○」「狭義の○○」といわれたりするものと同じようなものです。
「milter」はメールフィルタの仕組み全体のことを指す場合と、フィルタプログラムのことを指す場合が多いです。「milterに対応したMTA」という場合は「メールフィルタの仕組み」を指していますし、「このmilterを使う」という場合は「フィルタプログラム」のことを指しています。
milterの説明に入る前に、混乱しないように別々の名前をつけておきます。ただし、正式な名前ではないことに注意してください。あくまで、わかりやすさのためにつけた名前です。
それぞれの関係を図示するとこうなります。
MTAとmilter間でやりとりするmilterプロトコルはSMTPと密接に関わっています。milterプロトコルでのコマンドのほとんどはSMTPでのコマンドに由来しています。
例えば、MTAがSMTPで「EHLO」コマンドを受け取ったらmilterにも対応する「helo」コマンドが送られます。その時、EHLOで受け取ったFQDNも一緒に送られます。
また、milterプロトコルはSMTPと平行して動作するのも重要なポイントです。MTAがメッセージすべてを受信してからmilterにコマンドを送るのではないので、「helo」コマンドのときにmilter側でrejectすれば、MTAも「EHLO」コマンドのときにrejectし、「MAIL FROM」や「RCPT TO」などそれ以降のコマンドを受けとりません。
milterシステムでは複数のmilterを同時に利用することができます。複数のmilterを利用する場合もSMTPと平行して動作する点は変わりません。
複数のmilterを利用する場合に注意することは、それぞれのmilterはコマンド毎に順番に動くということです。1つめのmilterの処理が終わってからはじめて2つめのmilterにコマンドが送られます。
1つめのmilterの処理結果が2つめのmilterに影響を与えます。例えば、1つめのmilterで本文を変更したら、2つめのmilterには元の本文ではなく1つめのmilterが変更した本文が渡されます。DKIMなどメッセージが変更されると問題があるような処理をする場合はmilterの順序に気をつけてください。
例えば、DKIMの場合は、送信するメールの署名も受信したメールの署名の検証も一番外部に近い部分で行います。署名を行うmilterは、他のすべてのmilterが処理を終わった後に適用しなければ署名が壊れてしまうため、一番最後のmilterにします。署名を検証するmilterは、他のmilterがメッセージを変更する前に適用しなければ検証に失敗してしまうため、一番最初のmilterにします。
以上がmilterの動作です。それでは、milterの使い方について進みます。
milterシステムを使い込んでいくといくつか気になるところがでてきます。milterシステムはプラグインタイプなので他の方法に比べて機能の追加は容易ですが、さすがにmilterの数が増えてくると面倒になります。
milterはすべてのセッションに対して適用されます。ホワイトリストの管理は各milterの役割になります。しかし、複数のmilterを利用している場合は、複数の形式でホワイトリストを管理することになりメンテナンスが面倒になります。
これらの問題点を解決するソフトウェアがmilter managerです。
milter managerはMTA側に足りない機能を補って、milterをより使いやすくするソフトウェアです。MTA・milterどちらにも変更を加えずに導入することができるため、既存の環境を壊すことなく導入できます。
クリアコードの他のソフトウェアと同様、milter managerもオープンソースソフトウェアとして公開しているので自由に利用することができます。
milter managerはMTAとmilterの間で動作します。MTAからのmilterプロトコルのコマンドをmilterに転送し、milterからのレスポンスをMTAに転送します。MTAとmilterの間でやりとりを制御することができます。
milter managerはmilterとして実装されているため、MTAには1つのmilterとしてみえます。また、milter managerはMTA側のmilterプロトコルも実装していて、その機能を使ってmilterへコマンドを転送しています。よって、milterからはmilter managerがMTAのようにみえます。このため、MTAもmilterも変更なしでそのまま動作することができるのです。
milterシステムの設定・管理にいくつか作業が必要になります。
milterを追加する場合は、milter本体を設定した後にMTAにmilterを登録する必要があります。複数のmilterを同時に利用している場合はmilter本体の設定のみをして、MTA側に登録することを忘れてしまうこともあります。
milter managerはそのような部分を自動化し、単純なミスを防ぎます。/etc/以下を走査し、インストールされているmilterを検出したら自動で登録します。また、インストールはされているが無効にされている場合もそれを検出し、自動でそのmilterを使用しないようにします。
milterシステムは複数のMTAでサポートされていますが、完全に同じサポート状況ではなく、MTA毎に異なる部分があります。そのため、milterによってはSendmailでは動くが、Postfixでは動かないというのもありました。（最近はそのようなmilterは減ってきています。）
milter managerはMTAとmilterの間で動作します。その位置でSendmailとPostfixのmilterシステムのサポートの違いを吸収するため、同じmilterを変更せずにそのまま動作させることができます。
他にも、Sendmailはmilter毎にタイムアウトなどのパラメータを設定できるが、Postfixはmilter全体の設定なってしまうなどといった違いがあります。このような違いも、milter managerがmilter毎にパラメータを管理することにより、PostfixでもSendmailと同じようなmilterシステムサポートを利用することができます。
このようにmilter managerを導入することにより、milterシステムの管理が負担を減らすことができます。milter managerはMTAとmilterの間に入って動作するため、MTA・milterのどちらも変更せずにmilterシステムのサポートをより充実させることができます。このため、メールシステム全体の管理の負担も減ります。
前述の通り、milterはすべてのメールに対して適用されるため、milter全体でホワイトリストを共有したり、ユーザ毎に適用するmilterを選択することが面倒になります。それぞれのmilterにまたがって設定をする必要があります。
milter managerを使うとこの問題を解決することができます。MTAはすべてのmilterを適用しますが、milter managerはSMTPセッションの情報を使って動的に適用するmilterを選択する機能を提供しています。また、LDAPやRDBなどからもデータを取得することができるため、メールシステム外にあるアカウントシステムと連携した制御をすることもできます。
この機能を使うことにより、milter全体で共有するホワイトリストやユーザ毎にどのmilterを適用するかということをmilter managerレベルで一括管理できます。これにより、ユーザからの要望や利用状況に合わせた柔軟なメールシステムをメンテナンスしやすい構成で運用できます。
前述の通り、milter managerはmilterシステムをより使いやすくする機能を提供します。しかし、それだけにとどまらず、さらにメールシステムをより使いやすくする機能も提供します。その1つがtarpit問題の解決方法の提供です。
tarpitとはSMTPクライアントへのレスポンスを（RFCの範囲内で）わざと遅らせることにより、すぐに切断してくる迷惑メール送信SMTPクライアントからのメールを受信しないようにする迷惑メール対策手法です。
迷惑メール送信側はタイムアウト時間をRFCで示されている時間よりも短めに設定していることが多いというデータがあります。これは、できるだけ短時間で多くの迷惑メールを送信したいというのが理由ではないかと考えられています。この特徴にあわせた迷惑メール対策手法がtarpitです。
tarpitを使うことにより多くの迷惑メールを受信せずにすみますが、同時SMTPセッション数が増加し、リソース消費量が増えるという問題があります。1〜2分程度のレスポンス遅延を導入することにより、2倍程度セッション数が増えるというデータもあります。
この問題は、SMTPクライアントが切断したらすぐにSMTPセッションを終了することにより緩和することができます。Postfixなどでtarpitを実現すると、SMTPクライアントの切断を検出せずに、指定した時間までSMTPセッションを維持してしまいます。そのため、必要以上に同時SMTPセッション数が増加してしまうのです。
milter managerにはSMTPクライアントが切断したらすぐにSMTPセッションを終了する機能がついています。
milter managerはmitlerプロトコルでMTAからSMTPクライアントのソケット情報を受け取っています。それとnetstatコマンドの結果*1を照合することによってMTA外からSMTPクライアントの切断を検出します。切断を検出したらMTAとmilter双方に処理の中止を通知することですぐにSMTPセッションを終了することができます。
milterをベースとした柔軟なメールフィルタリングを実現するための仕組みを説明しました。
メールフィルタリングには以下のような仕組みがあり、それぞれ特徴があります。
新しい迷惑メール対策にも柔軟に対応していくメールシステムにはプラグインタイプがオススメです。プラグインタイプの仕組みの1つとしてmilterを説明しました。
milterはSMTPと密接に連携している仕組みです。milterプロトコルについても説明し、milterがどのような流れでフィルタリングを行うかも示しました。すでに多くの迷惑メール対策手法がmilterとして実現されているため、今すぐmilterを使って迷惑メール対策を組み込んだメールシステムを構築することができます。
最後に、milterシステムをより使いやすくするソフトウェアとしてmilter managerを紹介しました。milter managerを導入すると、設定の自動化や一元管理によりメンテナンスが容易なメールシステムが構築できることを説明しました。
組織に合わせたメールシステムを構築する場合があれば参考にしてみてください。
*1 Linux上では/proc/以下の情報を利用することも考えられます。
来月2/13(土)に札幌で開催されるLOCAL DEVELOPER DAY '10/WinterでRubyでメールフィルターを作る方法について話します。
Rubyでメールフィルターを開発する方法について話します。以下、背景などをまじえてもう少し詳しく説明します。
SendmailやPostfixといったよく使われているメールサーバにはmilterというメールフィルターを追加する仕組みが実装されています。milterを使うことにより、メールサーバに迷惑メール対策機能やウィルスチェック機能、メールアーカイブ機能、添付ファイル自動暗号化機能などを追加することができます。つまり、メールサーバ本体を変更せずに組織のポリシーに合わせたメールシステムを構築することができるということです。
milterという仕組みを使ったメールフィルター*1はすでにたくさん開発されているので、既存のものを組み合わせてメールシステムを構築できることも多いです。しかし、組織特有の事情などがある場合は既存のメールフィルターでは対応できないこともあるでしょう。そういった場合、新しくメールフィルターを開発したり既存のメールフィルターを改造して対応できます。
通常、メールフィルターはC言語で開発する必要がありますが、milter maangerが提供する機能を利用することによってRubyを使って素早くメールフィルターを開発することができます。
今回は、milter managerの機能を使ってRubyでメールフィルターを開発する方法やデバッグの方法などを紹介します。milterという仕組みを知らない方でもわかるように、milterという仕組みから順を追って説明します。ただし、Rubyについて詳しく説明しないので、Rubyがまったくわからない方には少し厳しいかもしれません。札幌でRubyについて詳しくなりたい方はRuby札幌に参加することをオススメします。
来月開催されるLOCAL DEVELOPER DAY '10/Winterで、Rubyを用いてメールフィルターを作る方法について話すので、それを告知しました。
JavaScript（Ext JS）やWebアプリケーションのテスト（Selenium）、ドキュメント指向データベース（MongoDB）、リレーショナルデータベース（PostgreSQL）の話などもあるようです。参加登録も必要ないので、興味のある方はお気軽に参加してみてはいかがでしょうか。
*1 混乱するかもしれませんが、「milterという仕組みを使ったメールフィルター」もmilterと呼びます。milterといった場合は仕組みよりメールフィルターのことを指すことが多いです。
milter manager 1.3.1にほとんど問題がなかったので、ドキュメントやOpenDKIMへの対応などを加えたmilter manager 1.4.0をリリースしました。1.4.0でログまわりを強化する予定もあったのですが、現時点で安定しているので、1.4.0での採用は見送り、次回のリリースにまわすことにしました。
今のところ、milter managerは新しい安定版をおよそ3ヶ月毎の間隔でリリースしています。そのたびに、新しい機能や最新のmilterへの対応が強化されています。また、バグも修正されているので、古いバージョンを使っている方はアップグレードをおすすめします。インストール・アップグレードの方法は以下のドキュメントを参考にしてください。
クリアコードではmilter managerの導入支援やmilterを用いたメールフィルタの開発などサーバサイドの迷惑メール対策サービスからMozilla Thunderbirdを用いたクライアントサイドの迷惑メール対策まで、メールシステム全体での迷惑メール対策サービスを提供しています。迷惑メールに困っている方はinfo@clear-code.comまでお問い合わせください。
milter-greylistでtaRgreyでmilter-greylistにtarpitの機能が取り込まれたことを紹介しました。当時はまだ取り込まれただけでリリースはされていなかったのですが、先日、開発版としてmilter-greylist 4.3.4がリリースされました。
興味のある方が簡単に試せるようにDebian GNU/Linux lenny i386用とUbuntu 8.04 LTS Hardy Heron i386用のパッケージを作成しました。
それでは、milterだけでtaRgreyを実現する方法を説明します。milter-greylist単体で実現すると設定が煩雑になるので、milter managerとmilter-greylistを連携させます。
milter managerのUbuntu用インストールドキュメント通りにインストールされているものとします。Debian用のインストールドキュメントはまだHTMLで公開していないので、下書きを参考にしてください*1。
ただし、milter managerは1.3.1（開発版）以降を利用してください。1.3.1のパッケージは以下にあります。
Ubuntu 8.04 LTS Hardy Heron用apt-line:
deb http://milter-manager.sourceforge.net/ubuntu/ hardy universe deb-src http://milter-manager.sourceforge.net/ubuntu/ hardy universe
Debian GNU/Linux lenny用apt-line:
deb http://milter-manager.sourceforge.net/debian/ lenny main deb-src http://milter-manager.sourceforge.net/debian/ lenny main
設定は以下のように変更します。
milter managerの設定を変更することがない点に注意してください。milter managerは環境にあわせて適切なデフォルト値を使うので、システム管理の手間を減少することができます。
Postfixは/etc/postfix/main.cfに以下の行を追加してください。
/etc/postfix/main.cf:
milter_command_timeout = 150
設定を反映するために再起動します。
% sudo /etc/init.d/postfix restart
milter-greylistは/etc/milter-greylist/greylist.confを以下のように変更します。
変更前:
racl greylist default
変更後:
racl whitelist tarpit 125s racl greylist default
125秒のtarpitに耐えたらホワイトリスト、耐えられなかったらgreylistで救済という動作が自然に書けています。
設定を反映するために再起動します。
% sudo /etc/init.d/milter-greylist restart
最後に、milter-managerに設定の変更を検出させるために再起動します。設定の変更は必要ありません。
% sudo /etc/init.d/milter-manager restart
milter-managerの設定内容を確認すると、milter-greylistのタイムアウト時間が135秒となっているのがわかります。
3 users
% sudo /usr/sbin/milter-manager -u milter-manager --show-config
...
define_milter("milter-greylist") do |milter|
...
milter.writing_timeout = 135.0
milter.reading_timeout = 135.0
...
end
...
135秒は「デフォルトのタイムアウト時間10秒」と「milter-greylistのtarpit時間125秒」を足し合わせた時間です。これはmilter-managerが自動で検出します。
これで、milterによるtaRgrey環境が完成です。
tarpit対応のmilter-greylistがリリース（ただし開発版）されたので、milter managerとmilter-greylistを組み合わせてtaRgreyを実現する方法を紹介しました。
milter managerもmilter-greylistもどちらも開発版を使用しているので、まだ本番環境への投入は早いですが、Debianパッケージがあるので比較的簡単に試せるようになっています。検証など興味のある方は試してみてはいかがでしょうか。問題があった場合は、それを報告し、安定版リリース時には問題が解決されているようにしたいですね。
*1 次のリリースで公開する予定
迷惑メール対策ソフトウェアmilter manager 1.3.1をリリースしました。
milter managerのバージョン番号は「MAJOR.MINOR.MICRO」というルールに従ってつけています。例えば、今回のバージョンの「1.3.1」は以下のようになります。
このうち、マイナーバージョンが偶数のリリースは安定版、奇数のリリースは開発版という扱いになっています。そのため、「1.3.1」は開発版になります。
開発版は安定版よりも新しい機能がありますが、安定して動作しない可能性があります。しかし、次期安定版が近くなった開発版はわりと安定して動作します。そして、今回の1.3.1はわりと次期安定版に近いリリースになります。もし、以下で紹介する開発版のみにある「評価モード」を利用したい場合は試してみて下さい。
世の中にはたくさんのmilterがありますが、すべてのmilterがすべての環境で効果的なわけではありません。それぞれの環境にあった迷惑メール対策を行えるmilterを導入する必要があります。
そのためには、導入する前にどのような効果になるかを試してみる必要があります。ENMAやOpenDKIMのように結果をメールヘッダに追加するタイプのmilterであれば、想定とは違う動作だったとしても既存のメールシステムにはほとんど影響はないため、既存のメールシステムに導入して効果を確かめることができます。一方、milter-greylistなどのように一時拒否や拒否をするタイプのmilterであれば、誤判定のメールを受信できなかったなど、既存のメールシステムに与える影響が大きくなるため、既存のメールシステムで効果を確かめることが難しくなります。
そのような場合でもmilterの効果を確かめることができるようにするのが1.3.1で追加された「評価モード」です。評価モードを用いると、実際にmilterを動かしますが結果は無視します。実際にmilterを動かしているので、milter managerやmilter自身が出力するログなどでどのように動作したかを確認することができます。milter managerはログからグラフを生成する機能もあるので、視覚的に効果を確認することもできます。
先日の第09回 まっちゃ445勉強会の資料で評価モードについて説明した図があるので、それを見てみましょう。
まず、評価モードを使っていない通常時の動作の流れです。
milterがメール本文を変更するなどの操作をした場合は、milter managerはそれをそのまま呼び出し元のメールサーバ（図では受信側と書いている部分）に返します。注目してほしいのは、milterと呼び出し元のメールサーバの間にいるmilter managerがやりとりをログに残し、グラフ化している部分です。milterやメールサーバに結果の統計情報を収集する機能がなくても、間にmilter managerを導入するだけで結果の統計情報を収集することができます。これは、milterの効果を確認するときにとても便利です。
それでは、評価モードを使っているときの動作の流れです。
上の2つのmilterが評価モードで動いています。評価モードのmilterがメール本文を変更するなどの操作をしていますが、呼び出し元のメールサーバにはその結果は返っていません。つまり、milterの結果が既存のメールシステムに影響を与えないということです。しかし、milterの結果の統計情報を収集する部分は動作します。これにより、既存のメールシステムに影響を与えずにmilterの効果を確認することができるようになります。
いつまでも同じ迷惑メール対策が効果があるとは限りません。迷惑メール送信側も進化していますが、それに対する有効な対策も考案されています。そのような対策を導入する場合、ここで紹介した評価モードが有用になるでしょう。
1.3.1がリリースされたので、新機能「評価モード」を紹介しました。
1.3.x系列は他にも1SMTPセッションで複数のメールを送る場合の処理が改善されていたり、milter-greylistを用いたtaRgreyに対応していたりします。
このような機能が必要な場合は1.3.1を試してみてください。もし、問題があった場合はメーリングリストで報告してもらえると助かります。
また、milter manager導入情報もお待ちしています。以下のような情報をメーリングリストかkou@clear-code.comまで送ってもらえると、今後の開発などの参考になるので助かります。
最後になりましたが、先日発売されたセキュリティExpert 2009に迷惑メール対策関連の小さな記事（4ページ）を書きました。見かけた場合はぜひ手に取ってみてください。
セキュリティExpert 2009
技術評論社
￥ 1,554
第09回 まっちゃ445勉強会で使用した資料を公開しました。
今回は、Ruby関連で話すときのように自由な感じで話したのですが、楽しんでもらえた方もいたようでよかったです。
話した内容はmilter managerのことというより、milter managerがベースとしているmilterのことです。milter managerについては、最後に少し触れた程度です。
プログラムを見てもらえればわかりますが、送信側の対策、経路情報を利用する対策、メッセージの内容を利用する対策と網羅的な内容でした。そのなかで、手法そのものではなく、これらの手法を活用するためのツールであるmilter managerは異色と言えます*1。
milter managerと同じくmilterも手法そのものではありません。milterは手法を実現するための仕組みの1つです。セッションの順番が経路情報を利用する対策のセッションとメッセージの内容を利用する対策のセッションの間という切り替えのタイミング（で、さらにおやつの後）ということもあり、umqさんのイントロダクションの一部をもう少し詳しく取り上げて、勉強会の話題に上がっている手法をmilterを使って実現できるよ、という流れになっています。全体を再確認しつつ、適度な中休みになったのならmilter managerセッションの役割は果たせたかと思います。
個別ではなく全体的に見てですが、みんな楽しそうでいいなぁ、集まれてよかったなぁ、というのが率直なところです。また、同じような機会ができればいいなぁと思いますので、実現したときはまたよろしくお願いします。
勉強会で使ったプレゼンテーションツールRabbitの機能を紹介しておきます。
さとうさんの資料はOpenOffice.orgのImpressで作成してPDF化されていました。少し時間がオーバーしそうということだったので、Rabbitの「うさぎとかめタイマー」をおすすめして実際に使ってもらいました。
RabbitはPDFレンダリング機能もあるので、他のプレゼンテーションツールで資料を作成しPDFに出力すれば、Rabbitで表示することができます。Rabbitは読み込んだPDFのスライドの上に「うさぎとかめタイマー」を表示するので、PDF側には特に何もする必要はありません。
「うさぎとかめタイマー」が何かについては、ぜひ自分の目で確認してください。
SMTPのやりとりのデモをするときにスライドの真ん中を開けて、後ろにあるターミナル上でtelnet（とMutt*2）を使いました。この穴のことを「Rabbit Hole」と呼んでいます。名前の由来はもちろん不思議の国のアリスです。
ちなみに、Rabbitにはアリス画像も用意されているので、アリスとうさぎを追いかけさせることもできます。
8/29（土）に行われる第09回 まっちゃ445勉強会のテーマは「迷惑メール対策」で、迷惑メール対策の方法を提案している方や迷惑メール対策を実現するためのツールの開発に関わっている方が発表者として参加する予定です。milter managerも迷惑メール対策関連ツールの1つとして参加します。
今回はmilter managerそのものよりも、milter managerがベースとしている「milter」という技術・仕組みについて話す予定です。
勉強会には迷惑メール対策に深く関わっている方が多く参加する予定なので、興味のある方は参加してみてはいかがでしょうか。
せっかくの機会なので、日本Ruby会議2009期間中にフリーソフトウェアをいくつかリリースする予定です。
以下のフリーソフトウェアはリリース準備ができているので、会場のネットワーク環境をうまく使えれば期間中にリリースします。
午前11時頃か午後3時頃にスポンサーブース内でリリース作業をする予定です。 日本Ruby会議2009は3日間あるので、リリース作業はそれぞれの日に分散させる予定です。
もしかしたら、以下のフリーソフトウェアもリリースできるかもしれません。
1つ実装したい機能が残っているので、それが実装できればリリースします。が、時間的に厳しそうです。
以下のフリーソフトウェアもリリースしたかったのですが、準備が十分ではないので、おそらくリリースできないと思います。残念です。
Ruby/Libglade2にGC関連のSEGVバグがあり、それを修正する時間がとれなかったので、日本Ruby会議2009のタイミングではリリースできそうにありません。
また、ソフトウェアではありませんが、GUI関連でRuby GUI調査2008のレポートを日本語に翻訳したものもリリースしたかった*1のですが、間に合いませんでした。Alexさんからは編集可能な形で原文をもらっているので、もし、協力してくれる方がいればkou@clear-code.comまでご連絡ください。
日本Ruby会議2009期間中にリリースを予定しているフリーソフトウェアを紹介しました。
RSS Parserやrcairoなど、ここに挙げたフリーソフトウェア以外でも構いませんので、なにかコメントなどがあればスポンサーブースで声をかけてください。
*1 永井さんがLightning TalksでRuby/Tkは本当にダメな子なのか？というお話をするようですし。
まっちゃだいふくさんに声をかけてもらったことがきっかけで、オープンソースカンファレンス2009 Hokkaidoのせきゅぽろ枠でmilter managerの話をしてきました。声をかけてくれたまっちゃだいふくさん、参加してくれたみなさん、ありがとうございました。
資料: milter manager
また、Ruby札幌がUstreamで配信してくれたので、動画もあります。
動画: OSC 2009 Hokkaido milter manager
今回はmilterとmilter managerの話をする前に、迷惑メール対策の現状と有効な対策方法についても話しました。これは、第2回静岡ITPro勉強会での佐藤さんの公演内容を参考資料として利用しています。利用を快諾してくれた佐藤さんありがとうございます。札幌のみなさんにも迷惑メール対策の現状と有効な対策方法を伝えられたのではないかと思います。
一般的な迷惑メール対策の話の後にmilterとmilter managerの話をしました。第2回静岡ITPro勉強会の時よりも時間が少ないということもあり、今回はあまり突っ込んだ話をせずに、雰囲気が伝わる程度に抑えました。
話の後、司会をしてくれたまっちゃだいふくさんが今回省略したあたりをフォローしてくれました。ありがとうございます。
まっちゃだいふくさんは勉強会の時間外に、いろいろアドバイスをしてくれます。そのため、発表者として参加したこちらもとても勉強になっています。
そして、まっちゃだいふくさんがもってきてくれたお菓子はとてもおいしかったです。
せきゅぽろ枠の時間以外はRuby札幌にお世話になりました。
Ruby札幌とせきゅぷろの枠はセミナーに参加したのですが、それ以外の時間はRuby札幌のブースにおじゃまさせてもらいました。daraさんからbuzztterのバックエンドをgroongaにしたいということを聞いたので、Ruby/groongaで実現するために少し相談しました。Ruby/groonga 0.0.3はbuzztterのバックエンドとして使える機能を提供することになるでしょう。
今回、ActiveLdapを使っている島田さん以外のRuby札幌の人たちとも話すことができたのはよかったです。ActiveLdapやRSS Makerあたりのレビューにも参加することができました。
今回、Ruby札幌の人たちはとても人柄がよいことがわかりました。とてもすばらしいです。また、Ruby札幌がRabbitを応援していることもすばらしいです。
オープンソースカンファレンス2009 Hokkaidoのせきゅぷろ枠でmilter managerの話をしてきました。この話は、まっちゃだいふくさんのおかげで実現しました。話の後のフォローなどいろいろありがとうございます。
Ruby札幌はすばらしいです。Ruby会議2009ではニュースがあるようですし、その後には札幌Ruby会議02もあるようです。Ruby札幌から目が離せません。
6/13に開催された第2回静岡ITPro勉強会に講師の1人として参加し、milter managerについて話しました。
資料: milter manager
勉強会はとても内容の濃いものでした。勉強会の内容は勉強会代表となかさんの第２回 静岡 IT Pro 勉強会、無事終了しました - 静岡 IT Pro 勉強会日誌が詳しいです。ここでは、かいつまんで紹介します。
最初にさとうさんが網羅的に迷惑メール対策の現状とおすすめの迷惑メール対策を話してくれました。おすすめの迷惑メール対策は、まず、SMTPセッション中で軽めのフィルタを使って多くの迷惑メールを落として、抜けてきたものはコンテンツベースのフィルタを使って対応するというものです。
1つのフィルタで何もかも解決するのではなく、複数のフィルタを組み合わせて実現するという方針です。1つのフィルタで完璧を求めてしまうと誤判定が増えたり、副作用が大きくでてしまう危険性があるからです。milter managerのベースは、複数のmilterをうまく組み合わせるという部分ですが、これは、さとうさんの方針と重なる部分が大きいです。
ちなみに、milter managerのインストールドキュメント にそってmilter managerをインストールすると、さとうさんの考案したRgreyが実現できます。このあたりからも、milter managerがさとうさんの影響を受けていることがわかります。
次に、umqさんが送信ドメイン認証の概要を話してくれました。Authentication-ResultsがRFCになっていた（RFC5451）ことがわかっ たことが収穫でした。milter managerのtrunkにはAuthentication-Resultsをパースする処理があるのですが、その処理を書いているときに、どこかでこのフォーマットは定義されていないのかと思いながら書いていたのです。いずれRFC5451に合わせたものにする予定です。
最後はmilter managerの発表でした。いくつか話し忘れたことがあるのが残念です。例えば、RgreyにSPFを組み合わせるとS25Rで誤検出してしまうmail-ew0-f216.google.comというようなGMailからの接続を救済することができます。*1こういうこともできるよ、ということだけではなく、そうすることによりどのような効果があるかも忘れずに話すべきでした。
資料にはmilter managerのことだけではなく、milter-greylist の設定例もあるので、milter-greylistを使っている場合は参考になるでしょう。
また、まっちゃだいふくさんが通常のmilterの動作フローとmilter managerを導入した場合の動作フローの図を描いてくれています。これまでのmilter managerの動作イメージ図より、流れがわかりやすくなっています。こちらの図の方が理解しやすいという方も多いのではないでしょうか。まっちゃだいふくさん、ありがとうございます。
時間が少し空いたので、急遽、予定にはない発表が行われました。
まず、勉強会の中でSpamAssassinの認知度が低いということがわかったので、滝澤さんがSpamAssassinについて話してくれました。滝澤さん、頼もしいです。
次に、さとうさんが、こんな迷惑メール対策システムが欲しい、ということを話してくれました。様々な情報から自動学習して、メンテナンスフリーで動くシステムです。とても共感できます。
という、とても内容の濃い勉強会でした。
勉強会にでるメリットはいくつかありますが、ここで2つ紹介します。
勉強会のメリットの1つは、直接会って話せることでしょう。
さとうさんとは勉強会の前に、迷惑メール対策の実現方法についていろいろやりとりしていましたが、やはり、直接会って話せると進みが違います。
IAjapan 第7回 迷惑メール対策カンファレンスのときに滝澤さんと、「オープンソースソフトウェアで迷惑メール対策を実現している人たちの間で情報共有できたらもっと有効な対策が実現できそうだよね」というような話をしていたのですが、今回、さとうさんともそのような話をすることができました。秋には実現できるかもしれません。
今回のように直接話す機会があったので進んだ話と言えるでしょう。このような機会になった勉強会を運営してくれたスタッフのみなさん、ありがとうございます。
また、きっかけになるということもメリットです。
勉強会のために事前にやりとりをしている中で、今回ドメイン認証関連の発表をしたumqさんがmilter managerのportsを作成してくれました。FreeBSDはmilter managerが公式にサポートしているプラットフォームのため、ぜひ、パッケージを提供したかったのですが、今回の勉強会がきっかけでそれが実現されました。
作成してくれたumqさん、声をかけてくれたまっちゃだいふくさん、さとうさん、ありがとうございます。
ここ数ヶ月milter managerについて様々な場で話す機会をもらっています。それぞれの場で雰囲気も聞いてくれる人のタイプも違うため、話す内容やそれぞれの話題の重みを変えて話しているつもりです。そのため、用意をすることは大変ですが、異なる場に行くことにより、話す側として様々なメリットがあると感じています。フィードバックの内容が多様になったり、いろいろな角度からの考えや実状が聞けることだったりします。
現在はたくさんの勉強会が開かれていて、それぞれ異なる場となっています。勉強会に参加したことがある人でも、違う場の勉強会に参加してみるというのはよい経験になるでしょう。また、発表者として参加するのもまたよい経験になるでしょう。
怖がらず、新しいことにふれてみるのもよいのではないでしょうか。
今週末はオープンソースカンファレンス2009 Hokkaidoで話します。今回の勉強会で、初めに迷惑メール対策の基本的なことを話した方がよいことがわかりました。さとうさんから、今回さとうさんが話した内容を取り入れてもよいと言ってもらえました。そこで、静岡でさとうさんが話したすばらしい内容の一部を北海道でも紹介する予定です。
*1 SPFを有効にしたmilter-greylistを使っている場合は、デフォルトでSPFがpassする場合はGreylistingをスキップします。
5/26,27の2日間開催されたIPAX2009にブース出展しました。立ち寄ってくれたみなさん、ありがとうございました。
このようなイベントに参加すると、新しくつながりができたり、つながりがある方たちと会うことができるのがよいところです。また、私たちが公開しているフリーソフトウェアのユーザの方と直接お話できることもあります。実際に便利に使っているという声を聞けると嬉しいものです。
さて、5/26にあった出展者プレゼンテーションで発表したので、その資料を公開します。
発表資料: milter-manager - 迷惑メール対策を柔軟に実現するためのmilterの開発
実は、今回の資料ではじめて「milterプロトコル」という単語を出しました。実装的には「milter managerがmilterプロトコルを実装しているので、うまくMTAとmilterの間に入ることができる」というのがおもしろいところなのですが、それを知らなくても便利に使うことができるので今までは触れずにいました。
他にも「milter manager内にRubyインタプリタを組み込み、IOまわりやプロトコル処理など速度を出したいところはC、設定ファイルや動的な条件判断など柔軟性が必要なところはRuby、というように適材適所で使い分けている」という実装面でおもしろいところがあるのですが、そこもいつか話せるとよいなぁと思っています。
5月は東京で開催されたIAjapan 第7回 迷惑メール対策カンファレンスとIPAX2009でmilter managerの紹介をしました。6月は東京以外の場所でmilter managerを紹介する予定です。興味のある方は足を運んでみてください。
先日開催されたIAjapan 第7回 迷惑メール対策カンファレンスで、送信ドメイン認証の結果を利用した迷惑メール対策を行えるソフトウェアとしてmilter managerの紹介をしました。
講演資料: milterの有効活用 - milter manager
講演資料は、後日、カンファレンスのサイトでも公開される予定です。カンファレンスのサイトでは他の講演者の方の資料も公開されると思うので、公開されたらそちらもチェックするとよいと思います。
また、配布資料とは構成が変わっていて、図も増えてあります。公開した資料は講演時に利用した資料となっています。
自分でも感じていたり、まわりの方からもそういうコメントをもらったのですが、他の講演者の方とは少し違う感じの講演となりました。それでも、講演後に何人かの方が声をかけてくれました。ありがとうございます。
milter managerそのものについて、milter managerやその周辺技術の活用方法についてなど、興味を持ってもらえたようです。今回の講演では省略したりあまり深く触れなかった部分の中には、実はすごく伝えたい部分もあったのですが、そこに興味を持ってくれた方もいたのが嬉しかったです。
来週はIPAX2009に出展します。また、5/26（火）にある出展者プレゼンテーション1 企業の中で、12:45-12:55の10分間、milter managerについて話します。迷惑メール対策カンファレンスではあまり触れなかった技術的な面について話そうかと考えています。ブースも出していますので、もし、時間が合えば、IPAX2009に来てみてください。
1.0.0リリース時のリビジョンがr2898で現在のリビジョンがr3001と、1.0.0リリース後も継続して開発されているmilter managerですが、5月は、開発だけではなくmilter managerの話をする機会もあります。5/19と5/26の2回です。
5/19の方は財団法人インターネット協会主催のIAjapan 第7回 迷惑メール対策カンファレンスです。
13:20-14:20の「３. 送信ドメイン認証活用に向けて」で「milterの有効活用 - milter manager」というタイトルで30分話します。同じ枠で、送信ドメイン認証SPF/Sender ID Framework/DKIM/DKIM ADSPに対応したmilterであるENMAの話も聞けます。
また、続く14:35-16:05の「４.【Ｑ＆Ａパネルディスカッション】送信ドメイン認証を導入にあたって」にもパネリストとして参加します。
迷惑メール対策に関心のある方は参加してみてはいかがでしょうか？
トピックス: IAjapan第7回迷惑メール対策カンファレンスで講演
5/26の方はIPA主催のIPAX2009です。
milter managerはIPAのオープンソフトウェア事業による成果であるため、今回出展することになりました。オープンソフトウェア事業以外にも未踏に参加した人たちも出展しているので、技術的におもしろいことが聞けるのではないかと思います。
出展者のプレゼンテーション枠があり、5月26日11:55〜12:55の枠の中で10分間milter managerの話をします。ブースは両日とも出展していますので、ご来場の際は一声かけてください。
このような機会がきっかけとなって、milter managerに興味を持ってくれる人が増えると嬉しいですね。
milter manager初の安定版1.0.0をリリースしました。→milter managerの紹介
また、クリアコード初のプレスリリースもしました。→迷惑メール対策システムの構築を簡単・低コストにする『milter manager』をリリース
今日をリリース日にしたのは、今日が大安だったからです。リリース作業はそれほど大きなトラブルもなく行えたので、よい日だったと思います。みなさんも、大安にリリースしてみてはいかがでしょうか。
迷惑メール対策ソフトウェア、milter manager 0.9.0をリリースしました。
変更点にもある通り、前のリリースである0.8.0より処理速度と安定性が向上しています。手元のメールシステムでも安定して動作しており、興味のある方に試してもらえる品質になってきたと思います。
このリリースは1.0.0のリリース候補版という位置付けです。0.9.0に問題が見つからなかった場合は0.9.0が1.0.0としてリリースされます。
最初のリリース時にもらったフィードバック*1を元に0.8.0でいくつか機能を拡張しましたが、今回はmilter manager本体に目立った機能追加はありません。これは、いつまでも完成しない1.0.0を待ってもらうより、まずは安定して動作するmilter managerを提供して、有効に使ってもらう方が有用だろうという判断からです。
いくつか追加機能の案はあるのですが、それは1.0.0のリリース後に実装する予定です。0.9.0のリリースでは組み込みの適用規則の追加と周辺ツールの機能追加にとどめました。
今回は以下の2つの適用規則が追加されました。
sendmail-compatibleは常にmilterを適用するので適用規則ではないのですが、適用規則の枠組みを使った応用例ということで追加しました。
適用規則中ではMTAからmilterに渡されるマクロを参照・変更することができます。この機能をフィルタのように利用しているのがsendmail-compatibleです。
SendmailとPostfixはともにmilter対応しているMTAですが、milterに渡すマクロの実装に互換性がありません。例えば、SendmailとPostfixではマクロ名が異なる、SendmailとPostfixでマクロが渡ってくるタイミングが違う、ということがあります。（詳しくはPostfix before-queue Milterサポートにあります）
この非互換の部分に依存しているmilterはSendmailでは動いてもPostfixでは動かない場合があります。例えば、dnsbl-milterがそのようなmilterです。*2
sendmail-compatibleは、Postfixが渡してきたマクロをSendmailが使っているマクロ名でもアクセスできるようにしたり、ダミーの値を入れたマクロをmilterに渡すなどして、できるだけ非互換の部分を利用しているmilterも動作するようにします。
適用規則の部分はmilter managerの動作の中で、もっとも特徴的で応用範囲が広い部分です。1.0.0リリース後はこれ以外にも応用できるような機能を追加する予定です。
なにかアイディアがあればメーリングリストなどで共有してもらえると、より有用な迷惑メール対策システムを構築できるようになるかもしれません。お待ちしています。
0.9.0ではこれまでよりも速度と安定性が向上していて、実際に試してみることができる品質になっています。milter managerに興味のある方はぜひ試してみてください。もし、問題が見つかった場合はその問題を修正してから1.0.0をリリースします。（問題の修正が大きな変更を伴う場合は既知の問題として修正を先送りする可能性もあります）
機能追加は1.0.0リリース後に行うので、もうしばらくお待ちください。
参考: milter managerのインストールドキュメント
*1 例えばmilter managerを利用したRgrey - モーグルとカバとパウダーの日記。ありがとうございます。
オープンソースカンファレンス2009 Tokyo/Springに参加しました。想像以上に展示スペースで足を止めてくれた方がいました。展示スペースに立ち寄ってくれたみなさん、ありがとうございました。いくつか展示したなかでも、以下の展示が気になってもらえたようです。
ライブ開発は、他の人が開発しているところを見る機会がないということと、そもそも何をやっているんだ？というのが気になってもらえたようです。機会があれば、また、ライブ開発はやりたいと思います。
milter managerについてはライトニングトークでも話しました。（スライド）milter managerよりもRabbitの方をアピールしているように見えたのであれば、それは発表者の実力不足です。ツールに食われてはいけません。
クリアコードがこのようなイベントに参加するのは初めてだったのですが、新しいつながりができたり、アイディアをもらえたりしたので、参加してよかったと思います。これからも、機会があればこのようなイベントに参加しようと思います。そのときも、ぜひ、クリアコードのところに立ち寄ってみてください。
迷惑メール対策ソフトウェア、milter manager 0.8.0をリリースしました。
milter managerはIPAの２００８年度 オープンソフトウェア利用促進事業 上期テーマ型（開発） 公募「迷惑メール対策ポリシーを柔軟に実現するためのmilterの開発」で開発しています。
2月21日（土）にはオープンソースカンファレンス2009 Tokyo/Springのライトニングトークでmilter managerの紹介をします。milter managerを導入した場合のシステム全体の紹介よりも、Rubyインタプリタを組み込んだアプリケーションとしての側面に重みをおいて紹介する予定です。
Ruby関連のイベントでは、同日にとちぎRuby会議01がありますが、栃木まで行くのは大変、という方はオープンソースカンファレンスに参加してみてはいかがでしょうか。 日本Rubyの会も展示をしたり、セッションを開いたりするようです。クリアコードの展示も面白そうです。
オープンソースカンファレンス2009 Tokyo/Springは2月20日（金）、2月21日（土）の2日間開催されます。予定が空いている方は参加してみてはいかがでしょうか。最近の技術の動向を知るよい機会だと思います。
クリアコードは2009年2月20日（金）、21日（土）開催のオープンソースカンファレンス2009 Tokyo/Springに協賛します。
クリアコードの展示スペースでは以下を実施する予定です。気になるものがあったら、ぜひ立ち寄ってみてください。
一ヶ月ほど前に紹介したとおり、クリアコードでは組み込み環境向けのMozillaの研究を進めています。展示スペースでは以前紹介したデモを展示しますので、もう少し詳しいことを知りたいという方は展示スペースで気軽に声をかけて下さい。
また、クリアコードが提供するMozilla関連サービスも紹介します。
クリアコードでは、実際にコードを書くということを重視しています。
クリアコードは、ソフトウェア開発だけではなく、ソースコードレベルまで踏み込んだ導入支援・技術支援サービスもおこなっています。支援サービスでは、必要であれば問題を解決・回避するようにソフトウェア本体を修正したり、修正するソフトウェアを開発します。また、より要望に沿ったシステムとなるような拡張をおこなう場合もあります。そのようなThunderbird用のアドオンの一部はフリーソフトウェアとして公開しています。
展示スペースではMozillaを対象としてライブ開発をします。ライブ開発は展示期間中は終日おこなっていますので、どのように開発しているのか気になる方は展示スペースまで立ち寄ってください。また、飛び込みのペアプログラミング希望にも対応しますので、希望する方は気軽に声をかけてください。
IPAの２００８年度 オープンソフトウェア利用促進事業 上期テーマ型（開発） 公募「迷惑メール対策ポリシーを柔軟に実現するためのmilterの開発」で開発中の迷惑メール対策ソフトウェアmilter managerについて紹介します。
現時点で有効な迷惑メール対策についても紹介するので、迷惑メール対策に興味のある方は気軽に声をかけてください。また、milter managerはRubyインタプリタを内臓しているユニークなソフトウェアでもあるので、実装に興味のある方も気軽に声をかけて下さい。（リリースされたばかりのRuby 1.9.1にはまだ対応していません。）
また、21日（土）15:15〜のライトニングトークでもmilter managerを紹介します。展示スペースでの紹介とは違った角度からmilter managerを紹介する予定です。
今年の夏に実施予定のインターンシップの紹介をします。
インターンシップで実施予定のペアプログラミングを体験することもできます。話題沸騰のインターンシップに興味のある方は気軽に声をかけてください。
オープンソースカンファレンス2009 Tokyo/Springは2009年2月20日（金）、21日（土）に日本電子専門学校 7号館で開催されます。
参加される方は、ぜひ、クリアコードの展示スペースにも立ち寄ってみてください。
