QuickMLをグループウェア化するの続き。

名前（メールアドレス）を決めるだけでメーリングリスト（グループ）が作成でき、メンバーの追加はCCに入れるだけで済む、というのはやはりとても便利だ。このくらい敷居が低ければ、どんどんMLを作ってしまおうという気にもなる。

グループウェア的に利用する場合、基本的にプロジェクト単位でML（グループ）を作ることになる。そのプロジェクトに関するメールのやりとりをすべてML経由にすることで、メールを書くたびに、そのメールを誰と誰に送るのかをいちいち考える必要が無くなる。またSubjectが定型になるので、メールの自動分類も簡単だ。ただし、MLのメンバーではない人にそのプロジェクトに関するメールを送るときの処理はちょっと考える必要がある。

MLログをアーカイブしてWebベースで閲覧できるようにしておくと、自動的にそのプロジェクトに関する資料が生成されていることになる。まだ途中までしか作っていないが、添付ファイルを管理する文書管理システムを構築し、メールと添付ファイルを全文検索システムで検索できるようにすることで、その有用度はさらに高まるだろう。

というあたりが利点。しかし、ML管理が手軽な分に応じたセキュリティ的な甘さがやはり問題。

たとえば、間違ってCCにメンバーにしたくない人を入れてしまった場合、ほかの誰かによってMLあてに送られたメンバー以外に公開したくないメールが、本来送られては困る人に送られてしまう可能性がある（間違ったことに気付いてメンバー削除メールを送っても間に合わない場合があり得る）。

また、Webベースのログ閲覧システムにおいて、MLメンバーを妥当に認証することが困難。もともとMLメンバーはメールアドレスだけを頼りにルーズに管理されているので、それぞれに対して妥当な権限と認証システムを用意するのが難しい。妥当な権限と認証システムを用意しようとすると、QuickMLの利点をスポイルしてしまうことになる（ようなものしか思いつかない）。

解決のためのアプローチは二つある。

QuickMLの利点を出来るだけスポイルしないように（＝多少はスポイルすることをあきらめつつ）、外付けの認証システムを追加していく、というのが一つ。そうすると、ある程度安定しているQuickMLをそのまま利用しつつ、外付けの認証システムでそれなりにセキュアにすることが出来る。

もう一つは完全に新規に、QuickML的な利便性を持ちグループウェア的なセキュリティ機能を兼ね備えたMLシステムを設計する、というもの。QuickMLの思想だけをもらって、システム的には新規に設計する。

根本的に設計からやり直すとなると、実は妥当なエイリアスメールアドレス管理をするだけでも結構いけるのではないか、という気もしてくるな。

ああ、完全にLAN内でしか通用しないシステムとして運用する手もあるな。MLシステムのアドレスはローカルアドレスだけを振り、外からは絶対にメールが送れない。MLアドレスにメールを送れるのはLAN内の人だけ。LAN外のメールアドレスに対してメールを配送することは可能。完全な社内システムとしてならこれもありかな。

とかいうことを本格的にやっている暇はないので、考えているだけ。