bounceHammer4歳のお誕生日とVersion 3.0.0について

今日、三月七日はbounceHammerの4回目のお誕生日です、おめでとうございます。Version 2.0.0としてオープンソースでリリースしてから四年が経ちました、ケーキとかは特に用意していません。

去年の秋にリリースした2.7.11でほぼ完成というか、安定したものとなっているのですが、経年と共にいろいろと問題点や修正しにくい不具合、それに実装しにくい機能追加要望が出てきていまして、それらをまとめて解決すべく、現在Tonkachiという名前空間でVersion 3.0.0を開発しています、やはりPerlで書いています。

コミュニケーション手段としてのメール(SMTP)はほぼ死んでいるような気もしますが、通知手段としてのメール・IDとしてのメールアドレスはまだまだ死んではいないので、続編の開発をする事にしました。

bounceHammer 2系の問題点

開発者として把握している2系(2.7.11)の問題点としては以下のようなものを認識しています。

1通のバウンスメールに2件以上のバウンスがある場合、最初の1件しか取得出来ない
一つのシステムとして完結しているのでモジュールとして使いにくい
O/R MapperでDBIx::Skinnyを使っているけどメンテされてない(Tengに移行すべきか?)
WebUIでCGI::Applicationを使ってるけどメンテされていない(Mojoliciousに移行?)
Perl 5.16以降では動かない(use base '...'使ってる)
要らん機能が多い(統計出すやつとか人気のないWebUIとか)
データが大量にある場合、Text::ASCIITable使ってる部分が重い
メールアドレスを取り出す際のヘッダの走査順序がハードコードされてる
依存モジュールが多いのでインストールに時間がかかるしたまに失敗する

このあたりの問題点、根本解決が難しいというか手間がかかるので、2系の開発は一旦終了(4月に2.7.12を出しますが)して、今後は新機能の追加は行わずに致命的なバグ修正のみに特化する予定です。勿論、僕の所属している会社でサポート契約を提供していますので、契約して頂いているユーザさんへの対応やサポート・パッチの提供は継続します。そして、新たに3系をほぼ一から書き直しています。

bounceHammer Version 2の開発前夜

2009年の秋ごろ、それまではコンパイルしなくても良いC言語みたいな感覚でしかPerlを使ってなかったのですが、「モダンPerl入門」で近代的なPerlを勉強し直してから開発に着手しました。オープンソースで公開した最初のバージョンが2.0.0なのは、実は開発したけど世に出さなかったVersion 1があったからです。どちらのバージョンもサーバ管理者とかインフラよりの作りになってました。

Version 1はもっと低機能で、Version 2で機能が追加されすぎて、Version 3ではもっと絞ったものになる予定なので、まさに「UNIXという考え方」に書かれている第一システム、第二のシステム、第三のシステムという流れをそのまま進んでいます。

bounceHammer version 3.0.0

前述の問題点を解決すべく、必要な機能だけに絞った堅牢なものとしてbounceHammer version 3.0.0をTonkachiという名前空間で開発しています。早ければ桜の咲く頃か散る頃、遅ければ祇園祭が始まる頃にはリリース出来ると思います、たぶん。

Version 3.0.0の概要

一応モジュールとしては動くのですが、現段階ではSendmailが作ったバウンスメールしか解析出来ないので完成度は20%〜30%ぐらいです。逆に明日の朝起きたら、世の中のMTAが全てSendmailになっていてqmail他全部消滅していたらほぼ完成な状態です。

解析用Perlモジュールとしての側面が強くなる
↑メールボックスのPATHか中身を渡して解析済のJSONとかYAMLを返すのに特化
依存モジュールはなるべく少ないライブラリとして出す
コマンドラインツールやWebUIは実装するかどうか不明
HTTPベースでメールのデータをPOSTしたら解析済JSONを返すAPIは作るかも
商用MTA対応モジュールも組み込む予定(ExchangeとかNotesとかDominoとかいろいろ)
Feedback Loopにも対応する(バウンスメールとして扱う)
PODがそこそこ書かれている(まだ内容は少ない)
CPANにも置く?
configureは多分やめる、cpanmでのインストールを前提とする
引き続き同じライセンスのオープンソースで公開

Version 2では、ユーザと最も近い部分はbin/以下にインストールされるコマンドラインツールでした。これはメールサーバで解析結果を得えるにはコマンドを実行すれば良いだけの手軽なものでした。一方、開発者の立場で見れば、例えば簡単な1枚スクリプトで解析結果を得て、それを加工するといった用途には使いにくいものでした。

僕自身、とある案件でPerで書かれたメール処理系プログラムに解析処理を組み込む際、わざわざbouncehammer全体をインストールしてというのが面倒に思えた事が何度かあります。

Feedback Loopは日本では導入されているのかどうかわかりませんが、外国、特に欧州のユーザから「FBLもバウンスメールとして扱うべきでしょ」という連絡と追加要望をよく貰います、主にドイツとフランスとスペインから。なのでこれも正式対応する事にしました。

気になっていたツイート

bounceHammerのKanadzuchiモジュールをcpan(cpanm)でインストールできると嬉しいなぁ。パーサーとバウンス解析モジュール群をカジュアルに使いたいのぅ。
— Hayato ｷｭｱ Imai (@hayajo) January 31, 2012

このツイート、二年ほど前ですがずっと気になってました。Version 2はDBからコマンドラインツールから何から何まで揃ってて「こういう風に使ってね」という押しつけがましい感じの物でしたが、解析結果をDBに入れるかファイルに書き出すか、あるいは解析結果の一部だけ取り出すかとか、そのあたりはユーザが自分で好きなものを作る方が良いのではという考えもあり、やっとカジュアルに解析出来るものが作れそうな気がします。

名前空間どうしよう

Version 2系の名前空間がKanadzuchi(なぜzを入れたのかは覚えていない)でしたので、金槌つながりで安易にTonkachi(とんかち)として作り出しています。他にはKinetsukiとかKuginukiとかハンマー系の候補がありましたがTonkachiが一番短いのでTonkachiにしました。名前、リリースまでにもっと良い名前、カッコいい名前が思いついたらそれに変更しますが、今のところ特に思い浮かびません。

あるいはMail::*やEmail::*(これはPEPのMLとかで根回しいるのかな?)でも良さそうな気もしますが、「メールを読みだして解析する+何か」という一連の動作と結果を提供するので、独立した名前空間の方がいいのか悪いのかわかりませんが、たちまち仮名としてTonkachiにしています。BounceHammerという名前空間を使わない理由は、Version 1の名前空間がそうやったので除外しています、長いですし。

Perl以外の言語

次のバージョンはPerlモジュールとして、おそらくはcpanm Tonkachiと実行すればすぐにインストールされてあとはそれを使うスクリプトをユーザが好きに作れば良いという感じになると思いますが、そうなるとPerl以外の言語から解析結果を得る手段がなくなります。

とは言っても、今の2.7.11でそれが出来るかといえばそうではなくて、WebUIのAPIを使ってDBに蓄積されたデータをHTTP+JSONで参照するか、解析結果のYAMLやCSVファイルを読むか、という程度ですが。

なので、Haineko(HTTP+JSONでメール送信する何か)がそうしているように、Plackで小さなhttpdが起動して、それに対してメールボックスのPATHか中身をPOSTすれば解析結果がJSONで返ってくるようなAPIを提供する何かを作る予定ではいます、たぶん。ただ、HTTPを使うかどうかも含めて特に決まってませんし、そのあたりのコードは1行も書いていません。

まとめ

まだまだ作り掛けですが、cpanmでインストール出来るモジュールとしてリリースし、開発者よりの使い方が出来るものになる予定です。

/var/log/azumakuniyuki

2014/03/07