Chienomi

MailDeliver2 : 完全にプログラマブルなフィルタ機能を持つMDA

有用なユーティリティコード

  • TOP
  • Old Archives
  • MailDeliver2 : 完全にプログラマブルなフィルタ機能を持つMDA

MailDeliver2がついに完成した。 おおよそできてはいたのだが、テストできておらず、テストしたらまだまだ足りない機能があることに気づき、 また不完全な部分が多かったため、2日かけてデバッグ、テスト、修正を繰り返した。

概要

保存・配送

Mail Deliverは完全にプログラマブルなフィルタを持つMDAと、それを補助するユーティリティ群である。 フィルタ、ソーター、通知の基本機能を備える。

基本的にはLinuxあるいはUNIX向けで、MH形式のメールフォルダに対して保存することになっている。

localdelivがMDAだ。その役割としては、フィルタを呼び出し、フィルタに従って処理することにある。 フィルタはメールの保存の機能を兼ねる。もしフィルタがメールを保存も破棄もしなかった場合は、localdeliv自身がデフォルトのメールフォルダへと保存する。

デフォルトのメールフォルダもフィルタ同様の方法で決定することができる。 MailDeliver2はRubyで書かれており、保存先メールフォルダの決定はRubyのprocオブジェクトによって行われる。このprocオブジェクトにはメールのヘッダの情報に加え、それを取り扱いやすくした情報を加えたメールオブジェクトが渡される。 そのため、静的な文字列ではなく、より動的に保存先を決定することができる。 ほとんどの場合、これで事足りるだろう。

例えば、設定サンプルでは次のように書かれている。

DefaultRule: ->(mail) { "inbox/address/#{mail.in || "Default"}/#{mail.domain || mail.address }/#{mail.address}" },

これはつまり、

inbox/address/<ユーザーのアカウント名 | Default>/<相手のドメイン名>/<相手のメールアドレス>

というフォルダに保存される、ということを意味している。 多数のメールアドレスを使用して使い分けている人は、そのメールアドレスによって相手の意味は既に分かれているだろう。まず、自分のどのアカウントに送られたものかをフォルダで分けてしまうことで相手を分類でき、この3段階の分け方があれば「だいたい分かる」。

ちなみに、副次的な効果として、詐欺にひっかかりにくくなる。受け取りアドレスとドメインを必然的に意識するからだ。 メールの「名前」をAmazonにしてお知らせを装った詐欺メールを大量に受け取っているが、ドメインがAmazonでないためすぐ分かる。 銀行関連もすぐわかるだろう。なぜならば、名前はメールを開くまでわからないが、アドレスは到着した時点から既に意識しているからだ。

フィルタは完全にプログラマブルであり、Rubyで自由に書くことができる。 もちろん、保存と破棄はよくある処理なのでそれを助ける機能がある。

さらに、保存してそのメールの処理を完了するかどうかは自由に選べる。 例えば複数のフォルダに保存するとか、特別に直ちに通知するとか、あるいは保存はするけれど通知の対象からは外す、ということも可能だ。 destroymail()は通知のためのファイルを削除するため、savemail()のあとdestroymail()すると通知はされない。

フィルタは条件自体がプログラマブルなので、例えば差出人によってのみ判定できる、というようなことはない。条件に単にtrueと書けば、常に適用されるフィルタが書ける。 現在デフォルトではclamAVしかサポートしないが、もっと強力な何らかのフィルタによって判定することもできる。その場合は、その判定処理を条件式に書けば良い。条件式に渡されるメールオブジェクトから完全なメール本文を得ることも可能で、IO.popenと$?を用いて外部プログラムを条件として使用できる。

そのためにルール記述がやや難しいことは否定しないが、最低限であればマニュアル通りに記述することで、常識的に判断できる人ならば動かすことはできるだろう。

通知

通知機能はプラグイン方式を取っている。

そのため、して欲しい通知方式を好きに組み合わせることができる。 現在はnotify-sendを用いたGUI表示機能と、play(SOX)を用いた音声通知機能を備える。

ディスプレイ表示機能はプログラマブルではない。選択式だ。 「アドレス」または「Fromの値」のどちらかで、各差出人あたりの通数か、 または総数を通知する。

音声通知機能はプログラマブルだ。 音声ファイルは静的に指定しなければならないが、適否に関してはProcオブジェクトなので、その気になれば判定とは関係のないプログラムを書くこともできる。

その重要性は、アドレスのマッチングにしても

  • 完全一致
  • case insensitiveな一致
  • Glob
  • 正規表現

とそれらの否定から選べることにある。また、論理和、論理積も使用可能だ。 一致だけでは大量のルールを書かなくてはいけない場合に、同じファイルを再生させる場合も楽になる。 設定ファイルの中でインスタンス変数を定義しておくことで、例えば複数のアドレスをマッチさせる、というようなことも可能だ。 マスター設定ファイル内でアドレスごとのグループを設定しておくこともできる。

何がしたかったかというと、「ケータイメールのような使い心地」だ。 ケータイならば、着信音で相手が分かる。通知で、メールを開かなくても誰から来たかも分かる。 「着メロ」機能があるMUAは極めて少ない。着メロ機能と強力な振り分け機能を兼ね備えるものはない。 そもそも、振り分けのルール記述が極めて面倒だ。

そのような、大量のメールを受け取る人が、効率的にルールを書くことができ、メールを確認したり処理するための効率を大幅に向上させる、画面にかじりついていなくても、その時がきたことをアクティブに教えてくれる、という使い心地を、MUAではなく、MDAで実現した形となる。

1からの変更

まず、完全にRubyになった。 フルプログラマブルにするために、今まで開発効率からZshを使用していた部分に関しても、全てRubyとした。外部プログラムでなく、ライブラリの呼び出しとすることで、連続したマッチングも高速化でき、また渡せる情報も大幅に増えた。

一部手段としてUNIX系OS固有のものを使用しているが、恐らくWindowsに対して移植可能なものになったというのもメリットだろうか。 問題はKernel.forkを使用していることと、playコマンドやnotify-sendを使っていること、Sound Notifyはログを/dev/nullに書いていることだろう。

当然、このこととセットになって、よりプログラマブルになった。 そもそもの出発点が、フィルタが保存する内容には関与できない（保存するフォルダを出力するだけだったため、必ず保存されるし、保存内容を加工することもできない）という点が要求を満たさないケースがあったことについてだ。

これに対応したため、メールの破棄や、保存内容の加工も可能になった。 メールオブジェクトがメール全文を持っており、それがそのまま書き込む内容でもある。 メールを破棄した場合は、通知にも残らない。

構造がすっきりして、手を加えることもしやすくなった。 これまで通知系はプログラム自体を変更して、手元で専用のものにしていたが、汎用性があるものとなり、 単にプラグインフォルダに入れているものが適用されることとなった。

このあたりは、自分用だったものが、使ってもらうことを考えた変更が加えられたといっていい。

このほか、開発効率を優先して非常に複雑な構成（トリッキー）だったプログラムが、しっかりと設計されたものに変更されたため、挙動を把握しやすく、プログラマブルな部分がちゃんと活かせるようになった。 従来はフィルタが動くはずのものを書いても動かないことが多く、デバッグも難しかった。 今回はデバッグしやすいようにログもわかりやすいしてある。 これは、プログラマブルなためにユーザー定義部分でプログラムのエラーがでる場合が多いからだ。

プログラム

見どころは多いが、いくつか紹介。

プラグイン

単純にロードしているが、

class StandardNotify
  PLUGINS = []

と名前に約束を作り、プラグインは自身のオブジェクトをStnadardNotify::PLUGINSにpushする。 プラグインはfireメソッドをインターフェイスとして義務付けられている。

メールの準備

ヘッダとボディは次のようにして取得。

head, body = NKF.nkf( "-w -Lu -m", mailstr ).split(/\r?\n\r?\n/, 2)

ヘッダは次のコード

    head.each_line do | l |
      if l =~ /^\s*$/
        break
      elsif l =~ /^\s+/
        headerlines.last.concat(l.lstrip)
      else
        headerlines.push(l)
      end

    end
    
    headerlines.each do |i|
      if i =~ /\A([-_A-Za-z0-9]+)\s*:/ # match header format?
        mailobj[$1.upcase] = $'.strip
      else
        next
      end
    end

caseやspaceなどを守らない変なメールに対応するための措置を取っている。

メールアドレスの抜き出し

恐らく最もテクニカルだ。

  def extract_addr(f)
    if f =~ /(?:[^"<]*(?>"[^"]*"))*<([^>]+)>/ # Do From term have NAME<addr> format?
      address = $1.delete("\" \t/")
    else
      address = f.delete("\" \t/")
    end
    
    address
  end

単に仕様だけでなく、実際に使われている形式に則っている。 アドレスをクォートしているものに対しては対応しない。

メール方向の判定

    if @maildeliv_conf[:MyAddress].any? {|k, v| in_k =k; File.fnmatch(v, from) }
      mailobj.direction = :send
      mailobj.address = to
      mailobj.in = in_k
      
    elsif @maildeliv_conf[:MyAddress].any? {|k, v| in_k =k; File.fnmatch("*" + v + "*", mailobj["TO"]) }
      mailobj.direction = :recieve
      mailobj.address = from
      mailobj.in = in_k
      
    else
      
      mailobj.direction = :unknown
      mailobj.address = from
      mailobj.in = nil
    end

fromもtoもアドレスを抽出したものだ。 差出人アドレスがマイアカウントとして定義されたものと一致するか？をチェックしている。 ちなみに、Toは単一とは限らないので、Fromを先に判定するのが確実で好ましい。