所々の理由でシシマイ(Sisimai)と名乗る事にしましたが、bounceHammer 4として開発していたので4.0.0を最初のバージョンとしてリリースし、8/16にversion 4.1.28になりました。とりあえず現状で安定版として問題ないであろう状態にはなっています。
シシマイについて最後に書いた記事が2014/11/11の「次期bounceHammerの中核モジュール"Sisimai"」で、それから一年近くが経過していましたので、その後の変化について書き記しておきます。
主要な事柄はGitHubのリポジトリ/README.mdに書いているのですが、いずれRuby版を作る計画もあり、そうなると関連情報が散逸しそうなので libsisimai.org というドメインを取得してTumblrでサイトを作りました。
ドメイン名はどうしよう
sisimai.orgとかsisimai.jpが良かったのですが、さすがにそんな都合の良いドメインが空いてるわけでもなく、ドメイン名はどうしようかと思いついたのが、シシマイはPerlモジュール→ライブラリと表現しても良い→lib ?→/usr/libの中をのぞく→libwrapとかlibzfsとかある→libsisimai.org ! ってドメイン名です。
ロゴが欲しい
さて、サイトが出来ると画像が欲しくなり、やはりロゴマークみたいなの(というかちゃんとしたロゴ)が要るなぁって事で、著作権の切れている獅子舞画像の顔をトレースして髪の毛を増やして丸で囲ってロゴマークを、いつもどおりお気に入りのフォントであるCentury Gothicでロゴタイプをそれぞれ作りました。
昔からPATHの操作が苦手でIllustratorなんて高級な道具は買っても先ずまともに使いこなせないのは目に見えているので、Inkscapeでどうにか出来たってとこです。Inkscapeは今回久しぶりに起動してアップデートして使ってみましたが、数年前よりも安定していて、たまに何かを描く程度のプロではない人にとっては充分に実用レベルであると思います。
色は獅子舞なので赤色、なるべく派手ではなくてキツくもなくて、毒々しくもない、そして赤色と認識出来る落ち着いたのを「日本の伝統色 和色大辞典 - Traditional colors of Japan」で物色して緋色にしました。bounceHammerのロゴは"b"と金槌の輪郭をうまいこと構成して作ったのですが、僕はデザイナーではないのでああいった新しい形を形成するのに物凄く時間がかかってしまいそうで、今回は著作権切れな獅子舞の絵を使う事にした次第です。
なお、僕の作る物は配色が壊滅的にセンスがないと何度か言われた事があるので、このロゴの評判次第では色を変えるかもしれません。
後継者
ロゴにも書いたのですが、正式にbounceHammerを継ぐ者を名乗っています。あと、数ヶ月以内にbounceHammerはEOL(End-Of-Life)になる予定です。
機能面でのアップデート内容
MTAの対応強化
bounceHammerの商用版からいくつかのモジュールをSisimai用に移植しました。それと、これは全く需要が無いであろうと認識していますが、Sendmail v5が作ったバウンスメールも解析出来るSisimai::MTA::V5Sendmailを実装しました。理由はbounceHammerの開発前から集めてたバウンスメールのサンプルに多くのSendmail v5由来なものがあったからです。そこまで磨いてもってレベルまで高めた精米歩合20%台のお酒を造るのに似ています。
それとバウンスメールのサンプルは幾つかあって、解析用コードも書けるのに、MTAの名前が解らないものについては、X1,X2というモジュール名(Sisimai::MTA::X1)で実装しました。X4まであります。将来それらを作ったMTAの名前が判明したらモジュール名も変更します。
MSPの対応強化
MSP(Mail Service Provider)の対応については僕がアカウントを持っているサービスだけ実装しています。特に@mail.ruなんかは誕生日を登録しておくと一番におめでとうメールをくれるフレンドリーなサービスです、サイトもメールもロシア語ですが。
海外のMSPは超有名なのは把握していますが、そうでない(というか僕が知らない)サービスについては、ユーザから貰ったPull-Requestで幾つか実装しました。Feedback-Loop対応も頂いたパッチで精度が向上したので嬉しい限りです。
バウンス理由の追加
Sisimaiは現時点(v4.1.28)で25種類のバウンス理由を検出できます。去年の11月以降に次のバウンス理由を新たに実装しました。
networkerror
以前は"systemerror"に分類していたエラーを"networkerror"として分離しました。ホップ数が多過ぎるとか、名前解決失敗とか、Unreachableとか、ネットワーク周りに起因するバウンスを扱います。
spamdetected
以前は"securityerror"に分類していましたが、相手側MTAが送信したメッセージをスパムであると判定した、あるいはDNSBLに一致するIPアドレスからの送信と判断された事によるバウンスは、この理由に分類されます。
norelaying
リレー拒否されたことによるバウンス理由です。以前は"norelaying"でしたが名前が長いので短くしました。
toomanyconn
同時接続数が多すぎることによる接続拒否でバウンスした理由として実装しました。時間を置いて再送すれば通るケースが多いので、ソフトバウンスな扱いにしています。たしかGmailのMXがそんなエラーを返していたので実装した気がします。
vacation
エラーではないのですが、とりあえず戻ってくるメールの一種なので実装しました。古来のvacationプログラムによるもので、最近は滅多に見ない気もしますが、RJBSさんのMail::DeliveryStatus::BounceParserが対応していたので対抗意識を燃やして実装してみました。
エラーメッセージパターンの拡充
Sisimai::Reason::*として実装しているバウンス理由の検出コードはエラーメッセージの正規表現の塊です。ここを充実させる事が精度の向上に繋がります。夏ごろ、エラーメッセージのパターンを検索している過程でSendGridのDeliverability Centerというページを見つけ、SendGridの担当者さんに連絡をして許可を貰って公開されているパターンを正規表現として実装しました。
dump()メソッド
Sisimai->dump('/path/to/mbox')を実行すると一発で解析結果のJSON文字列を返すようなのを実装しました。解析作業だけをSisimaiに任せて、その結果を別の言語(Ruby,Python,PHP他JSONが読める言語)で処理には便利なメソッドです。
解析結果に基づく処理をPerlで書くならSisimai->make('/path/to/mbox')を使うほうが便利です。
Sisimai::Dataのsoftbounceアクセサ
解析結果に基づいて処理をする場合に悩ましいのが、その宛先に再送するかどうか、という点です。運用方針によって異なるという側面はありますし、エラーメッセージによっても同様ですが、"expired"や"networkerror"なら再送してもOKという大まかな判断をSisimaiが行い、softbounceの値に1を設定するようになりました。userunknownやhostunknownなど再送しないほうが良さそうな場合、値は0となります。
Sisimai::Dataオブジェクトのデータ構造は「Sisimai — Data Structure of Sisimai::Data Object」のページに列挙しています。
今後の実装するかもしれない何か(v4.1.29以降)
一番のユーザである僕が特に必要としていないので、解析精度の改善以外に実装予定は立てていないのですが、以下の内容を実装する可能性はあるかもしれないです、たぶん。
ログファイルからの解析(/var/log/maillog)
外国からの問合せでバウンスメールはないけどエラーになったアドレスを調査したいって相談を貰いました。いろいろ聞いてみるとログがあるだけという話でした。ただ、バウンスメール全文に比べて/var/log/maillogはログレベルをDEBUGにでもしない限り情報量が少な過ぎて、解析出来ない事はないけど精度がどうかなぁってところなので、まだ実装する予定はありません。
Sendmail,Postfix,qmailぐらいならmaillogを集めてMTAのソースコードを読んで実装出来そうですが、それぞれのMTAを立ててある程度のメール送信+バウンスログの収集が必要なので、ユーザからの要望が多いとか、maillogを頂いたとか、あるいは僕がその機能を必要とするようになったとか、そういうケースでもない限り実装しないと思います。一応メモ書き程度にIssueを発行しています。
元メールの本文を解析結果に含む
Sisimai::Data->original_message()なんかでアクセス出来ると便利かも知れないんですが、make()やdump()に元メッセージをPATHで与えるので、ユーザが自分でコードを書けば元メッセージにアクセスする事は可能やと思います。とはいえ、何件かの問合せでこの機能が欲しいって言われたので、僕が必要性を実感したら実装するかもしれませんが、解析結果のデータ量が大きくなるし解析速度も落ちそうなので、消極的立場です。
Windows対応
ずっと放置しているのですが、SisimaiはWindowsで動きません。メールボックスの解析結果の件数が一致しないってエラーでmake testが落ちます。手元にWindows環境を持っていないので再現もデバッグも出来ないのですが、CPANにリリースする度にテスターさんからのメールが来て申し訳ない感じです。たぶん改行コードの扱いかPATHの扱いが原因であるような気がするのですが、やはり環境がないのと、僕がWindowsでSisimaiを動かす予定がないので結果的に放置になっています。
AmazonSESやSendGridのバウンス情報
直接バウンスメールを解析しているので僕は必要ないのですが、AmazonSESで発生したバウンスの情報が入っているJSONを読めると便利かなぁという気はしています。SendGridやMailChimpのAPIで得られるXMLやJSONについても同様です。
まとめ
という感じで、サイトもロゴも出来上がって一旦落ち着いています。細かなバグ修正やサンプルの追加、速度面での改善程度の変更は都度加えますが、上記の実装するかも知れない項目は実施予定も立てていません。
0 件のコメント:
コメントを投稿